Something has happened to my AC5300 router...

[David Wolfe]

My router had been acting a little squirrelly for a few weeks so a couple of days ago I did a factory reset on it. It was suffering from poor performance, client disconnects, VPN service failures to start, locked resources tables even though they were no were near capacity, etc. Running under Merlin 386.2.

Reset the router once and began rebuilding the config on stuff. About half way through on a reboot it would no longer accept my admin login. Just like it went corrupt and there was no way in. Reset a 2nd time.

After I reset this time, I was notified of 386.2_0 being available. I installed this firmware. So far I have been able rebuild the config on the router to a functional level without the previous loss of login access. However.... It still doesn't seem healthy. The 2.4 band on the router is dog slow for all clients. It chokes and freezes and drops clients frequently. The 5G bands seem ok though. About half the time when I adjust a MAC lock down list it won't just recycle the wifi signal. The router will do a full crash and reboot but it does store the change I was trying to apply. The AIProtection Internet scheduling feature seems to be back to 386.1 status where it shows that a client is blocked but in fact it is not. Every now and then the web UI is flakey and I have to hit refresh in my browser to cycle the page and get it back to a usable place.

Does anyone know if this is symptomatic of something I can fix or if the router is just in the process of dying? Any way to get some readable diagnostic info on these sort of issues? It's 2-3 years old so it should still be in the prime of life as far as I see it.

My wife and kid are about to kill me with all these problems and reboots. They're worse that my IT director at work.

Thanks

-David

 

[ColinTaylor]

You said you were previously running 386.2 when you had the problems, then you installed 386.2_0. AFAIK they're the same thing.

 

[David Wolfe]

I would have thought so too but the router seemed to think there was an update available and the timestamp on the _0 firmware is 4/2 so that is newer than the regular .2 firmware I applied about a month ago.

 

[sbsnb]

What do your temps look like?

 

[David Wolfe]

Seems to be in a fairly normal range. I have paid attention to the CPU and memory stats and they are in what I would consider low usage ranges. The router is placed in a pretty open and well ventilated area. To me it feels like the internal storage may be developing some corruption but I'm not Linux-savvy enough to know the command(s) to do an integrity check.

 

[ColinTaylor]

I would have thought so too but the router seemed to think there was an update available and the timestamp on the _0 firmware is 4/2 so that is newer than the regular .2 firmware I applied about a month ago.

"Regular" 386.2 never existed. It's likely you were running 386.1_2 from February. Regardless, the factory reset should have sorted you out. Strange.

Any errors in the syslog?

EDIT: This might account for some of the UI weirdness:

386.2 (2-Apr-2021)
  - NOTE: due to changes in how custom device icons are handled,
          first time you boot with 386.2 you need to either
          shift-reload the main index page, or clear your
          browser cache.

 

[sbsnb]

When you reset:

1. Are you resetting after loading firmware?
2. Are you loading any backups afterward (JFFS, configs, etc.)?
3. Do you have any USB devices connected to the router?
4. Have you tried L&LD's reset (https://www.snbforums.com/threads/n...and-manual-configuration.27115/#post-205573)?

 

[David Wolfe]

That may be me misremembering that version string. That probably does explain it. And yes, I did see an out-of-sync device icon issue on first load of the web UI after the update and I did a cache clear and that fixed it right up.

 

[David Wolfe]

When you reset:

1. Are you resetting after loading firmware?
2. Are you loading any backups afterward (JFFS, configs, etc.)?
3. Do you have any USB devices connected to the router?
4. Have you tried L&LD's reset (https://www.snbforums.com/threads/n...and-manual-configuration.27115/#post-205573)?

I did not reset after loading 386.2 as it was a pretty plain config to begin with. But I can do that if it is likely to help.

Not reloading anything. Manually rebuilding my config to make sure there was nothing wacky coming back from a settings import.

I did have a USB stick attached but I removed that prior to the first factory reset.

I have not tried that reset method. I will review it and see how it differs from a factory reset. Thanks for the tip!

-David

 

[ColinTaylor]

