I thought I had a problem in the past solved but I was wrong. I am NOT using channels shared with radar and yet both 5 GHz radios disable at least once a month with the only solution being to flash another firmware, reflash OpenWRT and then restore the configuration which I knew worked. This is getting annoying and making me want to look at other firmwares because it is causing disruptions to file transfers to a NAS appliance on a regular basis. I need a PERMANENT solution to this problem or I am abandoning this firmware and going back to another one with similar features.
RAM/ flash exhausted, due to some (non-default-) logging running amok?
(check this first)
If somehow the config has changed over time, you need to find out how.
Check what's on the overlay in the broken state and compare (diff
) it to your known-good state.
5 GHz radios disabling after one month
and
are a bit at odds, what's the actual behaviour you're observing - is it always going down after after one month (pretty much exactly the same time) or just on average?
The difference is important here, the former might indicate some kind of overflow - the later 'just' some statistical maximum uptime without issues - it makes a difference for further debugging.
What do the logs (logread
, rather soon after the wireless has gone down) say (in the broken condition), something about DFS events being detected?
EDIT: originally misread this as r7800, but r8000 is brcmfmac.
You can test ath10k-ct vs ath10k, including different firmware versions for ath10k/qca9984 (kvalo has newer versions upstream).
DFS detection isn't an exact science, the law requires that it mustn't ever miss a radar event (no false negatives allowed) - while operational reliability gives incentives to avoid false positives, but the former is the hard no-go. This means 'weird' circumstances always stand a chance of being misdetected as radar event (and technically there could also be mobile radar installations (ships, planes, etc.) at play).
I have looked at logs and it leaves no trace I am trying automatic channel selection and seeing what that does. I am about five miles away from an airport with TDWS and the fact that this is shared just seems a bit weird to me, in my opinion the two should be mutually exclusive and operate in different parts of the radio spectrum. This problem did not occur with the stock firmware or with DD-WRT and started occurring when I flashed OpenWRT and even the most current version still has this problem.
The r8000 with its bcm4366 radios is a very early 802.11ac design and mediocre linux support at best… And early designs might have even worse DFS algorithms (and if you're in the vicinity of an airport, there is at least one radar installation within range).
I would suggest using a non-DFS channel for at least 6 weeks, if it doesn't happen again, you have an answer - if it does, there'd be a non-DFS reason.
Within the OpenWrt ecosystem (developers and users), the r8000 with its bcm53xx based BCM4709A0 SOC and BCM43602 brcmfmac wireless is a rather exotic specimen, with rather little testing exposure - not the best hardware for running OpenWrt. Disclaimer, I don't have practical experience with this hardware either.
I am trying that, two non DFS channels were automatically selected which were 5.785 GHz and 5.220 GHz I am beginning to think that given the technical description this is a hardware weirdness and not one with the firmware.
brcmfmac is a fullmac driver, this means the entire wireless handling (including DFS detection) is handled within Broadcom's proprietary firmware blob, there's very little (~nothing) that could be changed on OpenWrt's side.
The fact that this is an early chipset is not surprising to me as I bought this router years ago as a Black Friday special at Best Buy. Should I decide to consider a new 802.11ac router, are there any specific chipsets or routers to look for? It seems very clear that given the DFS issues it might be worth considering especially with my proximity to a major international airport which uses TDWS.
At this point 802.11ax is quickly surpassing 802.11ac based devices (e.g. a used r7800/ xr450/ xr500 would be a good example), so personally I'd look at mt7622+mt7915, filogic 830 or ipq807x based devices (e8450/ rt3200, TUF-AX4200 (RT-AX59U), dl-wrx36, …).
I have looked at 802.11ax devices and the prices are more reasonable than I thought so I could go that direction which would eventually result in me getting the right adapters. Are there any particular 802.11ax routers with chipsets which are supported by the current builds?