Posted: Mon Mar 20, 2017 0:42 Post subject: Periodic wireless/connectivity dropouts AC1450
I've had a frustrating problem that has been puzzling me for a while. Every hour or two roughly, connectivity to the router breaks down. I can no longer ping the router from clients. But the wifi connection stays up and clients claim that the connection is strong. This situation lasts for 30 seconds to 2 minutes, and then resumes working normally. I can't make any sense of it. It also appears that the router is responsive to the outside world during this time.
I have a Netgear AC1450 and this has affected all recent Kong builds I have tried (since 29xxx at least). My Wifi has pretty standard settings and the issue appears to affect both 2.4ghz and 5 ghz radios. I don't overclock or modify transmit strength. I am not able to confirm whether it also affects wired connections as I am rarely connected via cables. I use WPA2-AES encryption and had suspected that this might have to do with key renewal, but increasing the renewal interval to 8x normal (28800s) did not seem to noticeably decrease the frequency of this issue. While my router setup is somewhat complex, with jffs, openvpn server and client running, as well as custom lighttpd, cpu loads are low as is traffic generally. The router does not have a fan, and these (current) temperatures are pretty typical: CPU 76.9 °C / WL0 48.5 °C / WL1 54.1 °C
The one other hunch I had is that somehow using virtual interfaces is related to this issue. I have one on each band (wl0.1 and wl1.1), and before I added them a few months ago, I hadn't noticed this issue. Although it's possible I just was more tolerant .
Does anybody have any ideas as to what might be going wrong?
While it has affected more than just one client, I have now confirmed that some clients CAN ping the router during periods when others cannot. That would seem to indicate some sort of problem with the affected clients. EXCEPT that pings during the period of failure can be much delayed. In particular, shortly before the router becomes newly available again to affected clients, the pings from unaffected clients suddenly jump to latencies of 2400 milliseconds or so, twice in a row, compared with the norm of 1-10ms. This seems to indicate that something strange is indeed happening on the router side.
I do not notice a major spike in CPU utilization on the web GUI however, and there is nothing happening in the syslog.
Did you try different channels in Basic Setup -> Wireless, including option "AUTO"?
Wbat about the transmit power?
Neither Auto nor transmit power are advised to be used. Channel is always better a fixed one and transmit power is only useful to fine tune if you have several routers in your house that might collide between them in the same channel.
---
Have you tried with basic settings for a few days? Without virtual networks and all that? Have you done erase nvram? _________________ R6400v2 (boardID:30) - Kong 36480 running since 03/09/18 - (AP - DNSMasq - AdBlocking - QoS) R7800 - BS 31924 running since 05/26/17 - (AP - OpenVPN Client - DNSMasq - AdBlocking - QoS) R7000 - BS 30771 running since 12/16/16 - (AP - NAS - FTP - SMB - OpenVPN Server - Transmission - DDNS - DNSMasq - AdBlocking - QoS) R6250 - BS 29193 running since 03/20/16 - (AP - NAS - FTP - SMB - DNSMasq - AdBlocking)
i have experienced similar issues with 2x r6300v2 as AP running a series of kong builds. my setup hass virtual wireless on each band on each router. each router broadcasts two SSID, and each SSID, encryption and key is the same on both bands and on both routers. thus a client can connect to SSID1 or SSID2 on either 2.4G or 5G band, on either AP. this is to facilitate seemless roaming, and to facilitate two populations of clients, one of which migrated from another facility.
i suspected that the problem might be from clients trying to negotiate connections from one band to another, or from one AP to another.
as an addtional finding: the mis-behaving AP may respond to ping, but may not be accessible by telnet, ssh, or via the gui. wired connections from clients that still maintain network access via the other AP also fail to access the GUI or other interfaces. the solution has been power cycle.
I hope I'm not speaking too soon, but I may have stumbled upon the cause. For the last day or so I've tried an experiment by disabling explicit beamforming on the 5ghz band (implicit beamforming was already disabled), as well as disabling multicast optimization on all bands & vaps. So far, I have not noticed the dropouts that used to be quite common.
To be honest I still don't know what the multicast optimization is supposed to do (and couldn't find documentation), but I suspect the culprit is not that but the explicit beamforming, for whatever reason (the specs for the AC1450 suggest that it does support this).
As for your other suggestions, I'm using fixed channels right now, as I'd also heard they are more reliable. They are 2.4Ghz - channel 1 (20mhz width, which works better than wider ones as I am in a fairly congested radio-space, particularly at 2.4Ghz), and 5Ghz channel 161 upper upper (80Mhz channel width) - there seems to be no contention with nearby APs at this frequency.
Transmit power is set to auto. I suppose I could experiment with lowering this if things go sour again.
I have reset nvram and rebuilt my settings, but I got the same results before and after. I've also tried various builds but have now settled on 30700m for the time being. Trying only the basic settings is also a good idea, but I'm now hoping I won't have to go there.
Now I'm wondering if I should try implicit beamforming, and what the use cases for these really are. Once I'm a bit more confident that the issue really has gone away, I'll also try to re-enable multicast optimization to confirm that wasn't the cause and that it was indeed the explicit beamforming.