I did not reset after loading 386.2 as it was a pretty plain config to begin with. But I can do that if it is likely to help.

From the GUI do a factory reset with the initialise option checked.

 

[David Wolfe]

Ah, I apologize. Didn't realize that's what you meant. Yes. I did select that option on the first factory reset. But, on the second one I had to use the front reset button since I couldn't get into the system.

 

[David Wolfe]

I just had another crash and reboot of my router as I was trying to make a change to the 2.4 ghz radio. I noticed that most of my 2.4 ghz clients were reporting horrible Tx and Rx rates in the network map (single digits with many being 1), even those in close proximity to the router. I noticed that the 2.4 ghz radio had a the Bluetooth Coexistence option disabled. I enabled that and applied settings and that caused the router to crash and reboot.

Tx and Rx rates look much better (pretty normal ranges in my experience) but I'll watch them over the evening and see if they drop.

The syslog showed on the crash that the router was handing back out DHCP addresses to all the clients reconnecting after the radio config change and then it died and the syslog service startup entries were next.

Apr  9 17:04:42 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:04:46 dnsmasq-dhcp[714]: DHCPDISCOVER(br0) 00:d0:2d:42:3d:72
Apr  9 17:04:46 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:04:54 dnsmasq-dhcp[714]: DHCPDISCOVER(br0) 00:d0:2d:42:3d:72
Apr  9 17:04:54 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:05:03 dnsmasq-dhcp[714]: DHCPDISCOVER(br0) 00:d0:2d:42:3d:72
Apr  9 17:05:03 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:05:05 syslog: wlceventd_proc_event(527): eth1: Auth 64:52:99:53:38:AC, status: Successful (0), rssi:0
Apr  9 17:05:05 syslog: wlceventd_proc_event(556): eth1: Assoc 64:52:99:53:38:AC, status: Successful (0), rssi:0
May  5 01:05:08 syslogd started: BusyBox v1.25.1
May  5 01:05:08 kernel: klogd started: BusyBox v1.25.1 (2021-04-01 22:49:54 EDT)
May  5 01:05:08 kernel: >Memory: 512MB = 512MB total
May  5 01:05:08 kernel: Memory: 514896k/514896k available, 9392k reserved, 0K highmem
May  5 01:05:08 kernel: Virtual kernel memory layout:
May  5 01:05:08 kernel:     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
May  5 01:05:08 kernel:     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
May  5 01:05:08 kernel:     DMA     : 0xf7e00000 - 0xffe00000   ( 128 MB)
May  5 01:05:08 kernel:     vmalloc : 0xa0800000 - 0xf0000000   (1272 MB)
May  5 01:05:08 kernel:     lowmem  : 0x80000000 - 0xa0000000   ( 512 MB)
May  5 01:05:08 kernel:     modules : 0x7f000000 - 0x80000000   (  16 MB)
May  5 01:05:08 kernel:       .init : 0x80008000 - 0x80050000   ( 288 kB)
May  5 01:05:08 kernel:       .text : 0x80050000 - 0x80410000   (3840 kB)
May  5 01:05:08 kernel:       .data : 0x8042a000 - 0x8044f400   ( 149 kB)
May  5 01:05:08 kernel: SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
May  5 01:05:08 kernel: Hierarchical RCU implementation.
May  5 01:05:08 kernel:     RCU-based detection of stalled CPUs is disabled.
May  5 01:05:08 kernel:     Verbose stalled-CPUs detection is disabled.
May  5 01:05:08 kernel: NR_IRQS:256
May  5 01:05:08 kernel: MPCORE GIC init

I assume the system clock rolled back to some arbitrary time on the crash and was reset when the ntp service started.

 

[Hawk]

I just had another crash and reboot of my router as I was trying to make a change to the 2.4 ghz radio. I noticed that most of my 2.4 ghz clients were reporting horrible Tx and Rx rates in the network map (single digits with many being 1), even those in close proximity to the router. I noticed that the 2.4 ghz radio had a the Bluetooth Coexistence option disabled. I enabled that and applied settings and that caused the router to crash and reboot.

