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

Installing and Using OpenWrt Network and Wireless Configuration
5

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

2 Likes
6

Good point.

7

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 ?

8

@redfast00 what kind of device you have?

9

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
10

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.

3 Likes
11

We have an ASUS RT-AC58U

12

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?

13

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

14

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

15

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.

16

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
17

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

18

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

19

sure it will happen if radar detectcion will be up

20

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

21

i cannot post it here, admin will ban me, and i do not want that

22

that will never happen with openwrt, just change the mac address of wwan or ap and they never can do that

23

Worst case you could write a script that checks if the radio is operating on a channel other than 60, and shuts it down if it is.

24

They are very serious about this: we're the only ones operating an access point, we've gotten a complaint about this before and I suspect they might own radio direction finding equipment. Just changing the MAC address is not sufficient to stop them. As I stated in the original post, fighting them on this will not work. I'm looking for a technical solution to prevent our AP from sending outside of channel 60, without disabling DFS.