RT-AC88U Dropping 2.4Ghz Clients

[sbsnb]

I have been running the RT-AC88U for over a month in Merlin 380.67 without even a single wireless hiccup. Not a single drop and amazing range. Before that I was running an old Linksys WRT54GS for over a decade without any issues (other than getting long in the tooth). Then this morning all of my 2.4GHz clients can't connect. I tried restarting the clients (Roku, Google Pixel phones, laptops) and still no joy. So I hit up Google and I see the same complaint with 2.4GHz dropping out going back years with Asus routers in particular, but none of the suggestions in those threads seem to have any effect. Of course this starts happening literally two days after my window to return the router passed.

In the logs I see the clients DHCP'ing every twenty seconds or so.

Has anybody who experienced this issue with Asus routers definitively solved it?

 

[sbsnb]

More information. When the clients do connect for a few seconds, they aren't able to ping the router even though ipconfig /all shows the router as the default gateway and they have a valid IP address.

 

[sbsnb]

Most of the time the clients can't connect. No entries in the log when connection attempt unsuccessful.

 

[sbsnb]

So I got the idea to connect to the guest 2.4GHz network, and that failed with "authentication problem". I know there isn't a problem because I connected by scanning a QR code I have on the router with the guest network's SSID and password, and it's worked fine in the past. Nothing in the logs after the failure.

I tried restarting the 2.4GHz radio by disabling and re-enabling it, but no effect.

 

[sbsnb]

Set logging to debug level, still nothing. Cannot ping clients from router even though dnsmasq has assigned them an IP.

 

[sbsnb]

Reboot doesn't fix the problem, either.

 

[ColinTaylor]

Backup your current configuration and then factory reset the router. See if the problem still exists with a vanilla configuration.

 

[sbsnb]

That's next on the agenda. Have to wait until remote VPN user can disconnect. It ran for over a month on this config flawlessly, though. No one's even logged in to the router for weeks until today after the 2.4G stopped working.

My fear is that it will work again just like when I first set it up, and then after a month or so it will die again. I'd much rather find the cause than to fix it without understanding why it's broken.

 

[sbsnb]

This is all I see in the logs that seems even remotely related:

