[grmcdorman]

I am having issues with the 2.4GHz WiFi becoming disabled after some period of up time. I can fix it by doing 'ifconfig eth1 down; ifconfig eth1 up'; when this is done it runs for another 30 to 60 minutes and then stalls again.

Hardware is a Netgear R7000P, I'm running the latest build: DD-WRT v3.0-r46772 std (05/26/21)

There are typically 7 or 8 devices on the 2.4GHz band:

1. A Canon MX532 printer.
   
2. One of a variety of Android phones or tablets.
   
3. Four Google Nest devices: a Nest Hello (video doorbell) and three Nest Protect (smoke detectors).
   

The 5GHz does not have this issue. There are typically four or so 5GHz clients.

On the wired LAN, there are two other survelliance cameras, one of which is normally streaming to a Synology server continuously (about 7FPS, 1920x1080 frames). This, technically, shouldn't cause any issue because it's Ethernet traffic. However, in the overnight test this traffic was not routed through the R7000P. I have turned off this streaming for now to see if it could be the issue.

2.4GHz is moderately crowded at this location, a residential suburb. At the router's location, I see r five or six channels overlapping, one 20MHz on channel 11, and a bunch below at variously 6, 4 (40MHz) and 3 (40MHz).

Transmit error counts are quite high:
Received 165434 OK, 25 errors
Transmitted 200704 OK, 19222 errors

Last time this happened, I was running pings to the Nest Hello; this is what happened:

64 bytes from 192.168.213.24: seq=1331 ttl=64 time=1.639 ms
64 bytes from 192.168.213.24: seq=1332 ttl=64 time=2.451 ms
64 bytes from 192.168.213.24: seq=1333 ttl=64 time=1.982 ms
64 bytes from 192.168.213.24: seq=1334 ttl=64 time=1.364 ms
64 bytes from 192.168.213.24: seq=1335 ttl=64 time=612.729 ms
64 bytes from 192.168.213.24: seq=1336 ttl=64 time=626.363 ms
64 bytes from 192.168.213.24: seq=1337 ttl=64 time=1628.891 ms
64 bytes from 192.168.213.24: seq=1338 ttl=64 time=3644.060 ms

after which the 2.4GHz stopped.

This is a brand-new R7000P; I performed initial setup yesterday evening and left it running overnight, with the old WRT1900AC V1 just acting as a switch. It seemed fine through the night. Then this morning I unplugged the WRT1900AC, moved R7000P to the spot occupied by the WRT1900AC, powered up, and upgraded to the latest build.

Following that, problems have been occurring continuously. I have tried a full reset and manual re-entry of settings to no avail.

Currently, 2.4GHz is configured as follows:

1. Regulatory Domain: Canada
   
2. AP
   
3. NG-Mixed
   
4. Channel 8 (seems to have least overlap)
   
5. SSID broadcast on
   
6. TurboQAM & Beamforming off
   
7. WPA2-PSK/CCMP-128 (AES), key renewal 3600 (defaults)
   

All other WiFi settings are at default, although I have tried settings as suggested in various threads here to no avail.

One workaround - which I'm not enamoured of - is to set up a cron job that pings one of the devices, and restarts the WiFi if it fails to respond. That's not a nice hack, though.

I would appreciate suggestions on how to diagnose and fix this.

[grmcdorman]

So, just to update here: I've had the surveillance streaming off for over an hour now - and the WiFi has been fine. The last hang was when I was fiddling with the streaming settings.

This makes me suspect the image streaming, even though it's on the wired network (through Ethernet over Powerline, actually). I'll perform more tests on the weekend. One possible factor, though, is that there is an access restriction rule for both cameras that is intended to block all outbound internet traffic (i.e. the rule contains two MAC addresses, with the 'deny' option set). It's filtered 0 packets, though.

Oh, and I'm running YaMon3. I currently have SFE on, though, so it's not picking up the traffic.

Would still appreciate suggestions. Perhaps a cheap gigabit switch so the camera traffic doesn't go through the router.

[grmcdorman]

Solved! But not sure how, I changed a lot of things. It does seem related to the surveillance video streaming, though. Most likely culprit, to my mind, is that the device was set to broadcast on one of the stream formats. Perhaps the broadcast packets made DD-WRT unhappy.

As part of doing this, I configured my DSL modem, an SR505N, to put three of the four ports on a separate VLAN, essentially. Turns out that it only has gigabit on port 1, though; the other three are 100MB. If anyone's interested in how to do this, let me know (although it's not strictly anything to do with DD-WRT).