Automatic return to correct channel after DFS forced change

As in the subject - is there a way to somehow force it to e.g. redo DFS check every N min or so and come back to correct channel (if it's available).

I mean on hostapd/hostapd_cli/configuration level.

I can do simple cron/timer check and just call wifi command to restart, but wanted something more fine grained.

Also I tried doing it with chan_switch (via hostapd_cli), but no matter the combination of options, the only result of that attempt is FAIL (with no particularly useful info in the logs either: IEEE 802.11 CHAN_SWITCH VHT CONFIG 0x3).

The above was tested/trierd on ZyXEL NBG6817 with recent snapshots (but on standard kernel firmware - not candelatech's one).

It's ugly, as without an independent radio to pre-scan the channels, you probably have to bring the wireless down, at least as I understand the spec. From what I understand, you can't start transmitting on a channel until the DFS check is complete, which I believe is on the order of 60 seconds. Even if you "knew" that the channel was clear using a different radio or scan, I believe that the radio would still need its minute to check.

I'm also wondering about the utility of such an action. If the radio has determined that a channel is unusable because of DFS, why would this change in a "stable" way in the future?

Are you intentionally trying to jam a military radar?

That idea is very dangerous, illegal and bad for your general health/wellbeing - in most Nations...

I don't see anything even remotely like "retry DFS channel" in the self-documenting hostapd.conf upstream source.

I'm also wondering about the utility of such an action. If the radio has determined that a channel is unusable because of DFS, why would this change in a "stable" way in the future?

  • cause majority of time the channel is ok to use, this happens from once - twice per day, to once per week; thus:
  • there are multiple accesspoints here configured on disjoint channels, so it's nice to ask them to try to return to their prefered frequencies - otherwise one of the most practical features of 5ghz becomes a total moot point

This is, unfortunately, reality. There aren't a large number of consistently available channels for 802.11ac, especially for 80 MHz bandwidth (2 in the US) or even 40 MHz (4 in the US). See, for example, http://www.revolutionwifi.net/revolutionwifi/2013/03/80211ac-channel-planning.html

Are you intentionally trying to jam a military radar?

Well this is near middle of a big city, with 2 big shop centers nearby, in old building within concrete walls, with 10-20 dBm power. Even if I tried, I couldn't jam anything. What's even the point of the DFS in context of lower power indoor use ?

I watched some time ago a presentation about DFS, where guy was talking about kilowatt directional antennas mounted on roofs, but that's not my use case.

1 Like

The splatter that even a consumer device can cause is immense. Remember that the radar receiver is looking for reflections off rain drops or even clouds, or objects hundreds of miles/km away. 10-20 dBm is a huge signal level compared to those returns and its wideband nature basically obscures everything else, as it can't be "processed out" by the radar receiver.

See, for example http://www.ieee802.org/18/Meeting_documents/2007_Nov/WFA-DFS-Best%20Practices.pdf including these images on pages 13 and 14

Edit: See also https://journals.ametsoc.org/doi/pdf/10.1175/BAMS-D-15-00048.1

1 Like

And even if it could, it won't be, since the radar use was there first, takes precedence, and often involves long-term capital investment -- tens or hundreds of thousands of US-equivalent moneys per station, often with lifetimes of a decade or more.

1 Like