AXT1800 wired connections get slower, reboot fixes it. Why?

I’m in a hotel this week, and lucky enough to snag an Ethernet connection for my AXT1800 (running 4.0.3-Release1). (ProTip: many times the TV’s in-room entertainment system has an Ethernet cable, and provided they don’t VLAN/MAC-filter it off, you can use it for Internet instead :slight_smile: )

Anyway, this hotel likely has fiber as I could get ~100Mbit/sec in both directions on my laptop (wired to the SlatePlus) - at first. As the days went on, I’d noticed things seemed more sluggish and a Speedtest showed the same upload, but download was reduced to about ~30Mbit/sec. I figured I should try seeing if there was a newer firmware, but ended up just reloading 4.0.3-r1 and rebooting- and when I did, the download came back to the ~100Mbit figure.

Now, everything is wired up, and I have a Wireguard VPN connection active, but it only is for my home-office’s subnet (i.e., everything not 192.168.124.0/24 goes thru the WAN), so why/how should rebooting make things fast again? It was even the same Speedtest server as before the reboot. WiFi is active, but there was nothing on it but a couple of dormant cellphones.

I’m a little worried if this is something others are seeing, as these systems should pretty much do the same thing the entirety of the time it’s powered up.

Sounds like a memory leak or process that’s gone haywire and started eating up resources. Rebooting clears out the memory so you’re starting from scratch at that point.

I’d considered that, but the upload is just fine. Next time it happens (and I’m about to check out tomorrow so it may not happen in this trip’s timeframe) I’ll ssh in and run ps/top and take a look at /proc/meminfo , to be sure though.

ETA: I should also see about the WAN port’s PHY Auto-Negotiated at. I looked around, but can’t find it- and the “Switch” page in LuCI has more ports marked “connected” than I’m using right now, so don’t know if I can trust that.

I just spent two weeks trying to use the AXT1800 as a travel router and… shoo… the software just isn’t there yet. Tons of trouble connecting, both to 2.4G and 5G. nginx going totally unresponsive until a reboot, at which point I would have to try to catch it early in the boot cycle. Multiple hard firmware resets and loading different versions (4.0, 4.0.2, 4.0.3, 5.4 kernel) before finding combinations that work. And at the end of the day my MT1300 would have been more than sufficient to max out the connection I had. At one hotel it took me over an hour to get connected and running - and I’m someone who knows a fair bit about networking and embedded firmware. Not a good look.

I like the look and features of 4.0, and I appreciate that GL-iNet are doing a lot of work to even get the chipset to work with OpenWRT, but my frank evaluation of the platform right now - as a travel router - is that it is not ready for production. I’ve just accepted the fact that this one is not going to be ready to rely on for another few months, at least.

There have been promises of rapid firmware updates, and I hope that’s true, but I can guarantee that for my next trip, the AXT1800 is staying home in favor of one of my older GL-iNet products.

Next time you can have have a check if restart Wireguard

Dude, I’m not trying to dismiss your experience, but my SlateAX has been my go-to router for all my various and extensive trips- it’s been rock-solid since Day One. I’m guessing you’ve already done all the basic stuff (firmware, resets, config, …)?

What do you want me to do? And if WG is just routing a particular subnet, you think it could still be involved?

I suspect that Wireguard affect your network performance. So before restart router try restarting Wireguard first.

Yeah. Not my first rodeo. I’ve been using GL-iNet routers since the 6416, and typically like to build my own firmware from source.

Oddly it seemed ok on some of the older firmwares (say 4.0.0 r3?). There are acknowledged problems connecting to 5GHz networks, but this went well beyond that. The biggest issue was a completely unresponsive WebUI after 2-3 minutes while SSH remained fully functional (no obvious process problems or memory leaks in top).

Once I finally got connected it was fine, but it took 20 minutes at one hotel and over an hour at the other to make that happen - something I’ve never experienced on older products (or stock OpenWRT).

You may be onto something here … but with my current setup (using my own HS and sometimes repeating the hotel WiFi in a different location) I can’t tell RN if the issue is that or something else.

… I dunno if it’s related to WG or not now … I ran w/o WG and repeating the hotel WiFi, and things didn’t really get back to full speed until I’d rebooted. Note that it seems like the same issue when wired, but on this trip I only used hotspot and repeater as WAN.