Tx and Rx rates look much better (pretty normal ranges in my experience) but I'll watch them over the evening and see if they drop.

The syslog showed on the crash that the router was handing back out DHCP addresses to all the clients reconnecting after the radio config change and then it died and the syslog service startup entries were next.

Apr  9 17:04:42 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:04:46 dnsmasq-dhcp[714]: DHCPDISCOVER(br0) 00:d0:2d:42:3d:72
Apr  9 17:04:46 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:04:54 dnsmasq-dhcp[714]: DHCPDISCOVER(br0) 00:d0:2d:42:3d:72
Apr  9 17:04:54 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:05:03 dnsmasq-dhcp[714]: DHCPDISCOVER(br0) 00:d0:2d:42:3d:72
Apr  9 17:05:03 dnsmasq-dhcp[714]: DHCPOFFER(br0) 192.168.1.209 00:d0:2d:42:3d:72
Apr  9 17:05:05 syslog: wlceventd_proc_event(527): eth1: Auth 64:52:99:53:38:AC, status: Successful (0), rssi:0
Apr  9 17:05:05 syslog: wlceventd_proc_event(556): eth1: Assoc 64:52:99:53:38:AC, status: Successful (0), rssi:0
May  5 01:05:08 syslogd started: BusyBox v1.25.1
May  5 01:05:08 kernel: klogd started: BusyBox v1.25.1 (2021-04-01 22:49:54 EDT)
May  5 01:05:08 kernel: >Memory: 512MB = 512MB total
May  5 01:05:08 kernel: Memory: 514896k/514896k available, 9392k reserved, 0K highmem
May  5 01:05:08 kernel: Virtual kernel memory layout:
May  5 01:05:08 kernel:     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
May  5 01:05:08 kernel:     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
May  5 01:05:08 kernel:     DMA     : 0xf7e00000 - 0xffe00000   ( 128 MB)
May  5 01:05:08 kernel:     vmalloc : 0xa0800000 - 0xf0000000   (1272 MB)
May  5 01:05:08 kernel:     lowmem  : 0x80000000 - 0xa0000000   ( 512 MB)
May  5 01:05:08 kernel:     modules : 0x7f000000 - 0x80000000   (  16 MB)
May  5 01:05:08 kernel:       .init : 0x80008000 - 0x80050000   ( 288 kB)
May  5 01:05:08 kernel:       .text : 0x80050000 - 0x80410000   (3840 kB)
May  5 01:05:08 kernel:       .data : 0x8042a000 - 0x8044f400   ( 149 kB)
May  5 01:05:08 kernel: SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
May  5 01:05:08 kernel: Hierarchical RCU implementation.
May  5 01:05:08 kernel:     RCU-based detection of stalled CPUs is disabled.
May  5 01:05:08 kernel:     Verbose stalled-CPUs detection is disabled.
May  5 01:05:08 kernel: NR_IRQS:256
May  5 01:05:08 kernel: MPCORE GIC init

I assume the system clock rolled back to some arbitrary time on the crash and was reset when the ntp service started.

Correct, clock has to sync again with ntp server after router boot up.

 

[anonimo]

Having an RT-AC5300 I have been following how people with the same router have fared with the latest firmware before updating my own. The newer 386-based code has been a bit hit-or-miss on the RT-AC5300, though not much of a surprise when the previous 384 code base was out, updated, and improved for years versus a few months on the 386 code base. The only way to improve the existing 386 code base is to try it and fix what breaks, but if stability is critical then going back to the 384.19 version might be a good course of action if L&LD’s firmware update method isn’t working in your case. Disabling DNSSEC and using a trusted upstream DNS server will address the DNSpooq vulnerabilities for 384.19.

If you do go back to 384.19 and it works well, or not, please let us know.

 

[dcoli]