Sep  7 12:14:43 kernel: br0: port 2(eth1) entering forwarding state
Sep  7 12:14:43 kernel: device eth1 left promiscuous mode
Sep  7 12:14:43 kernel: br0: port 2(eth1) entering disabled state
Sep  7 12:14:43 kernel: br0: port 3(wl0.1) entering forwarding state
Sep  7 12:14:43 kernel: device wl0.1 left promiscuous mode
Sep  7 12:14:43 kernel: br0: port 3(wl0.1) entering disabled state
Sep  7 12:14:43 kernel: dhd_detach(): thread:dhd_watchdog_thread:1302 terminated OK
Sep  7 12:14:44 kernel: dhd_detach(): thread:dhd_watchdog_thread:12fc terminated OK
Sep  7 12:14:49 kernel: PCI_PROBE:  bus 1, slot 0,vendor 14E4, device 4365(good PCI location)
Sep  7 12:14:49 kernel: dhd_attach(): thread:dhd_watchdog_thread:18e9 started
Sep  7 12:14:49 kernel: Dongle Host Driver, version 1.363.45.58013 (r651509)
Sep  7 12:14:49 kernel: Compiled in drivers/net/wireless/bcmdhd on Jun 21 2017 at 10:36:36
Sep  7 12:14:49 kernel: Register interface [eth1]  MAC: ff:ff:ff:ff:ff:fa
Sep  7 12:14:49 kernel: PCI_PROBE:  bus 1, slot 0,vendor 14E4, device 4365(good PCI location)
Sep  7 12:14:49 kernel: dhd_attach(): thread:dhd_watchdog_thread:1913 started
Sep  7 12:14:50 kernel: Dongle Host Driver, version 1.363.45.58013 (r651509)
Sep  7 12:14:50 kernel: Compiled in drivers/net/wireless/bcmdhd on Jun 21 2017 at 10:36:36
Sep  7 12:14:50 kernel: Register interface [eth2]  MAC: ff:ff:ff:ff:ff:ff
Sep  7 12:14:50 kernel: Register interface [wl0.1]  MAC: ff:ff:ff:ff:ff:fa
Sep  7 12:14:50 kernel: device eth1 entered promiscuous mode
Sep  7 12:14:50 kernel: br0: topology change detected, propagating
Sep  7 12:14:50 kernel: br0: port 2(eth1) entering forwarding state
Sep  7 12:14:50 kernel: br0: port 2(eth1) entering forwarding state
Sep  7 12:14:50 kernel: device wl0.1 entered promiscuous mode
Sep  7 12:14:50 kernel: br0: topology change detected, propagating
Sep  7 12:14:50 kernel: br0: port 3(wl0.1) entering forwarding state
Sep  7 12:14:50 kernel: br0: port 3(wl0.1) entering forwarding state
Sep  7 12:15:00 dnsmasq-dhcp[5666]: DHCPDISCOVER(br0) ff:ff:ff:ff:ff:fb
Sep  7 12:15:00 dnsmasq-dhcp[5666]: DHCPOFFER(br0) 192.168.229.159 ff:ff:ff:ff:ff:fb
Sep  7 12:15:00 dnsmasq-dhcp[5666]: DHCPREQUEST(br0) 192.168.229.3 ff:ff:ff:ff:ff:fc
Sep  7 12:15:00 dnsmasq-dhcp[5666]: DHCPNAK(br0) 192.168.229.3 ff:ff:ff:ff:ff:fc address not available
Sep  7 12:15:03 dnsmasq-dhcp[5666]: DHCPDISCOVER(br0) 192.168.229.3 ff:ff:ff:ff:ff:fc
Sep  7 12:15:03 dnsmasq-dhcp[5666]: DHCPOFFER(br0) 192.168.229.51 ff:ff:ff:ff:ff:fc
Sep  7 12:15:03 dnsmasq-dhcp[5666]: DHCPREQUEST(br0) 192.168.229.51 ff:ff:ff:ff:ff:fc
Sep  7 12:15:03 dnsmasq-dhcp[5666]: DHCPACK(br0) 192.168.229.51 ff:ff:ff:ff:ff:fc
Sep  7 12:16:04 dnsmasq-dhcp[5666]: DHCPDISCOVER(br0) ff:ff:ff:ff:ff:fb
Sep  7 12:16:04 dnsmasq-dhcp[5666]: DHCPOFFER(br0) 192.168.229.159 ff:ff:ff:ff:ff:fb
Sep  7 12:16:04 dnsmasq-dhcp[5666]: DHCPREQUEST(br0) 192.168.229.159 ff:ff:ff:ff:ff:fb
Sep  7 12:16:04 dnsmasq-dhcp[5666]: DHCPACK(br0) 192.168.229.159 ff:ff:ff:ff:ff:fb CLIENT
Sep  7 12:27:35 rc_service: httpd 1527:notify_rc restart_qos;restart_firewall
Sep  7 12:27:39 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Sep  7 12:36:26 dnsmasq-dhcp[5666]: DHCPINFORM(br0) 192.168.229.159 ff:ff:ff:ff:ff:fb
Sep  7 12:36:26 dnsmasq-dhcp[5666]: DHCPACK(br0) 192.168.229.159 ff:ff:ff:ff:ff:fb CLIENT

Even after DHCPACK 192.168.229.159, I can't ping it from the router.

 

[ColinTaylor]

I'm guessing you've edited the MAC addresses (ff:ff:ff:ff:ff:fa) for no particular reason?

 

[sbsnb]

I'm guessing you've changed the MAC addresses (ff:ff:ff:ff:ff:fa) for no particular reason?

Yes. It's just a little script I run in my text editor that replaces MAC addresses. It doesn't hurt either, unless somebody really wants to know the manufacturer of the devices.

 

[ColinTaylor]

Yes. It's just a little script I run in my text editor that replaces MAC addresses. It doesn't hurt either, unless somebody really wants to know the manufacturer of the devices.

Sometimes knowing the device manufacturer can provide clues to the problem. Obfuscating local MAC addresses provides no security benefits and just confuses things IMHO.

 

[sbsnb]

Interesting. When I just ping one of the wireless clients from SSH, most of the packets don't make it, but if I wait a long time some of the packets start making it. If I traceroute to the wireless client, even the first step (the router) has some packet loss and very slow responses.

admin@asuswrt:/jffs/configs# traceroute 192.168.229.159
traceroute to 192.168.229.159 (192.168.229.159), 30 hops max, 38 byte packets
 1  *  *  192.168.229.1  3005.222 ms !H
 2  192.168.229.1  3009.706 ms !H  3009.798 ms !H  3009.855 ms !H
