I tried to set up hostapd to do HT40-, but for whatever reason,
it's not sending any wmm_param options, so the stations will not
associate with HT40- enabled due to the check below.
Is it really *reqired* that wmm_param exist to enable HT mode?
From mlme.c:
if (elems.ht_info_elem && elems.wmm_param &&
(sdata->local->hw.queues >= 4) &&
!(ifmgd->flags & IEEE80211_STA_DISABLE_11N))
changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
cbss->bssid, ap_ht_cap_flags);
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 01/30/11 04:36, Johannes Berg wrote:
> On Sat, 2011-01-29 at 21:38 -0800, Ben Greear wrote:
>> I tried to set up hostapd to do HT40-, but for whatever reason,
>> it's not sending any wmm_param options, so the stations will not
>> associate with HT40- enabled due to the check below.
>>
>> Is it really *reqired* that wmm_param exist to enable HT mode?
>>
>> From mlme.c:
>> if (elems.ht_info_elem&& elems.wmm_param&&
>> (sdata->local->hw.queues>= 4)&&
>> !(ifmgd->flags& IEEE80211_STA_DISABLE_11N))
>> changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
>> cbss->bssid, ap_ht_cap_flags);
>
> 802.11n-2009 says it is required.
>
Having run into this same issue before, I considered adding some
default values for the case that wmm is not configured, but someone
tries to enable 802.11n, I just never decided where the best spot
for that would be. Should this sort of thing be a hostapd default
or somewhere in the cfg80211/mac80211 layer? I was thinking this
should be something that hostapd does.
As I see it, there are a few ways to prevent this problem:
1. Hostapd doesn't allow 802.11n to be enabled without wmm
2. Hostapd does allow 802.11n to be enabled without wmm, but uses
defaults
3. Hostapd doesn't care about this, and the kernel doesn't allow
802.11n without wmm
4. Hostapd doesn't care, but the kernel makes the correnctions
I believe 2 is the cleanest solution. So that the packets passed
from hostapd can make it through unmolested, and new hostapd versions
can work with older kernels. Any other solution I'm not thinking of?
Pat Erley
On Sat, 2011-01-29 at 21:38 -0800, Ben Greear wrote:
> I tried to set up hostapd to do HT40-, but for whatever reason,
> it's not sending any wmm_param options, so the stations will not
> associate with HT40- enabled due to the check below.
>
> Is it really *reqired* that wmm_param exist to enable HT mode?
>
> From mlme.c:
> if (elems.ht_info_elem && elems.wmm_param &&
> (sdata->local->hw.queues >= 4) &&
> !(ifmgd->flags & IEEE80211_STA_DISABLE_11N))
> changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
> cbss->bssid, ap_ht_cap_flags);
802.11n-2009 says it is required.
johannes
On 01/30/2011 01:36 AM, Johannes Berg wrote:
> On Sat, 2011-01-29 at 21:38 -0800, Ben Greear wrote:
>> I tried to set up hostapd to do HT40-, but for whatever reason,
>> it's not sending any wmm_param options, so the stations will not
>> associate with HT40- enabled due to the check below.
>>
>> Is it really *reqired* that wmm_param exist to enable HT mode?
>>
>> From mlme.c:
>> if (elems.ht_info_elem&& elems.wmm_param&&
>> (sdata->local->hw.queues>= 4)&&
>> !(ifmgd->flags& IEEE80211_STA_DISABLE_11N))
>> changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
>> cbss->bssid, ap_ht_cap_flags);
>
> 802.11n-2009 says it is required.
Do you know the pertinent section, or some keywords to search for? I'm
unable to find anything useful.
Also, from looking at utils.c, it seems that this wmm_param is
a vendor specific Microsoft thing? I don't see anywhere else that
wmm_param is assigned...
case WLAN_EID_VENDOR_SPECIFIC:
if (elen >= 4 && pos[0] == 0x00 && pos[1] == 0x50 &&
pos[2] == 0xf2) {
/* Microsoft OUI (00:50:F2) */
if (calc_crc)
crc = crc32_be(crc, pos - 2, elen + 2);
if (pos[3] == 1) {
/* OUI Type 1 - WPA IE */
elems->wpa = pos;
elems->wpa_len = elen;
} else if (elen >= 5 && pos[3] == 2) {
/* OUI Type 2 - WMM IE */
if (pos[4] == 0) {
elems->wmm_info = pos;
elems->wmm_info_len = elen;
} else if (pos[4] == 1) {
elems->wmm_param = pos;
elems->wmm_param_len = elen;
}
}
}
break;
Thanks,
Ben
>
> johannes
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Sun, 2011-01-30 at 09:34 -0800, Ben Greear wrote:
> On 01/30/2011 01:36 AM, Johannes Berg wrote:
> > On Sat, 2011-01-29 at 21:38 -0800, Ben Greear wrote:
> >> I tried to set up hostapd to do HT40-, but for whatever reason,
> >> it's not sending any wmm_param options, so the stations will not
> >> associate with HT40- enabled due to the check below.
> >>
> >> Is it really *reqired* that wmm_param exist to enable HT mode?
> >>
> >> From mlme.c:
> >> if (elems.ht_info_elem&& elems.wmm_param&&
> >> (sdata->local->hw.queues>= 4)&&
> >> !(ifmgd->flags& IEEE80211_STA_DISABLE_11N))
> >> changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
> >> cbss->bssid, ap_ht_cap_flags);
> >
> > 802.11n-2009 says it is required.
>
> Do you know the pertinent section, or some keywords to search for? I'm
> unable to find anything useful.
No, I got confused. 802.11n says an HT STA is a QoS STA (5.2.9), but in
practice WMM is tested/certified instead of QoS.
johannes
On Mon, 2011-01-31 at 09:35 -0800, Ben Greear wrote:
> > No, I got confused. 802.11n says an HT STA is a QoS STA (5.2.9), but in
> > practice WMM is tested/certified instead of QoS.
>
> So maybe we can remove that check for wmm_param, but put in a printk
> to warn users that their AP is probably mis-configured?
Yes, but there are hidden assumptions that WMM is available throughout
the code that we need to hunt down first -- I'm sure there are some in
the aggregation code for example since aggregation can only work when
QoS/WMM is enabled.
johannes
On 01/31/2011 03:03 AM, Johannes Berg wrote:
> On Sun, 2011-01-30 at 09:34 -0800, Ben Greear wrote:
>> On 01/30/2011 01:36 AM, Johannes Berg wrote:
>>> On Sat, 2011-01-29 at 21:38 -0800, Ben Greear wrote:
>>>> I tried to set up hostapd to do HT40-, but for whatever reason,
>>>> it's not sending any wmm_param options, so the stations will not
>>>> associate with HT40- enabled due to the check below.
>>>>
>>>> Is it really *reqired* that wmm_param exist to enable HT mode?
>>>>
>>>> From mlme.c:
>>>> if (elems.ht_info_elem&& elems.wmm_param&&
>>>> (sdata->local->hw.queues>= 4)&&
>>>> !(ifmgd->flags& IEEE80211_STA_DISABLE_11N))
>>>> changed |= ieee80211_enable_ht(sdata, elems.ht_info_elem,
>>>> cbss->bssid, ap_ht_cap_flags);
>>>
>>> 802.11n-2009 says it is required.
>>
>> Do you know the pertinent section, or some keywords to search for? I'm
>> unable to find anything useful.
>
> No, I got confused. 802.11n says an HT STA is a QoS STA (5.2.9), but in
> practice WMM is tested/certified instead of QoS.
So maybe we can remove that check for wmm_param, but put in a printk
to warn users that their AP is probably mis-configured?
Thanks,
Ben
>
> johannes
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Sun, Jan 30, 2011 at 12:41:05PM -0500, Pat Erley wrote:
> Having run into this same issue before, I considered adding some
> default values for the case that wmm is not configured, but someone
> tries to enable 802.11n, I just never decided where the best spot
> for that would be. Should this sort of thing be a hostapd default
> or somewhere in the cfg80211/mac80211 layer? I was thinking this
> should be something that hostapd does.
>
> As I see it, there are a few ways to prevent this problem:
>
> 1. Hostapd doesn't allow 802.11n to be enabled without wmm
I don't think that that would ever happen since as far as I can tell,
WMM is not required from 802.11n based on any standard or specification.
(Sure, there may be some non-IEEE certifications that require it, but
hostapd is not limited by such requirements; it just needs to allow one
to implement a device to meet such needs.)
> 2. Hostapd does allow 802.11n to be enabled without wmm, but uses
> defaults
What do you mean with "defaults" here?
> 3. Hostapd doesn't care about this, and the kernel doesn't allow
> 802.11n without wmm
My comment on (1) would apply here.
> 4. Hostapd doesn't care, but the kernel makes the correnctions
I don't think that that would be a good idea either and well, not really
at all suitable for the current design of where the HT/WMM IEs come from
for management frames in AP mode.
> I believe 2 is the cleanest solution. So that the packets passed
> from hostapd can make it through unmolested, and new hostapd versions
> can work with older kernels. Any other solution I'm not thinking of?
I do not fully understand what (2) is, but it may be close enough to
what I think would be a reasonable approach:
- for non-AP STA case, allows association with HT even if WMM (or IEEE
802.11 QoS) is not enabled (mac80211 change)
- for AP case, make hostapd default to enabling WMM with default EDCA
parameters if HT is enabled and there is no explicit configuration
for disabling WMM
- if WMM is explicitly disabled in hostapd.conf, allow IEEE 802.11n
to be enabled without WMM/QoS
The main focus here is to make it less likely for users to end up
configuring something they did not plan on doing while not removing
flexibility in configuration. I don't know any particularly good reasons
for disabling WMM/QoS/aggregation, but that is not good enough
justification to make it impossible to do so.
--
Jouni Malinen PGP id EFC895FA