hti->control_chan is 15??

hti->control_chan is 15??

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: hti->control_chan is 15??

[Ben Greear]

[-- Attachment #1: Type: text/plain, Size: 7307 bytes --]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


[-- Attachment #2: wifi-n-bad-ctrl-channel.pcap --]
[-- Type: application/octet-stream, Size: 351 bytes --]

Re: hti->control_chan is 15??

[Daniel Halperin]

On Fri, Jan 28, 2011 at 4:21 PM, Ben Greear <greearb@candelatech.com> 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

Re: hti->control_chan is 15??

[Ben Greear]

On 01/28/2011 04:35 PM, Daniel Halperin wrote:
> On Fri, Jan 28, 2011 at 4:21 PM, Ben Greear<greearb@candelatech.com>  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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: hti->control_chan is 15??

[Daniel Halperin]

On Fri, Jan 28, 2011 at 4:43 PM, Ben Greear <greearb@candelatech.com> 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

Re: hti->control_chan is 15??

[Ben Greear]

On 01/28/2011 04:48 PM, Daniel Halperin wrote:
> On Fri, Jan 28, 2011 at 4:43 PM, Ben Greear<greearb@candelatech.com>  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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: hti->control_chan is 15??

[Felix Fietkau]

On 2011-01-29 1:48 AM, Daniel Halperin wrote:
> On Fri, Jan 28, 2011 at 4:43 PM, Ben Greear <greearb@candelatech.com> 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