admin@asuswrt:/jffs/configs# ping 192.168.229.159
PING 192.168.229.159 (192.168.229.159): 56 data bytes
64 bytes from 192.168.229.159: seq=36 ttl=128 time=1405.447 ms
64 bytes from 192.168.229.159: seq=37 ttl=128 time=406.232 ms
64 bytes from 192.168.229.159: seq=38 ttl=128 time=1.351 ms
64 bytes from 192.168.229.159: seq=39 ttl=128 time=1.336 ms
64 bytes from 192.168.229.159: seq=40 ttl=128 time=1.710 ms
64 bytes from 192.168.229.159: seq=41 ttl=128 time=1.465 ms
64 bytes from 192.168.229.159: seq=42 ttl=128 time=1.271 ms
64 bytes from 192.168.229.159: seq=43 ttl=128 time=1.320 ms
64 bytes from 192.168.229.159: seq=44 ttl=128 time=1.248 ms
64 bytes from 192.168.229.159: seq=45 ttl=128 time=1.358 ms
64 bytes from 192.168.229.159: seq=46 ttl=128 time=1.704 ms
64 bytes from 192.168.229.159: seq=47 ttl=128 time=1.534 ms
64 bytes from 192.168.229.159: seq=48 ttl=128 time=1.296 ms
64 bytes from 192.168.229.159: seq=49 ttl=128 time=1.443 ms
64 bytes from 192.168.229.159: seq=50 ttl=128 time=3.760 ms
64 bytes from 192.168.229.159: seq=51 ttl=128 time=4.518 ms
64 bytes from 192.168.229.159: seq=52 ttl=128 time=4.731 ms
64 bytes from 192.168.229.159: seq=53 ttl=128 time=2.798 ms
64 bytes from 192.168.229.159: seq=54 ttl=128 time=1.357 ms
^C
--- 192.168.229.159 ping statistics ---
63 packets transmitted, 19 packets received, 69% packet loss
round-trip min/avg/max = 1.248/97.151/1405.447 ms

 

[ColinTaylor]

In the logs I see the clients DHCP'ing every twenty seconds or so.

I don't see that. I see one client doing another DHCP request after 20 minutes.

 

[sbsnb]

If I ping a 5G client, no problem:

admin@asuswrt:/jffs/configs# ping 192.168.229.51
PING 192.168.229.51 (192.168.229.51): 56 data bytes
64 bytes from 192.168.229.51: seq=0 ttl=64 time=2.480 ms
64 bytes from 192.168.229.51: seq=1 ttl=64 time=2.211 ms
64 bytes from 192.168.229.51: seq=2 ttl=64 time=2.085 ms
64 bytes from 192.168.229.51: seq=3 ttl=64 time=2.436 ms
64 bytes from 192.168.229.51: seq=4 ttl=64 time=2.029 ms
64 bytes from 192.168.229.51: seq=5 ttl=64 time=2.102 ms
...
64 bytes from 192.168.229.51: seq=49 ttl=64 time=2.032 ms
64 bytes from 192.168.229.51: seq=50 ttl=64 time=2.397 ms
64 bytes from 192.168.229.51: seq=51 ttl=64 time=2.235 ms
^C
--- 192.168.229.51 ping statistics ---
52 packets transmitted, 52 packets received, 0% packet loss
round-trip min/avg/max = 1.976/2.256/3.144 ms

But if I try to traceroute:

admin@asuswrt:/jffs/configs# traceroute 192.168.229.51
traceroute to 192.168.229.51 (192.168.229.51), 30 hops max, 38 byte packets
 1  *  *  *
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5^C

 

[sbsnb]

I don't see that. I see one client doing another DHCP request after 20 minutes.

Yes, that's only a partial log excerpt.

 

[ColinTaylor]

Yes, that's only a partial log excerpt.

There's a big difference between 20 seconds and 20 minutes.

Is the device connected to a guest network with Access Intranet disabled?

 

[sbsnb]

No. This happens to all 2.4G devices that try to connect. They are connecting to the "real" 2.4G SSID. They can't connect to the guest 2.4G. They get a "authentication problem" error.

 

[ColinTaylor]

The only thing I can suggest is to turn off the router and unplug it for 60 seconds before turning it back on. If that doesn't work then try the factory reset.

 

[sbsnb]

That's how I rebooted back when I first started troubleshooting. When I reboot the 2.4G clients connect and everything works for about 30 seconds and then it all dies again.