RT-AC86U not able to authenticate or DHCPACK(br0) 2.4Ghz clients after 2-4 days (Merlin 384.8_2)

- DoS protection was enabled
- unreplied UDP timeout is set to 15 to help avoid potential NAT corruption with SIP clients
- 2.4 Ghz running at 53C, CPU at 69C
- -49 dBm on 2.4 Ghz ... it's not a signal strength issue
- it's also highly unlikely that it's an interference issue ... read below, please
- wireless MAC filtering is enabled ... yes, I know it doesn't necessarily help with security
- all clients are assigned static IPs
- Smart Connect is disabled
- 2.4 Ghz SSID is not the same as the 5 Ghz SSID (channels are also manually assigned after using inSSIDer)
- Bluetooth Coexistence is set to pre-emptive
- Nothing is attached to USB 3.0
- This is the second RT-AC86U I've tried where 2.4 Ghz clients drop but not because of wireless signal strength

Most 2.4 Ghz clients were dropping (all clients were unreachable over LAN) and not able to authenticate on some clients with "wrong password" errors. System logs don't show the block message when clients attempt to reconnect. The 2.4Ghz signal is still strong and broadcasting while the problem is occurring.

One client is a Logitech Harmony Hub, used with a Harmony Elite remote control. Another client is an Ecobee 3 thermostat running firmware version 4.2.0.394, which is the latest firmware according to Ecobee. Other clients connecting to 2.4Ghz, which I doubt are important, include three Wyze Pan Cams and some iPhones. Oddly, the Ecobee 3 was still showing as being connected and so were two Wyze Pan Cams, but the Ecobee 3 and all Wyze Pan Cams were unreachable over the LAN and weren't able to connect to WAN. The other Wyze Pan Cam simply wasn't listed in the client list under "view list" in Network Map.

First, I disabled DoS protection. That didn't seem to change anything with respect to trying to reconnect other devices manually back to 2.4 Ghz.

After about 20 minutes of looking at settings and router logs, I unplugged the Harmony Hub. That didn't seem to didn't seem to change anything with respect to trying to reconnect other devices manually back to 2.4 Ghz. I plugged the Harmony Hub back in.

Then I removed the Ecobee 3 thermostat from the wall and reconnected it. At that point, all 2.4Ghz clients automatically reconnected, first starting with Harmony Hub, an iPhone, and then the Ecobee 3, which takes a little while to boot up. DoS protection was still disabled at this point.

At no point was the router rebooted or turned off. At no point did 2.4Ghz signal drop and return. No microwaves were in use.

I've contacted Ecobee. The response I received indicated they have no idea. It doesn't seem coincidental that almost as soon as I unplugged and reconnected the Ecobee 3, all 2.4 Ghz clients reconnected and worked. I did come across a reddit thread that suggested contacting Ecobee in order to disable power saving mode in the Wi-Fi chip, but all newer Ecobee firmwares don't have the power saving mode issue. That Reddit thread was for an Ecobee 4, and this issue involves an Ecobee 3.

Does anyone have an idea what might be going on? This problem doesn't seem like 2.4Ghz is dying in the router, and this is the second one I've tried where the problem occurs by the fourth day. What would be causing DHCPACK not to be issued to any 2.4 Ghz client due to something involving the Ecobee 3 after 2-4 days?

Thank you for your response. The only thing I haven't done in that list is to delete previously saved Wi-Fi configurations on the clients. I'll do that now. I've not had this issue using Merlin firmware on older Asus routers. I understand that just because something worked on a different router doesn't mean it will work on a newer one.

I don't feel it's a signal strength or interference issue. Rather, it's something involving dhcp, but without system logs indicating a connection has been blocked or something else has been rejected, it's difficult to troubleshoot. If the issue involves the Ecobee and power saving mode, which shouldn't be enabled in the those thermostats using the latest firmware, then I guess I could try disabling WMM APSD to see if that helps.

The problem is something involving either an Ecobee 3 or a Logitech Harmony Hub not getting a DHCP ack after 2 to 4 days and blocking the rest of my 2.4 GHz clients from receiving dhcp acknowledgments as well.

2.4Ghz has been working fine for over 114 hours, but I also disabled "Enable WMM APSD" because I had a sneaking suspicion it was causing problems with Ecobee 3 thermostat and because I have a limited return window for testing purposes. I am going to test with "Enable WMM APSD" enabled this weekend.

Have you disabled Beamforming and Airtime Fairness? These resolves a large majority of connectivity issues with smart devices / IoT devices.

Click to expand...

The issue appears to have been Beamforming.
After I disabled Universal beamforming, the problem went away.
2.4Ghz has been up for over 152 hours without dropping any clients.
Thank you very much

For people with an Ecobee 3 and, perhaps, a Logitech Harmony Hub, disabling these three settings works for me for 2.4 Ghz:
1) Airtime Fairness, (to be fair, I had Airtime Fairness off and was still encountering problems)
2)Explicit Beamforming, and
3)Universal beamforming.

Well, I updated to Merlin 384.9 yesterday, and the problem returned today. I didn't do a factory reset after updating last night.

All clients either dropped 2.4Ghz or couldn't connect to the internet using it this afternoon.

I unplugged the Ecobee 3 from the wall and plugged it back in to see if all devices would reconnect again. They didn't.

I unplugged the Harmony Hub and plugged it back in. All 2.4 Ghz clients reconnected.

That's the complete opposite behavior from last time. I'm not positive whether both devices (Harmony Hub and Ecobee 3) are causing the problem or just one.

I'm not sure if I should save router settings, do a factory reset, and then restore router settings or if I should try disabling "Enable WMM APSD" again. I guess the easiest thing to try is disabling "Enable WMM APSD" again.