Periodic wireless/connectivity dropouts AC1450

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Author Message
jtbr
DD-WRT User


Joined: 09 Mar 2017
Posts: 100

PostPosted: Mon Mar 20, 2017 0:42    Post subject: Periodic wireless/connectivity dropouts AC1450 Reply with quote
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 Cool.

Does anybody have any ideas as to what might be going wrong?
Sponsor
jtbr
DD-WRT User


Joined: 09 Mar 2017
Posts: 100

PostPosted: Sun Mar 26, 2017 14:11    Post subject: Reply with quote
This bizarre problem continues.

Another note:

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.
mwchang
DD-WRT Guru


Joined: 26 Mar 2013
Posts: 1858
Location: Hung Hom, Hong Kong

PostPosted: Mon Mar 27, 2017 16:22    Post subject: Reply with quote
Did you try different channels in Basic Setup -> Wireless, including option "AUTO"?

Wbat about the transmit power?

_________________
Router: Asus RT-N18U (rev. A1)

Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!

Facebook: https://www.facebook.com/changmanwai
Website: https://sites.google.com/site/changmw
SETI@Home profile: http://setiathome.berkeley.edu/view_profile.php?userid=211832
GitHub: https://github.com/changmw/changmw
Xeon2k8
DD-WRT Guru


Joined: 11 Feb 2016
Posts: 1288

PostPosted: Mon Mar 27, 2017 19:09    Post subject: Reply with quote
mwchang wrote:
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)
ghoffman
DD-WRT User


Joined: 03 Jan 2010
Posts: 453

PostPosted: Mon Mar 27, 2017 19:19    Post subject: Reply with quote
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.
jtbr
DD-WRT User


Joined: 09 Mar 2017
Posts: 100

PostPosted: Tue Mar 28, 2017 13:38    Post subject: Reply with quote
Thanks for the ideas.

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.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum