[PATCH 1/3] hostapd: Fix VHT unsolicitated channel switching
ilan.peer at intel.com
Wed Mar 19 04:17:39 EDT 2014
> >> >> + /* FIXME: It's impossible to tell how exactly an unsolicitated
> >> >> + * switch downgraded channel definition in all cases. */
> >> >> + if (width == CHAN_WIDTH_80 ||
> >> >> + width == CHAN_WIDTH_80P80 ||
> >> >> + width == CHAN_WIDTH_160)
> >> >> + hapd->iconf->ieee80211ac = 1;
> >> >> + if (!ht)
> >> >> + hapd->iconf->ieee80211ac = 0;
> >> >> +
> >> >
> >> > As far as I understand the ieee80211ac variable states weather
> >> > 80211ac is
> >> enabled or not, and thus I do not think that it should be changed
> >> based on the actual operating mode/channel width.
> >> You could apply this for ieee80211n, yet, it is possible for channel
> >> switch to change it.
> > I would consider this a wrong behavior. For example if 80211ac was enabled
> at first, and disabled due to this change, then a subsequent request to CS
> (for example due to DFS), would not allow to switch to VHT.
> I get your point. For this to be handled perfectly you probably need to have
> hostapd to have an additional variable to describe whether 11ac is actually
> enabled, or not (while the other says if it's ever okay to use 11ac). The same
> would be necessary for ht_capab with [HT40+/-] flag. This can prove to be
Yep ... hope it is not that tricky :)
> >> > Regardless, how is it possible that the CS ended with being on VHT
> >> > if hostap
> >> did not ask to use VHT in the first place?
> >> >
> >> Technically a driver can call cfg80211_ch_switch_notify() with any
> >> It's not a necessity for an actual CSA to be requested first.
> > But what's the use case? Is this for actual CS or only for bandwidth change?
> Might be my misunderstanding, but I did not expect a CS to be triggered
> without the knowledge of wpa_supplicant/hostapd as this might break
> things if wpa_supplicant/hostapd also try to trigger CS without the
> This very patch is probably least important of the three. I don't know if
> there's any driver that can do such unsolicited CS. For explicit CSA bandwidth
> change (i.e, chan_switch) there are patches [2/3] and [3/3].
Will have look at the others :) ... other than that, even a bandwidth change requires that CSA/eCSA would include the WB channel switch IEs etc.
> > In addition such change should also involve changing some of the IEs etc.
> Good point. Unsolicited CS doesn't seem to update beacons.
> ieee802_11_set_beacons() is called only if a CSA was requested earlier.
> Perhaps it should be called regardless?
I think that this will only cause a mess without proper support in the stack and would avoid it ...
More information about the HostAP