| Message ID | 1395146256-18815-4-git-send-email-michal.kazior@tieto.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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@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). Regards, Ilan.
On 19 March 2014 09:33, Peer, Ilan <ilan.peer@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@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.. For an unsolicited CS the beacon isn't updated (as with ieee80211ac update in patch 1/3) -- but it should be. Michał
> -----Original Message----- > From: Michal Kazior [mailto:michal.kazior@tieto.com] > Sent: Wednesday, March 19, 2014 11:02 > To: Peer, Ilan > Cc: j@w1.fi; hostap@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@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@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.
> > > > > > 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. > I meant that the fact that an AP should not change its supported capabilities is going to be addressed in the spec. Ilan.
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; + if (hapd->iface->csa_in_progress && freq == hapd->iface->cs_freq_params.freq) { hapd->iconf->ieee80211ac = hapd->iface->cs_freq_params.vht_enabled;
The HT Capabilities IE wasn't updated when HT width was changed. This could possibly confuse clients. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> --- src/ap/drv_callbacks.c | 5 +++++ 1 file changed, 5 insertions(+)