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.
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.
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.
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.
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:
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.
@anon4457646 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.