[itwontbewe]

* thread can be deleted Key Renewal Interval issue was addressed in the sticky
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327595

[manoj]

Not an answer to your actual question, but...

I'd try playing with the "Key Renewal Interval" under the "Wireless Security" tab (turning it off by setting to 0 seconds or at least changing the period) to see if the frequency of disassociations changes. I didn't notice the "nas" daemon on my R7000 (non-P) restarting, but it did turn out to be the cause of my wireless connections breaking on hourly boundaries (only on 5 GHz in my case).

My understanding is that this is a Broadcom issue the devs can't fix, though I didn't have this problem with earlier Kong builds, so I wonder if reverting to an older driver would fix it (though I also don't know what other side effects that'd have).

[Alozaros]

--clear-on-reload
Whenever /etc/resolv.conf is re-read or the upstream servers are set via DBus, clear the DNS cache. This is useful when new nameservers may have different data than that held in cache. So how could clearing the DNSmasq cache will affect clients connection drops...?

if this was the source of the issue, all the other routers would have the same problem...unless its not very Dbus related...

you can dig in and start your kernel syslog and check for no-DBus reports...may be...this will out rule the Dbus issue related with clear on reload... i guess no-Dbus is only for ipv6, no idea for ipv4 and if Dbus is not breaking down dnsmasq for some reason...

also you can enable Dbus, if its compiled with it.. but, couldn't find how to disable it, so it may be not running untill its called...unless BS force enable it by default for ipv4/dnsmasq for R7000p

--enable-dbus[=<service-name>]
Allow dnsmasq configuration to be updated via DBus method calls. The configuration which can be changed is upstream DNS servers (and corresponding domains) and cache clear. Requires that dnsmasq has been built with DBus support. If the service name is given, dnsmasq provides service at that name, rather than the default which is uk.org.thekelleys.dnsmasq


i also guess it could be something else radio driver related...


on your R7000p if your devices are idle, so no traffic or not even anything connected to the R7000p, what is the output of:

tcpdump -nnS -i br0 !'port 22'

presume port 22 is your default port for SSh...

also on broadcom routers, fiddling with key renewal could help with client drops indeed...

does it happen for both type of clients wired and wireless ??

[itwontbewe]

thanks for the replies

i dont have a chance to test right now but will look into what was mentioned

*
i removed static leases from additional dnsmasq options and updated to the latest beta. i havent seen any disconnects in the 4 hours its been up so far.

they were using the below format

[itwontbewe]

i ran
tcpdump -nnS -i br0 !'port 22'

it looked like it might have been info about a neighbors router

mostly ......

* a portion which i could read looked like a wifi name i have seen before. on my phone i looked for wifi around me and didn't see that one. they probably aren't broadcasting the ssid anymore

is this normal/expected?

[Alozaros]

yep it seams its the same for any Broadcom based radio, using their proprietary radio driver...it captures some frames form the other radios around...channel doesn't matter and i believe, its a part of radio disconnects and reconnects behaviour once those alien frames become very intense...in my case later afternoon when everyone is back from work..

On my R7000 i decided to turn my WiFi off and added an old Atheros based WAP using one of R7000 LAN ports..believe or not this radio is fine...

But if your R7000P is stable after the update, even with those alien frames around, than no more problems for you...