Hi, Please see the inline. On Tue, 2023-03-14 at 08:42 +0100, Johannes Berg wrote: > Hi, > > > To deal with such an error case, Extender’s STA interface would > > downgrade the channel bandwidth (from 80MHz) and run > > ieee80211_link_use_channel to check again until the bandwidth > > becomes > > the minimum 20MHz. > > Correct, and then it fails. > > > Since the control channels are different, downgrading the bandwidth > > cannot make ieee80211_link_use_channel to return 0. > > Right. > > > Finally, Extender’s > > STA interface bandwidth (ifmgd->flags) would use 20MHz afterward. > > (In > > the current kernel version, the flag is link->u.mgd.conn_flags) > > Also correct, but does it matter? It matters because Extender's STA interface's ifmgd->flags is changed during bandwidth downgrading and remains changed to the next association. > > > At this moment, a hostapd_cli channel switch command might be > > issued, > > making Extender's AP interface switch to RootAP's channel (ch36). > > Because the control channel now synchronizes, Extender's STA > > association attempt succeeds. However, Extender’s STA ifmgd->flags > > remains in the fallback state and thus the operating bandwidth is > > 20MHz > > instead of 80MHz we expect. > > So ... still not sure I understand. > > Are you saying that > > 1) you have a race, and hostapd switches channels while the client- > side > code is in the middle of this loop? No, we think there is no race concern since the locks are well- maintained. So the steps are: First association fails -> hostapd switches channel -> second association succeeds (with STA operating on 20MHz) Every step starts after the previous step has finished. > > or > > 2) the ifmgd->flags are not reset correctly for a new association? Yes, our patch wants to solve this problem. Since there is no way to reset ifmgd->flags after bandwidth downgrading, we check the control channel before downgrading the bandwidth. If the control channels are different, we directly fail the association. > > > johannes Best, Michael
