I have 2 UniFi APs running a recent master build close to each other, 5GHz only, they both broadcast the same SSIDs for better coverage. What's a good strategy for picking channels in the lower channels 36-64? Note that for this purpose I do not want anything in the 149 channel and higher as I have another AP on 149@80MHz and want to keep the upper channels clear.
Set both APs to ch 36@80MHz and hope for the best. Doesn't sound ideal as they would be talking over each other and also who knows what the clients decide to connect to.
Set 1 AP on ch 36@40MHz and the other on ch 48@40MHz, no overlap, no DFS. It will reduce the bandwidth on each AP but that might be OK given the clients use pattern.
Set 1 AP on ch 36@80MHz and the other on ch 64@80Mhz. But this will put the 2nd AP in the DFS 52-64 channels. This is how I currently have it configured but the 2nd AP lost its WiFi earlier today, I had to reboot it, couldn't get WiFi back any other way. I think it correlates with a DFS-CAC-START message in the log, but I'm not sure yet. I doubt it really discovered any radar, it's more like it started scanning and never recovered, perhaps some bug. Cannot tell for sure, just speculation at this point, I'm monitoring to see if it does it again.
Any safe strategies/suggestions are appreciated. Thanks.
I cannot comment on what channels you should pick, I'd gravitate towards DFS since that offers more channels either way, but if you happen to be on a channel with lots of radar activity, you'll get booted often as well. So that's something to keep in mind, although multiple APs will mitigate the outage if they partially overlap. After experiencing multiple DFS radar events (which basically killed my network since I had no fallback channels configured), I predefined a list of channels: two DFS, one regular, and ever since I haven't had any real issues.
Thanks for the pointer. In my case I don't see anything in the log that it detected any radar, but there still might be a bug that it doesn't recover from scanning. I'm not even sure how often it scans for radar under normal operation once on a DFS channel or what impact that has.
Interesting about the auto + channels options, never used auto before. Not sure when auto is applied, at boot only, at boot and then during normal operation once in a while, only when radar is detected?
When used in conjunction with the channels list, hostapd will consult the list when it detects a radar event on the channel it's listening on. I don't think it matters whether it's at boot, or during normal operation. I believe it's scanning for radars periodically.
Using DFS is usually a good idea, if only for the reason that less APs can do it properly - leaving the air waves to yourself. In case you are in proximity of a radar installation, you'll get to know which channels to avoid in due time (e.g. I can't use channels 52-64 because of frequent DFS events in my location, all others are fine)
Question on using this... is there a way to scan or monitor for radar activity across the DFS band, or do you have to try channels and see if you get booted?
I know its supposed to be dynamically detecting and moving channels, but it sounds like, as with some other features, sometimes it ain't as graceful as its supposed to be. (If it even works!)
The later.
Before tuning into a DFS channel, the kernel needs to wait and listen for radar events for (at least) 60s, if you're close to a source emitting DFS events you'll see that rather quickly. If you're farther away, it might take a little longer for the kernel to notice - but you'll typically know within somewhere between a couple of hours to a couple of days.
That depends on how you look at it, yes, in case of a DFS event, the kernel must vacate the affected channel(s) immediately, this does necessarily cause a service interruption (depending on the question if hardware and regionally regulatory rules allow background scanning in advance, you have to cater in for another 60s scanning times, plus the delays of your clients reconnecting), but you aren't going to see this regularly (unless you insist on using a channel that's known to by used by radar installations around you). Once the dust has settled, you'll know which channels are clear and which might be problematic.
Predominantly weather radars, but not exclusively restricted to those.
Radars are rather long range (they transmit with a lot of power), you can expect those to be present in the vicinity of airports (civil and military), ports (civil and military), military installations with air traffic control tasks - and large installations of the weather services or research departments (although the later two typically use the data from existing airports). At least ports and civil airports are often not too far away from urban environments.
Drivers must err on the side of caution. Detecting interference on DFS channels is easy, but distinguishing between just random noise and radar patterns is not. Driver (and firmware-) implementations differ a lot in this regard, funnily enough the worst performance I've seen in this regard are very current commercial Broadcom devices. So yes, false positives are likely.
Any known bugs in ath10k-ct for a UniFi AP (ath79) that may cause wifi to just "die" during/after a scan?
I noticed this in the log daemon.notice hostapd: wlan0: DFS-CAC-START freq=5320 chan=64 sec_chan=-1, width=1, seg0=58, seg1=0, cac_time=60s
Then nothing else, no DFS-CAC-COMPLETED that I normally see after a reboot. WiFi just disappeared. I tried wifi down && wifi up and couldn't get it back. I had to reboot the AP. I now read in a different thread that maybe I should have restarted wpad too.
Constantly (on the current channel), without interruptions (it's a pattern filter weeding through all incoming traffic).
The purpose of background scanning is not to check for DFS events (as mentioned above, that happens continuosly on the active channel, before even decoding the received signals into packets), but to have a (supposedly) clean channel on standby, to reduce the mandatory 60s listening after a DFS related channel switch.
That depends on the hardware (driver and firmware) - and the regulatory domain (ath10k has only learned it for ETSI within the last ~year). It's usually non-zero, but negligible (there is a short period when the AP is not tuned to the active channel and would miss incoming packets, it's the driver's (&& firmware's && hardware's) job to minimize the impact.
As mentioned initially, it's trivial to write a DFS parser that satisfies regulatory scrutiny (expensive to get it certified, but trivial). All you need to do is bailing out immediately, whenever you receive anything you don't understand (interference from another AP on a slightly overlapping channel, some other wireless protocol, ...), the regulatory bodies are fine with the behaviour, you as the user probably won't (because it effectively means you can never keep using a DFS channel, even if there is no radar in sight). The regulatory bodies don't object against false positives, but your hardware must never -ever- allow false negatives.
Writing a good DFS filter, with a minimal amount of false positives and without taxing the hardware for these mandatory scanning however is hard (and needs cooperation from the hardware), so is optimizing its behaviour upon received DFS events (Linksys went as far as adding a third radio to their WRT3200ACM/ WRT32x merely for doing contiuous DFS scanning in the background, although they never managed to get it work, leaving it unused).
The AP on DFS ch 52-64 has been up for 3 days now without any wifi issues. I don't see any DFS or radar events in the log. Not sure what went wrong when its wifi went down, maybe it was something else that had nothing to do with DFS.