[PATCH 3/3] hostapd: Update ht_capab HT20/40 upon channel switch

[Peer, Ilan]

> -----Original Message-----
> From: Michal Kazior [mailto:michal.kazior at tieto.com]
> Sent: Wednesday, March 19, 2014 11:02
> To: Peer, Ilan
> Cc: j at w1.fi; hostap at lists.shmoo.com
> Subject: Re: [PATCH 3/3] hostapd: Update ht_capab HT20/40 upon channel
> switch
> 
> On 19 March 2014 09:33, Peer, Ilan <ilan.peer at intel.com> wrote:
> > Hi Michal,
> >
> >> The HT Capabilities IE wasn't updated when HT width was changed. This
> >> could possibly confuse clients.
> >>
> >> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
> >> ---
> >>  src/ap/drv_callbacks.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/src/ap/drv_callbacks.c b/src/ap/drv_callbacks.c index
> >> 9ed7601..3c6a376 100644
> >> --- a/src/ap/drv_callbacks.c
> >> +++ b/src/ap/drv_callbacks.c
> >> @@ -478,6 +478,11 @@ void hostapd_event_ch_switch(struct
> hostapd_data
> >> *hapd, int freq, int ht,
> >>       hapd->iconf->vht_oper_centr_freq_seg0_idx = seg0_idx;
> >>       hapd->iconf->vht_oper_centr_freq_seg1_idx = seg1_idx;
> >>
> >> +     if (offset)
> >> +             hapd->iconf->ht_capab |=
> >> HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
> >> +     else
> >> +             hapd->iconf->ht_capab &=
> >> ~HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
> >> +
> >
> > Same as in previous patch. In addition such a change only changes the
> internal interface configuration but does change the actual beacon (which
> was already configured as part of the csa flow).
> 
> I'm confused with the sentence.
> 
> For requested CSA we recalculate beacon IEs. Actually now that I think about
> it.. is this properly updated when constructing after_csa beacon for CSA
> request itself? Hmm..

Ieee80211-2012 spec., 10.15.4.1 states that:

" NOTE?The Supported Channel Width Set subfield transmitted by an AP is constant for the lifetime of its BSS as it is a
parameter of the MLME-START.request primitive".

I discussed this possibility of changing the HT/VHT capabilities of the AP during the lifetime of the AP with Johannes. He explained that generally an AP should not change its supported capabilities (still debatable in the 802.11 TG), unless explicitly stated in the spec. and expected to be clarified  in the spec.

> 
> For an unsolicited CS the beacon isn't updated (as with ieee80211ac update in
> patch 1/3) -- but it should be.
> 

I still think that this is a bad idea to have an unsolicited CS. 

Ilan.