When testing with 60 stations, 30 against a netgear running HT40
and 30 against a cheap cisco AP, using HT20, I notice that the
stations on the netgear often choose NO_HT instead of HT40
for their channel type.
The root cause appears to be that the hti->control_chan is 15
in the ieee80211_enable_ht method.
Everything *should* be running on channel 11.
Is this just a bug with the AP, or could this be a local
issue?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Jan 28, 2011 at 4:43 PM, Ben Greear <[email protected]> wrote:
> My AP is an off-the-shelf Netgear:
> WNDR3700
>
> It's only rate configuration option is '300Mbps', which appears to
> turn on HT40.
>
> It is configured for channel 10 (for the packet capture) and actually
> passes traffic there. ?It's just this HT Info thing with (primary-channel ==
> (real_channel + 4))
> that seems wrong. ?Note that when I had the channel set to 11, it was
> reporting
> 15 for the primary channel in the HT info.
>
> Looks like a bug in that AP to me...but would be nice if there were a way to
> work around it, in case others have similar issues.
Set it to channel 6, then?
Yeah, I played with Netgear's APs (and D-Link's) for about 3 hours
before I put them down and never picked them up again. Performance,
configuration, reliability, etc., were horrible. I've found that
Apple APs work well, but really hostapd offers the best flexibility by
far.
Dan
On 01/28/2011 02:39 PM, Ben Greear wrote:
> When testing with 60 stations, 30 against a netgear running HT40
> and 30 against a cheap cisco AP, using HT20, I notice that the
> stations on the netgear often choose NO_HT instead of HT40
> for their channel type.
>
> The root cause appears to be that the hti->control_chan is 15
> in the ieee80211_enable_ht method.
>
> Everything *should* be running on channel 11.
>
> Is this just a bug with the AP, or could this be a local
> issue?
I sniffed on a separate machine (using ath9k NIC), and it agrees
that the beacon's control_channel is 14 (I have since set the AP to channel
10 instead of 11, but the control_channel remains 4 higher than expected.)
I'm attaching the pkt in pcap format as well.
(From wireshark):
Vendor Specific: 00:90:4c: HT Additional Capabilities (802.11n D1.00)
Tag Number: 221 (Vendor Specific)
Tag length: 26
Vendor: 00:90:4c
Tag interpretation: 802.11n (Pre) OUI
Tag interpretation: HT additional information (802.11n D1.00)
Tag interpretation: Control Channel 14
HT Additional Capabilities: 0x000F
.... .... .... ..11 = Extension Channel Offset: Extension Channel below control channel (0x0003)
.... .... .... .1.. = Recommended Tx Channel Width: Any channel width enabled
.... .... .... 1... = Reduced Interframe Spacing (RIFS) Mode: Use of RIFS permitted
.... .... ...0 .... = Controlled Access Only: PSMP only
.... .... 000. .... = Service Interval Granularity: 5ms (0x0000)
HT Additional Capabilities: 0x0008
.... .... .... ..00 = Operating Mode: Pure HT, no protection (0x0000)
.... .... .... .0.. = Non Greenfield (GF) devices Present: One or More HT devices are not GF capable
HT Additional Capabilities: 0x0000
.... .... .000 0000 = Basic STB Modulation and Coding Scheme (MCS): 0x0000
.... .... 0... .... = Dual Clear To Send (CTS) Protection: Regular use of RTS/CTS
.... ...0 .... .... = Secondary Beacon: Primary Beacon
.... ..0. .... .... = L-SIG TXOP Protection Support: Not full support
.... .0.. .... .... = Phased Coexistence Operation (PCO) Active: PCO is not activated in the BSS
.... 0... .... .... = Phased Coexistence Operation (PCO) Phase: Switch to 40MHz phase/keep 40MHz
Rx Supported Modulation and Coding Scheme Set (VS): MCS Set
Tag interpretation: Rx Modulation and Coding Scheme (One bit per modulation)
.... .... .... .... .... .... 0000 0000 = Rx Bitmask Bits 0-7: 0x00000000
.... .... .... .... 0000 0000 .... .... = Rx Bitmask Bits 8-15: 0x00000000
.... .... 0000 0000 .... .... .... .... = Rx Bitmask Bits 16-23: 0x00000000
0000 0000 .... .... .... .... .... .... = Rx Bitmask Bits 24-31: 0x00000000
.... .... .... .... .... .... .... ...0 = Rx Bitmask Bit 32: 0x00000000
.... .... .... .... .... .... .000 000. = Rx Bitmask Bits 33-38: 0x00000000
.... .... ...0 0000 0000 0000 0... .... = Rx Bitmask Bits 39-52: 0x00000000
...0 0000 0000 0000 0000 0000 000. .... = Rx Bitmask Bits 53-76: 0x00000000
Highest Supported Data Rate: 0x0000
.... .... .... ...0 = Tx Supported MCS Set: Not Defined
.... .... .... ..0. = Tx and Rx MCS Set: Equal
.... .... .... 00.. = Tx Maximum Number of Spatial Streams Supported: 1 spatial stream (0x0000)
.... .... ...0 .... = Unequal Modulation: Not supported
HT Information (802.11n D1.10)
Tag Number: 61 (HT Information (802.11n D1.10))
Tag length: 22
Primary Channel: 14
HT Information Subset (1 of 3): 0x0F
.... ..11 = Secondary channel offset: Secondary channel is below the primary channel (0x03)
.... .1.. = Supported channel width: Channel of any width supported
.... 1... = Reduced Interframe Spacing (RIFS): Permitted
...0 .... = Power Save Multi-Poll (PSMP) stations only: Association requests are accepted regardless of PSMP capability
000. .... = Shortest service interval: 5 ms (0x00)
HT Information Subset (2 of 3): 0x0008
.... .... .... ..00 = Operating mode of BSS: All STAs are - 20/40 MHz HT or in a 20/40 MHz BSS or are 20 MHz HT in a 20 MHz BSS (0x0000)
.... .... .... .0.. = Non-greenfield STAs present: All associated STAs are greenfield capable
.... .... .... 1... = Transmit burst limit: 2.4 GHz - 6.16 ms | All other bands - 3.08 ms
.... .... ...0 .... = OBSS non-HT STAs present: Use of protection for non-HT STAs by overlapping BSSs is not needed
0000 0000 000. .... = Reserved: 0x0000
HT Information Subset (3 of 3): 0x0000
.... .... ..00 0000 = Reserved: 0x0000
.... .... .0.. .... = Dual beacon: No second beacon is transmitted
.... .... 0... .... = Dual Clear To Send (CTS) protection: Not required
.... ...0 .... .... = Beacon ID: Primary beacon
.... ..0. .... .... = L-SIG TXOP Protection Full Support: One or more HT STAs in the BSS do not support L-SIG TXOP protection
.... .0.. .... .... = Phased Coexistence Operation (PCO): Inactive
.... 0... .... .... = Phased Coexistence Operation (PCO) Phase: Switch to or continue 20 MHz phase
0000 .... .... .... = Reserved: 0x0000
Rx Supported Modulation and Coding Scheme Set: Basic MCS Set
Tag interpretation: Rx Modulation and Coding Scheme (One bit per modulation)
.... .... .... .... .... .... 0000 0000 = Rx Bitmask Bits 0-7: 0x00000000
.... .... .... .... 0000 0000 .... .... = Rx Bitmask Bits 8-15: 0x00000000
.... .... 0000 0000 .... .... .... .... = Rx Bitmask Bits 16-23: 0x00000000
0000 0000 .... .... .... .... .... .... = Rx Bitmask Bits 24-31: 0x00000000
.... .... .... .... .... .... .... ...0 = Rx Bitmask Bit 32: 0x00000000
.... .... .... .... .... .... .000 000. = Rx Bitmask Bits 33-38: 0x00000000
.... .... ...0 0000 0000 0000 0... .... = Rx Bitmask Bits 39-52: 0x00000000
...0 0000 0000 0000 0000 0000 000. .... = Rx Bitmask Bits 53-76: 0x00000000
Highest Supported Data Rate: 0x0000
.... .... .... ...0 = Tx Supported MCS Set: Not Defined
.... .... .... ..0. = Tx and Rx MCS Set: Equal
.... .... .... 00.. = Tx Maximum Number of Spatial Streams Supported: 1 spatial stream (0x0000)
.... .... ...0 .... = Unequal Modulation: Not supported
>
> Thanks,
> Ben
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Jan 28, 2011 at 4:21 PM, Ben Greear <[email protected]> wrote:
> On 01/28/2011 02:39 PM, Ben Greear wrote:
>>
>> When testing with 60 stations, 30 against a netgear running HT40
>> and 30 against a cheap cisco AP, using HT20, I notice that the
>> stations on the netgear often choose NO_HT instead of HT40
>> for their channel type.
>>
>> The root cause appears to be that the hti->control_chan is 15
>> in the ieee80211_enable_ht method.
>>
>> Everything *should* be running on channel 11.
>>
>> Is this just a bug with the AP, or could this be a local
>> issue?
>
> I sniffed on a separate machine (using ath9k NIC), and it agrees
> that the beacon's control_channel is 14 (I have since set the AP to channel
> 10 instead of 11, but the control_channel remains 4 higher than expected.)
>
How did you configure the AP to HT40 mode? Did you put HT40+ or HT40-
in the hostapd.conf file?
Look at IEEE 802.11n-2009, Annex I and J. They explain what these
mean and which combinations are valid in which sets.
Looks like you're using a weird domain and/or disabled ath's
regulatory checks? I'd think that they would catch this otherwise.
Or, it could also be a bug related to the Japan regulatory stuff that
seemed to cause problems for iwlwifi also.
Dan
On 01/28/2011 04:48 PM, Daniel Halperin wrote:
> On Fri, Jan 28, 2011 at 4:43 PM, Ben Greear<[email protected]> wrote:
>> My AP is an off-the-shelf Netgear:
>> WNDR3700
>>
>> It's only rate configuration option is '300Mbps', which appears to
>> turn on HT40.
>>
>> It is configured for channel 10 (for the packet capture) and actually
>> passes traffic there. It's just this HT Info thing with (primary-channel ==
>> (real_channel + 4))
>> that seems wrong. Note that when I had the channel set to 11, it was
>> reporting
>> 15 for the primary channel in the HT info.
>>
>> Looks like a bug in that AP to me...but would be nice if there were a way to
>> work around it, in case others have similar issues.
>
> Set it to channel 6, then?
It will still fail the control_chan test and so HT will not be enabled.
That's the symptom I've been chasing all day...just turns out that
the cause, for once, appears to not be my system :)
I'll look into adding a hack to allow HT to be enabled
if the channel is off-by-4.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 2011-01-29 1:48 AM, Daniel Halperin wrote:
> On Fri, Jan 28, 2011 at 4:43 PM, Ben Greear <[email protected]> wrote:
>> My AP is an off-the-shelf Netgear:
>> WNDR3700
>>
>> It's only rate configuration option is '300Mbps', which appears to
>> turn on HT40.
>>
>> It is configured for channel 10 (for the packet capture) and actually
>> passes traffic there. It's just this HT Info thing with (primary-channel ==
>> (real_channel + 4))
>> that seems wrong. Note that when I had the channel set to 11, it was
>> reporting
>> 15 for the primary channel in the HT info.
>>
>> Looks like a bug in that AP to me...but would be nice if there were a way to
>> work around it, in case others have similar issues.
>
> Set it to channel 6, then?
>
> Yeah, I played with Netgear's APs (and D-Link's) for about 3 hours
> before I put them down and never picked them up again. Performance,
> configuration, reliability, etc., were horrible. I've found that
> Apple APs work well, but really hostapd offers the best flexibility by
> far.
I think the hardware quality of the WNDR3700 is pretty good. I'm using
it at home regularly (running OpenWrt of course).
- Felix
On 01/28/2011 04:35 PM, Daniel Halperin wrote:
> On Fri, Jan 28, 2011 at 4:21 PM, Ben Greear<[email protected]> wrote:
>> On 01/28/2011 02:39 PM, Ben Greear wrote:
>>>
>>> When testing with 60 stations, 30 against a netgear running HT40
>>> and 30 against a cheap cisco AP, using HT20, I notice that the
>>> stations on the netgear often choose NO_HT instead of HT40
>>> for their channel type.
>>>
>>> The root cause appears to be that the hti->control_chan is 15
>>> in the ieee80211_enable_ht method.
>>>
>>> Everything *should* be running on channel 11.
>>>
>>> Is this just a bug with the AP, or could this be a local
>>> issue?
>>
>> I sniffed on a separate machine (using ath9k NIC), and it agrees
>> that the beacon's control_channel is 14 (I have since set the AP to channel
>> 10 instead of 11, but the control_channel remains 4 higher than expected.)
>>
>
> How did you configure the AP to HT40 mode? Did you put HT40+ or HT40-
> in the hostapd.conf file?
>
> Look at IEEE 802.11n-2009, Annex I and J. They explain what these
> mean and which combinations are valid in which sets.
>
> Looks like you're using a weird domain and/or disabled ath's
> regulatory checks? I'd think that they would catch this otherwise.
> Or, it could also be a bug related to the Japan regulatory stuff that
> seemed to cause problems for iwlwifi also.
My AP is an off-the-shelf Netgear:
WNDR3700
It's only rate configuration option is '300Mbps', which appears to
turn on HT40.
It is configured for channel 10 (for the packet capture) and actually
passes traffic there. It's just this HT Info thing with (primary-channel == (real_channel + 4))
that seems wrong. Note that when I had the channel set to 11, it was reporting
15 for the primary channel in the HT info.
Looks like a bug in that AP to me...but would be nice if there were a way to
work around it, in case others have similar issues.
Thanks,
Ben
>
> Dan
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com