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

login
register
mail settings
Submitter Michal Kazior
Date March 18, 2014, 12:37 p.m.
Message ID <1395146256-18815-4-git-send-email-michal.kazior@tieto.com>
Download mbox | patch
Permalink /patch/331405/
State Changes Requested
Headers show

Comments

Michal Kazior - March 18, 2014, 12:37 p.m.
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(+)
Ilan Peer - March 19, 2014, 8:33 a.m.
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.
Michal Kazior - March 19, 2014, 9:02 a.m.
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ł
Ilan Peer - March 19, 2014, 11:52 a.m.
> -----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.
Ilan Peer - March 19, 2014, 11:58 a.m.
> > >

> > > 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.

Patch

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;