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?
> 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?
or
2) the ifmgd->flags are not reset correctly for a new association?
johannes
