Hi, In the scenario mentioned in the previous mail, we expect the association attempt from Extender’s STA interface would fail with the following conditions: 1. Extender's STA and AP interfaces locate on the same ieee80211_local which uses channel 44 and bandwidth 80MHz. 2. The channel configurations between RootAP’s and Extender's are different. (RootAP: Ch36/80MHz; Extender: Ch44/80MHz) 3. Our device allows only one channel context to exist on each ieee80211_local. (num_different_channels = 1 in mt76 driver, ref: https://github.com/openwrt/mt76/blob/master/mt7915/init.c#L30) When Extender's STA interface tries to associate with RootAP, the return value of ieee80211_link_use_channel is not 0 because the current channel context (ch44/80M) is not compatible with RootAP’s channel context (ch36/80M) and it cannot create a new channel context on Extender’s ieee80211_local because of the device limitation (num_different_channels = 1). 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. Since the control channels are different, downgrading the bandwidth cannot make ieee80211_link_use_channel to return 0. 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) 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. To avoid any undesirable bandwidth downgrading, when ieee80211_link_use_channel returns non-zero, we check the control channel before entering the loop of downgrading bandwidth. For other replies, please see the inline. On Wed, 2023-01-18 at 10:40 +0100, Johannes Berg wrote: > Hi, > > So I've looked at this patch a few times, but it just confuses me ... > > On Thu, 2022-12-22 at 17:13 +0800, Michael Lee wrote: > > When the link fails to use the channel, chandef's bandwidth will > > be > > downgraded without checking the control channel. > > The issue happens when the STA of an extender with limited channel > > context associates with a root AP operating on a different channel. > > > > Below is an example: > > > > ______________ ________________ > > | RootAP(ch36) | | Extender(ch44) | > > | | (ASSOC) | AP | > > | AP <-------------------- STA | > > |______________| |________________| > > > > - RootAP is operating on channel 36, while Extender is operating > > on channel 44 > > What does this matter? The extended is just a STA, no? Or are you > saying > it's important that the extender has a concurrent AP interface that's > on > channel 44? > > And if you say "ch36" or "ch44" that's just the control channel (I > guess), but what's the actual complete channel configuration? Our Extender contains one AP interface and one STA interface on the same ieee80211_local, and since our device allows only one channel context on each ieee80211_local, the AP and STA interface must operate on the same control channel. RootAP and Extender’s AP interface operate on different control channels (ch36 and ch44), with other channel configurations being the same (bandwidth 80MHz and center frequency 5210MHz) > > > - When associating with RootAP, Extender-STA downgrades the > > chandef's bandwidth to be compatible with any channels on the phy > > What do you mean by "on the phy" here? That's not mac80211 > terminology, > so not sure. Sorry for the ambiguous word, we mean the ieee80211_local structure. > > > - Finally, chandef's bandwidth is downgraded to 20MHz and > > the association fails > > > > In this patch, a control channel checking is added to avoid > > unnecessary > > bandwidth downgrading > > > > Signed-off-by: Michael Lee <michael-cy.lee@xxxxxxxxxxxx> > > --- > > net/mac80211/mlme.c | 24 ++++++++++++++++++++++++ > > 1 file changed, 24 insertions(+) > > > > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c > > index 0aee2392dd29..bc435e8508e2 100644 > > --- a/net/mac80211/mlme.c > > +++ b/net/mac80211/mlme.c > > @@ -4616,6 +4616,27 @@ ieee80211_verify_sta_he_mcs_support(struct > > ieee80211_sub_if_data *sdata, > > return false; > > } > > > > +static bool > > +ieee80211_check_same_ctrl_channel(struct ieee80211_sub_if_data > > *sdata, > > + const struct cfg80211_chan_def > > *chandef) > > +{ > > + struct ieee80211_local *local = sdata->local; > > + struct ieee80211_chanctx *ctx; > > + > > + mutex_lock(&local->chanctx_mtx); > > + list_for_each_entry(ctx, &local->chanctx_list, list) { > > + if (ctx->replace_state == > > IEEE80211_CHANCTX_WILL_BE_REPLACED) > > + continue; > > + if (ctx->mode == IEEE80211_CHANCTX_EXCLUSIVE) > > + continue; > > + if (chandef->chan == ctx->conf.def.chan) > > + return true; > > + } > > + > > + mutex_unlock(&local->chanctx_mtx); > > + return false; > > +} > > + > > static int ieee80211_prep_channel(struct ieee80211_sub_if_data > > *sdata, > > struct ieee80211_link_data *link, > > struct cfg80211_bss *cbss, > > @@ -4842,6 +4863,9 @@ static int ieee80211_prep_channel(struct > > ieee80211_sub_if_data *sdata, > > chandef.width == NL80211_CHAN_WIDTH_10) > > goto out; > > > > + if (!ret || !ieee80211_check_same_ctrl_channel(sdata, > > &chandef)) > > + goto out; > > Not sure I get how this is any different - you're describing a case > where "ret != 0" (because if ret == 0 nothing happens in the while > loop), so then you fail _anyway_? So what's the point? As described above, the first association fails as expected. However, after Extender's AP interface switch to the same control channel as RootAP, the Extender's STA associates with RootAP by only 20MHz instead of 80Mhz we expect. > > johannes > Best, Michael