I'm having the same problem with the .2 version and an RT-AC5300. Actually, the first time I tried to upgrade I did a reset afterwards and uploaded my config and jffs. Had weird dropping problems, so uploaded firmware again with hard reset and started config from scratch (I don't remember if I wiped the jffs again, so i probably didn't.) Still flaky with random drops, and my Sonos network stopped working largely. So, I uploaded the stock firmware, did hard reset, and now getting abysmal traffic speeds. I have a Pepwave router I use for some IoT stuff, and when that's hooked up to my cable modem my network speeds are normal (but as slow as the Pepwave supports). So I think there's something I'm doing wrong with the upgrade. We should really have a pinned thread that just says how to properly upgrade, both clean and dirty.

And I'll add that with merlin I was sporting two USB drives both with USB 2.0, but having trouble. With the stock firmware I only have the one, also using USB 2.0 since I know 3 can be flakey, but I have a media server, an ftp server, and time machine hooked up to it.

 

[David Wolfe]

Having an RT-AC5300 I have been following how people with the same router have fared with the latest firmware before updating my own. The newer 386-based code has been a bit hit-or-miss on the RT-AC5300, though not much of a surprise when the previous 384 code base was out, updated, and improved for years versus a few months on the 386 code base. The only way to improve the existing 386 code base is to try it and fix what breaks, but if stability is critical then going back to the 384.19 version might be a good course of action if L&LD’s firmware update method isn’t working in your case. Disabling DNSSEC and using a trusted upstream DNS server will address the DNSpooq vulnerabilities for 384.19.

If you do go back to 384.19 and it works well, or not, please let us know.

I have a feeling you're right about holding off on the 386 release, anonimo. I reviewed the full reset advice on the L&LD post but that is a lot of work and disabling and waiting which I don't think in the long run will make any difference. My gut tells me there's something fundamentally amiss (at least with the AC5300 implementation) with this release that no amount of tweaking is going to help.

It got so bad with my router last night and this morning that 2.4 clients would not stay connected for more than 30-60 minutes. When I say "would not stay connected", I mean they would still ping, but that's about it. My WiFi printer has a web interface for status and I could ping the printer but port 80 access to the printer would just spin and eventually time out. And my Ring cameras on the 2.4 band would stop being accessible as well. I have a Honeywell WiFi thermostat and I could see it dropping in the Network Map list every 60 seconds as it released it's IP and renewed trying to go out to the Internet. The syslog showed these release and renew attempts as well so it wasn't dropping WiFi so much as it just couldn't get through the router to the Internet.

I followed the steps for a rescue boot on the router and installed the 384.19 Merlin firmware and factory reset immediately afterwards. I'm rebuilding my config from scratch now. So far so good. I'll post again in the morning with a status of my 2.4 clients. Shouldn't take long until I have a feel for whether or not things are better.

dcoli.... Sorry you're in the same boat. If my downgrade stabilizes my environment, that may be the way you'll need to go.

-David

 

[David Wolfe]

Just to follow up. It's been nearly 6 hours since I rolled back the firmware to 384.19 and the router has been smooth as silk. I couldn't make it 30 minutes under the 386 code without problems. No crash at all and I've got everything set as needed. All 2.4 ghz band clients are solid and happy. Ping times that used to be 700-1000 ms to 2.4 ghz clients are now 2-9 ms. Not a single issue since the roll back.

From my perspective the 386 release is not ready for deployment at least on the AC5300.

 

[kernol]

My first Asus Router was the AC5300 ... and even back then it seemed to me that Asus was "slow" in releasing firmware updates for it compared to other models. The same seems to be the situation now - with their latest "386" stock firmware still only in "beta" release.

There is certainly no "release" version 386_42095 for the AC5300 even though RMerlin seems to have baked that GPL into his 386.2 release for this model. The lesson I learned back then ... stick with stable and only adopt more recent if Asus has in fact released their GPL code for this model which is in sync with GPL code version baked in by RMerlin.

 

[Crazy]

My AC5300 have been running fine on 386.2. Only thing not working is the traffic log.

 

[fitnesspmm]

I found all versions after 384.18 unstable on my RT-AC5300. I notice it the most on my security cameras (Swann), which will always drop out after a short period of time.

I tried everything including a hot or cold reset as well as a lot of help on the forum here. Never a problem with 384.18 hence why I will stick with it for now.