5GHz: disabel DFS switching channels (not as bad as it sounds)

At our university where I'm a student, there's a rule that no non-university access points are allowed unless specific exemptions. We got such an exemption: we are allowed to have an access point, but we can only use channel 60 in 20 MHz bandwidth on the 5GHz band. We set the radio channel to channel 60 in LuCi, but one day got a very angry email, saying that our AP was configured to the wrong channel and was causing interference. Indeed, the config still said that it was on channel 60, but the channel of the radio interface was now channel (40, 44, 48? I don't recall). I learned that this might be because of DFS: if our AP detects radar signals, it moves channels, as to not interfere with the radar.

Is there a way to turn off channel switching? I'm okay if that means for example if that means turning off the radio for some time if radar is detected, but it should be absolutely avoided that the radio is switched to a different channel (the university WILL confiscate our AP if it uses the wrong channel). I'm looking for a technical solution, fighting the university on this will not work. Turning off DFS itself is not a good solution, since we don't want to interfere with the weather radar.

1 Like

Set option channels '60' (note that is channels with an s, not channel). This should cause the radio to shut down if radar is detected since no alternative channel is specified.

You may want to test this at an off-campus location first.

1 Like

Thank you for the fast answer! The config was:

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path 'platform/soc/a800000.wifi'
	option country 'BE'
	option legacy_rates '1'
	option channel '60'
	option htmode 'VHT20'

so it now becomes this, correct?

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path 'platform/soc/a800000.wifi'
	option country 'BE'
	option legacy_rates '1'
	option channel '60'
	option channels '60'
	option htmode 'VHT20'

Remove option channel entirely. Also option legacy_rates has no effect on 5 GHz. You can use option cell_density to restrict AP transmission to higher rates. That restricts the distance where a client can receive the AP, which is actually a good thing.

channels is a list, not an option
list channels '60'

2 Likes

Good point.

A few days ago, in another thread, someone talk about channels, and that gave me some ideas for my own config. So I read the documentation.

Shouldn't the option channel be set to auto, when using channels ?

@redfast00 what kind of device you have?

It doesn't need to be set to auto, combining the channels option with a fixed channel configuration is also a valid configuration since this commit (i.e. since OpenWrt 21.02). Restricting the channels that may be used after a DFS event is the exact use case where this makes sense.

3 Likes

For what it's worth... we have an athk9 device (dir-825 C1) using 22.03.2 on which we use WiFi just for admin purposes. We wanted it on DFS channels to be "out of the way" of primary channels. It has:

        option country 'CA'
        option channel 'auto'
        list channels '52 56 60 64 100 104 108 112 116 132 136 140'
        option htmode 'HT40'

Works like a charm. It avoids the non-DFS channels completely. They are not even used when asking for 'Channel Analysis' in LUCI.

Edit: oops... that was an old file. Spaces, not dashes.

2 Likes

We have an ASUS RT-AC58U

so let me get it right.
you need 5 ghz radio on channel 60 at 20 mhz and it never need change channel?
is that right?

That's correct. It can disable the radio for some time if it detects radar, but changing channels is not allowed.

ok give me some time, i'll try that tomorrow

have you solved that? I did, not the long way, but I found a short way, a work around.i'm busy whit some drivers that I'm drive me crazy. but as I promise I did it.

I used list channels '60' in the wireless config, the channel is correct for the time being. From what I can see from the system log in LuCi, no DFS events have taken place yet. The AP is in a basement, so it might be pretty well shielded from radar. In the original setup, the university only complained after a couple of days or weeks, which leads me to think that the DFS event that made the AP switch channels might have been a false positive and could have been interference falsely identified as radar instead of actual radar. Since this false positive might be rare, it might take some time I'm able to verify that the AP no longer switches channels.

1 Like

that's good, but that is not a real solution, anyway if you still have problems you can @bricco1981

@bricco1981 What do you mean by 'that is not a real solution'? Will it eventually switch channels again? We really can't afford to have that happen, the university will confiscate our access point.

sure it will happen if radar detectcion will be up

How did you fix it so it doesn't switch channels anymore?