3

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
11
  • 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 Apr 4 '19 at 13:59
  • 1
    @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 4 '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 4 '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....) Apr 4 '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 4 '19 at 15:05
1

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.

3
  • Thanks! I think I searched their iw page for "dfs", but I didn't try searching the wiki as a whole :-).
    – sourcejedi
    Apr 4 '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
    – sourcejedi
    Apr 4 '19 at 19:51
  • @sourcejedi Good point, I've edited it in.
    – TooTea
    Apr 4 '19 at 20:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.