[PATCH] supplicant: skip NOP channels

[Janusz Dziedzic]

czw., 19 mar 2026 o 18:27 Jouni Malinen <j at w1.fi> napisał(a):
>
> On Sun, Feb 22, 2026 at 10:36:50AM +0100, Janusz Dziedzic wrote:
> > In case we have AP run:
> >  - on same phy that supplicant
> >  - on different phy in current system
> > respect unavailable (NOP) channels and
> > don't try to assoc using this channel,
> > after AP will detect RADAR on such channel.
>
> This description feels a bit confusing.. Isn't this proposed a STA mode
> operation to avoid using channels that have been marked unavailable due
> to radar detection based on anything operating on the system (whether it
> happens to be the same phy or something else does not really matter for
> this). And isn't that "after AP will detect RADAR" supposed to be "after
> the AP has detected a radar"?
>
True.

> Why should a STA mode operation, i.e., a DFS client, follow NOP from
> local DFS owner operation? The rules for DFS owners may prevent that
> specific device from starting an AP mode operation for a certain time
> after having detected a radar, but that does not apply to other devices
> that might not have detected the radar, i.e., it does not apply to other
> APs that might be operating on the channel and to which the local STA
> interface might want to connect.
>
Yeah, my case is specific. I have OpenWrt and my phy0 have:
 - wlan0 - STA connected to owner on 52/80
 - wlan0.1 - AP1 - 52/80
 - wlan0.2 - AP2 - 52/80

At some point we detect radar locally on wlan0.1, so we mark 52/80 NOP.
We stop APs, but STA still connect. Still using same radio, that
support radar detection.
So, mainly multi-interface phy/radio/device used.
Question here, how this should behave in case of multi-interface device?


I could move this step to upper layer and disable supplicant network
after radar detection,
but still some prop drivers (that have channel management inside the
driver) simply block such
association for multi-interface phy.

BR
Janusz