Monitor "Dynamic Frequency Selection" (DFS)?

Question

My Linux PC is connected to a Wi-Fi access point. It is currently on channel 124:

# iw dev wlp2s0 link
Connected to e0:10:7f:1f:d0:5c (on wlp2s0)
    SSID: _The Cloud
    freq: 5620

In my regulatory domain, channel 124 legally requires DFS. At least one source says this channel is "potentially impacted by weather radar".

I believe DFS could potentially prevent my PC from connecting on this channel. Now that I am connected on a DFS channel, can I monitor/view any actions my system takes to satisfy the DFS regulations?

E.g. does iw event show specific event(s) related to this?

I have no control over the access point.

I am using NetworkManager to manage my Wi-Fi connection.

EDIT: Rui asked about my PC's Wi-Fi regulatory settings, so I ran iw reg get. For whatever reason, I have now been kicked to a non-DFS channel (in 2.4Ghz). Hopefully nothing is screwing up the regulatory settings at the same time.

I.e. at the moment, it appears to confirm that my Wi-Fi client considers channel 124 (5620Mhz) to be a DFS channel. And I expect this has not changed, compared to when I was connected on this channel.

I don't have any reason to think these reg settings are causing a problem for me. I also found a little description about what "phy#0 (self-managed)" means.

$ iw reg get
global
country GB: DFS-ETSI
    (2402 - 2482 @ 40), (N/A, 20), (N/A)
    (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
    (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
    (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0 (self-managed)
country 00: DFS-UNSET
    (2402 - 2437 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
    (2422 - 2462 @ 40), (6, 22), (N/A), AUTO-BW, NO-80MHZ, NO-160MHZ
    (2447 - 2472 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
    (2457 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-80MHZ, NO-160MHZ, PASSIVE-SCAN
    (5170 - 5190 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5190 - 5210 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5210 - 5230 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5230 - 5250 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5250 - 5270 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5270 - 5290 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5290 - 5310 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5310 - 5330 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5490 - 5510 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5510 - 5530 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5530 - 5550 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5550 - 5570 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5570 - 5590 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5590 - 5610 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5610 - 5630 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5630 - 5650 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5650 - 5670 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5670 - 5690 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5690 - 5710 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5710 - 5730 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5735 - 5755 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5755 - 5775 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
    (5795 - 5815 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
    (5815 - 5835 @ 20), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-HT40PLUS, NO-80MHZ, NO-160MHZ, PASSIVE-SCAN

I know you can see it in the regulatory source ching files. But that begs the question, have you told the WiFi chipset to set your country? Not sure it is done by default, I had to set it on my openwrt and also on my Debian — Rui F Ribeiro, Apr 04 '19 at 13:59
@RuiFRibeiro since you ask, here is `iw reg get`. Although I have now been kicked to 2.4Ghz for some reason. I hope that the reg setting is not being messed about at the same time. — sourcejedi, Apr 04 '19 at 14:16
@RuiFRibeiro I've edited in case I was not clear enough. This question is specifically interested in monitoring changes required by DFS, *after* I know I am connected on a DFS channel. (But before you asked, I had not thought to confirm that my Linux PC considered it a DFS channel. Thanks for your comment!) — sourcejedi, Apr 04 '19 at 14:44
`iw reg set PT` ; `pre-up iwconfig wlan0 freq 5.3G` ; ; and yeah, the pesky thing about the WiFi protocols is that the clients are also transmitters.... (I also noticed that 2.4GHz default thing, forcing it here to 5GHz....) — Rui F Ribeiro, Apr 04 '19 at 14:54
@RuiFRibeiro I don't understand what you are trying to say about this question. Neither `iw reg set` nor `iwconfig wlan0 freq` are monitoring tools. I am using NetworkManager on Fedora, so I have absolutely no `/etc/network/interfaces` to put a `pre-up` line in :-). The country code shown in `global` is correct for me, certainly I have no plan to try setting it to Portugal and see what happens :-). — sourcejedi, Apr 04 '19 at 15:05
Never said they were, just commenting, and that is my CC ;) btw, if you have a Mac, it has a free Wifi monitoring capture tool, cant recall how to invoke it without having one nearby (at home) — Rui F Ribeiro, Apr 04 '19 at 15:05
@RuiFRibeiro I mean, I assume you were providing *some* information you felt was related to the question. But I can't work out, what are you trying to tell me? FWIW my ultimate hope with this question is to see if there are some techniques I can learn, regarding my current, temporary, slightly flaky Wi-Fi connection. — sourcejedi, Apr 04 '19 at 15:28
@RuiFRibeiro AFAICT my client is quite capable of using this DFS channel. It did select it at one point. And I have no reason to think the reg settings fluctuate to prevent it. It might be DFS working as designed; it might be something else. I have no need to override it if it is DFS. I don't really want to set the DFS frequency using `iwconfig` / `iw` - I don't know how that will interact with DFS, I don't know if there *is* any sensible way for it to interact with DFS, and the ideal way for me to inspect any interaction of it with DFS would be an answer to this question :-). — sourcejedi, Apr 04 '19 at 15:35
I think in the US you have a set of frequencies and channels set aside for DFS. If I am not wrong, just looking at iwconfig or Wifi sniffer you know you are using it. As for *detecting* if you are using it, I think DFS is only about turning it off if it detects other transmissions in that frequency. Would it work generating it with another equipment? — Rui F Ribeiro, Apr 04 '19 at 15:53
I also suspect that "radar detection and avoidance" (first link) simply means you can't use that channel if a radar is using it. I would like to know if the Wi-Fi system thinks there is a radar and e.g. switches from my current channel to 2.4ghz because of that. That is my question (but maybe there is no way to tell). I don't *think* I have a license to operate a radar, so that I can see how `iw event` reports it :-P. — sourcejedi, Apr 04 '19 at 18:27

TooTea · Accepted Answer · 2019-04-04T20:01:33.557

In an Infrastructure network, handling DFS is up to the AP. If it detects radar pulses on the channel it wanted to use, it will just pick a different channel and otherwise continue working as usual. Thus the only thing you will notice on a client is that it's connected to the network on a different channel than the usual one. If the AP switches the channel while you're connected to it, it will notify all clients to switch as well, and you'll see that in iw event as ch_switch_notify.

Let's imagine that your Linux machine is the AP (or a mesh node), so that it's actually in charge of DFS. First thing it does when bringing up the network is to run the CAC (channel availability check), which means waiting for a specified time for radar pulses before transmitting anything. If no pulses are detected on the selected channel, the network will come up as usual. (If you have ever wondered why the wireless takes ages to come up when you reboot the router, this is why.)

Afterwards, the firmware/driver keeps an eye out for special radar pulse signatures and if it detects them, it triggers the DFS procedure (marks the channel unavailable and picks a different one). You could see that in iw event as xxx MHz: radar detected.

If you want to learn all the gory details, take a look at the Linux Wireless Wiki.

Thanks! I think I searched their `iw` page for "dfs", but I didn't try searching the wiki as a whole :-). — sourcejedi, Apr 04 '19 at 19:44
Do you know if `iw event` on the client will show the change of channel as "unknown event 88 (ch_switch_notify)" ? (Or equivalent, if/when someone teaches `iw` what event 88 is). [I learned about this event from seeing it on non-DFS channels](https://unix.stackexchange.com/questions/510574/frequent-channel-switching-any-client-only-diagnostics) — sourcejedi, Apr 04 '19 at 19:51

Monitor "Dynamic Frequency Selection" (DFS)?

1 Answers1

Linked