Scanning and channel types.

Scanning and channel types.

[Ben Greear]

Current code always sets the channel type to NO_HT when scanning.

 From what I can tell, we should be able to send NO_HT packets on
any channel type, and for passive scanning, it should not matter
at all what channel-type we are using.

I tested relaxing scanning to use the current channel type
when scanning on the operating channel, and it seems to
work.

Does anyone see any problems with this approach?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Felix Fietkau]

On 2011-02-06 8:01 PM, Ben Greear wrote:
> Current code always sets the channel type to NO_HT when scanning.
> 
>  From what I can tell, we should be able to send NO_HT packets on
> any channel type, and for passive scanning, it should not matter
> at all what channel-type we are using.
> 
> I tested relaxing scanning to use the current channel type
> when scanning on the operating channel, and it seems to
> work.
> 
> Does anyone see any problems with this approach?
One thing you should make sure is that once you're done associating to
an NO_HT or HT20 AP (and you have no other interfaces to consider), the
channel mode must not be HT40 - otherwise it could reduce throughput.

- Felix

Re: Scanning and channel types.

[Ben Greear]

On 02/06/2011 11:42 AM, Felix Fietkau wrote:
> On 2011-02-06 8:01 PM, Ben Greear wrote:
>> Current code always sets the channel type to NO_HT when scanning.
>>
>>   From what I can tell, we should be able to send NO_HT packets on
>> any channel type, and for passive scanning, it should not matter
>> at all what channel-type we are using.
>>
>> I tested relaxing scanning to use the current channel type
>> when scanning on the operating channel, and it seems to
>> work.
>>
>> Does anyone see any problems with this approach?
> One thing you should make sure is that once you're done associating to
> an NO_HT or HT20 AP (and you have no other interfaces to consider), the
> channel mode must not be HT40 - otherwise it could reduce throughput.

That is currently handled correctly by the ieee80211_set_channel_type
method, as far as I can tell...

Regardless of that, in my multi-vif testing, I see lower throughput when
using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP ath9k machine).
The VIFS all claim 300Mbps rate.
I haven't looked into this any further at this point...

Thanks,
Ben

>
> - Felix


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Felix Fietkau]

On 2011-02-06 8:54 PM, Ben Greear wrote:
> On 02/06/2011 11:42 AM, Felix Fietkau wrote:
>> On 2011-02-06 8:01 PM, Ben Greear wrote:
>>> Current code always sets the channel type to NO_HT when scanning.
>>>
>>>   From what I can tell, we should be able to send NO_HT packets on
>>> any channel type, and for passive scanning, it should not matter
>>> at all what channel-type we are using.
>>>
>>> I tested relaxing scanning to use the current channel type
>>> when scanning on the operating channel, and it seems to
>>> work.
>>>
>>> Does anyone see any problems with this approach?
>> One thing you should make sure is that once you're done associating to
>> an NO_HT or HT20 AP (and you have no other interfaces to consider), the
>> channel mode must not be HT40 - otherwise it could reduce throughput.
> 
> That is currently handled correctly by the ieee80211_set_channel_type
> method, as far as I can tell...
> 
> Regardless of that, in my multi-vif testing, I see lower throughput when
> using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP ath9k machine).
> The VIFS all claim 300Mbps rate.
> I haven't looked into this any further at this point...
Well, with HT40 you take a hit from not just the busy time of the
primary channel, but also from the busy time of the extension channel.
If you have other wifi activity on the extension channel, then it's
normal that this would reduce throughput.

- Felix

Re: Scanning and channel types.

[Ben Greear]

On 02/06/2011 11:59 AM, Felix Fietkau wrote:
> On 2011-02-06 8:54 PM, Ben Greear wrote:
>> On 02/06/2011 11:42 AM, Felix Fietkau wrote:
>>> On 2011-02-06 8:01 PM, Ben Greear wrote:
>>>> Current code always sets the channel type to NO_HT when scanning.
>>>>
>>>>    From what I can tell, we should be able to send NO_HT packets on
>>>> any channel type, and for passive scanning, it should not matter
>>>> at all what channel-type we are using.
>>>>
>>>> I tested relaxing scanning to use the current channel type
>>>> when scanning on the operating channel, and it seems to
>>>> work.
>>>>
>>>> Does anyone see any problems with this approach?
>>> One thing you should make sure is that once you're done associating to
>>> an NO_HT or HT20 AP (and you have no other interfaces to consider), the
>>> channel mode must not be HT40 - otherwise it could reduce throughput.
>>
>> That is currently handled correctly by the ieee80211_set_channel_type
>> method, as far as I can tell...
>>
>> Regardless of that, in my multi-vif testing, I see lower throughput when
>> using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP ath9k machine).
>> The VIFS all claim 300Mbps rate.
>> I haven't looked into this any further at this point...
> Well, with HT40 you take a hit from not just the busy time of the
> primary channel, but also from the busy time of the extension channel.
> If you have other wifi activity on the extension channel, then it's
> normal that this would reduce throughput.

There were a few other APs on that channel, but they were not doing any active work
(just beacons and such).  The two ath9k systems were very busy
talking to each other.  My typical work-load is STA sending to STA
through the AP.

So, would that scenario be likely to cause the slowdown that you
mention?

Thanks,
Ben

>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Daniel Halperin]

Could be rate selection.

Ben, a sanity check:  is it possible for the device to be associated
to an "HT-Only" AP and thus not be able to sent NO_HT packets?  Could
that be why there might need to be a channel change sometimes?

Dan

On Sun, Feb 6, 2011 at 12:07 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 02/06/2011 11:59 AM, Felix Fietkau wrote:
>>
>> On 2011-02-06 8:54 PM, Ben Greear wrote:
>>>
>>> On 02/06/2011 11:42 AM, Felix Fietkau wrote:
>>>>
>>>> On 2011-02-06 8:01 PM, Ben Greear wrote:
>>>>>
>>>>> Current code always sets the channel type to NO_HT when scanning.
>>>>>
>>>>>   From what I can tell, we should be able to send NO_HT packets on
>>>>> any channel type, and for passive scanning, it should not matter
>>>>> at all what channel-type we are using.
>>>>>
>>>>> I tested relaxing scanning to use the current channel type
>>>>> when scanning on the operating channel, and it seems to
>>>>> work.
>>>>>
>>>>> Does anyone see any problems with this approach?
>>>>
>>>> One thing you should make sure is that once you're done associating to
>>>> an NO_HT or HT20 AP (and you have no other interfaces to consider), the
>>>> channel mode must not be HT40 - otherwise it could reduce throughput.
>>>
>>> That is currently handled correctly by the ieee80211_set_channel_type
>>> method, as far as I can tell...
>>>
>>> Regardless of that, in my multi-vif testing, I see lower throughput when
>>> using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP
>>> ath9k machine).
>>> The VIFS all claim 300Mbps rate.
>>> I haven't looked into this any further at this point...
>>
>> Well, with HT40 you take a hit from not just the busy time of the
>> primary channel, but also from the busy time of the extension channel.
>> If you have other wifi activity on the extension channel, then it's
>> normal that this would reduce throughput.
>
> There were a few other APs on that channel, but they were not doing any
> active work
> (just beacons and such).  The two ath9k systems were very busy
> talking to each other.  My typical work-load is STA sending to STA
> through the AP.
>
> So, would that scenario be likely to cause the slowdown that you
> mention?
>
> Thanks,
> Ben
>
>>
>> - Felix
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Scanning and channel types.

[Ben Greear]

On 02/06/2011 12:23 PM, Daniel Halperin wrote:
> Could be rate selection.
>
> Ben, a sanity check:  is it possible for the device to be associated
> to an "HT-Only" AP and thus not be able to sent NO_HT packets?  Could
> that be why there might need to be a channel change sometimes?

I don't know.  The code and comments in  ieee80211_set_channel_type
make me think that it's always possible to send NO_HT packets regardless
of hardware's channel type.

One thing I haven't figured out yet:  What actually tells the
hardware to send NO_HT v/s HT20 v/s HT40, etc.  I have previously tested
HT20 STAs concurrent with HT40 stas, and both can send/receive at once
while the hardware stays in HT40 mode.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Felix Fietkau]

On 2011-02-06 10:07 PM, Ben Greear wrote:
> On 02/06/2011 12:23 PM, Daniel Halperin wrote:
>> Could be rate selection.
>>
>> Ben, a sanity check:  is it possible for the device to be associated
>> to an "HT-Only" AP and thus not be able to sent NO_HT packets?  Could
>> that be why there might need to be a channel change sometimes?
> 
> I don't know.  The code and comments in  ieee80211_set_channel_type
> make me think that it's always possible to send NO_HT packets regardless
> of hardware's channel type.
> 
> One thing I haven't figured out yet:  What actually tells the
> hardware to send NO_HT v/s HT20 v/s HT40, etc.  I have previously tested
> HT20 STAs concurrent with HT40 stas, and both can send/receive at once
> while the hardware stays in HT40 mode.
mac80211 tx info sets the mode for the transmission (as part of the rate
series). Drivers like ath9k translate that to descriptor fields.
Rate control selects these things based on peer HT capabilities.

- Felix

Re: Scanning and channel types.

[Daniel Halperin]

Right. I think there is a function something like "send_rate_low" that
sends the lowest entry in the mac80211 enabled rates table for control
and mgmt packets.  If the NIC is associated to an HT Only AP then that
lowest entry should be HT20 MCS 1, I'd think.

Also, does circumventing "set channel type" code work properly across
bands?  If you start on 5 GHz will it send 6 Mbps probes or 1 Mbps
probes?

Dan

On Sun, Feb 6, 2011 at 1:09 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-02-06 10:07 PM, Ben Greear wrote:
>> On 02/06/2011 12:23 PM, Daniel Halperin wrote:
>>> Could be rate selection.
>>>
>>> Ben, a sanity check:  is it possible for the device to be associated
>>> to an "HT-Only" AP and thus not be able to sent NO_HT packets?  Could
>>> that be why there might need to be a channel change sometimes?
>>
>> I don't know.  The code and comments in  ieee80211_set_channel_type
>> make me think that it's always possible to send NO_HT packets regardless
>> of hardware's channel type.
>>
>> One thing I haven't figured out yet:  What actually tells the
>> hardware to send NO_HT v/s HT20 v/s HT40, etc.  I have previously tested
>> HT20 STAs concurrent with HT40 stas, and both can send/receive at once
>> while the hardware stays in HT40 mode.
> mac80211 tx info sets the mode for the transmission (as part of the rate
> series). Drivers like ath9k translate that to descriptor fields.
> Rate control selects these things based on peer HT capabilities.
>
> - Felix
>

Re: Scanning and channel types.

[Ben Greear]

On 02/06/2011 09:42 PM, Daniel Halperin wrote:
> Right. I think there is a function something like "send_rate_low" that
> sends the lowest entry in the mac80211 enabled rates table for control
> and mgmt packets.  If the NIC is associated to an HT Only AP then that
> lowest entry should be HT20 MCS 1, I'd think.
>
> Also, does circumventing "set channel type" code work properly across
> bands?  If you start on 5 GHz will it send 6 Mbps probes or 1 Mbps
> probes?

I did some tests with a sniffer set up:

I have 8 STA vifs.

1)  AP is setup to run on channel 11, HT40-
     Let all associate on channel 11, radio goes to HT40- mode.
     Run Scan on operating channel:
     Probe request is reported as 1Mbps data rate on ch 11.

2)  Scan on all channels:
     Probe requests on 2.4Ghz channels are 1Mbps data rate.
     Probe requests on 5Ghz channels (channel 40 in this case)
     are reported as 6Mbps data rate.

3)  Kill AP, no VIFS are associated (radio goes to NO_HT)
     Run scan on all channels.
     Probe request on channel 40 is 6Mbps data rate.


Please note that with my patches, the channel-type is still set to NO_HT
if we are scanning off the operating channel.  Since test 1 appears to
function properly, I think that verifies that we can safely send NO_HT
requests while leaving the radio at HT40-.

Please let me know if this answers your concerns.  If you can think of
other combinations I should try, please let me know that as well.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Daniel Halperin]

Start on 2.4 GHz AP with HT Only (not just HT40) set.  That is, AP
that doesn't allow 1 Mbps packets to be sent.  Scan, make sure 1 mbps
packets are sent.

Start on 5 GHZ AP with HT Only set.  Scan.  What rate are probes sent
at for 2.4 GHz?

Dan

On Mon, Feb 7, 2011 at 10:03 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 02/06/2011 09:42 PM, Daniel Halperin wrote:
>>
>> Right. I think there is a function something like "send_rate_low" that
>> sends the lowest entry in the mac80211 enabled rates table for control
>> and mgmt packets.  If the NIC is associated to an HT Only AP then that
>> lowest entry should be HT20 MCS 1, I'd think.
>>
>> Also, does circumventing "set channel type" code work properly across
>> bands?  If you start on 5 GHz will it send 6 Mbps probes or 1 Mbps
>> probes?
>
> I did some tests with a sniffer set up:
>
> I have 8 STA vifs.
>
> 1)  AP is setup to run on channel 11, HT40-
>    Let all associate on channel 11, radio goes to HT40- mode.
>    Run Scan on operating channel:
>    Probe request is reported as 1Mbps data rate on ch 11.
>
> 2)  Scan on all channels:
>    Probe requests on 2.4Ghz channels are 1Mbps data rate.
>    Probe requests on 5Ghz channels (channel 40 in this case)
>    are reported as 6Mbps data rate.
>
> 3)  Kill AP, no VIFS are associated (radio goes to NO_HT)
>    Run scan on all channels.
>    Probe request on channel 40 is 6Mbps data rate.
>
>
> Please note that with my patches, the channel-type is still set to NO_HT
> if we are scanning off the operating channel.  Since test 1 appears to
> function properly, I think that verifies that we can safely send NO_HT
> requests while leaving the radio at HT40-.
>
> Please let me know if this answers your concerns.  If you can think of
> other combinations I should try, please let me know that as well.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>

Re: Scanning and channel types.

[Ben Greear]

On 02/07/2011 10:32 AM, Daniel Halperin wrote:
> Start on 2.4 GHz AP with HT Only (not just HT40) set.  That is, AP
> that doesn't allow 1 Mbps packets to be sent.  Scan, make sure 1 mbps
> packets are sent.

I configured my AP with the conf file below.  Radio is configured
for HT20.  Is that what you mean??

On channel 3 (off-channel), probe request is sent at 1Mbps
On channel 8 (on-channel), probe request (and deauth) is sent at 1Mbps.


[root@lec-2010p-ath9k-3x3 wifi]# cat /debug/ieee80211/wiphy0/ath9k/wiphy
wiphy0 (chan=8  center-freq: 2447 MHz  channel-type: 1 (ht20))
addr: 00:15:6d:84:65:0b
addrmask: ff:ea:a1:3f:12:f5
rfilt: 0x597 UCAST MCAST BCAST BEACON PROBEREQ PHYERR COMP_BAR


interface=vap0
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
dump_file=/home/lanforge/wifi/hostapd_vap0.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=vap-3x3
bssid=00:00:33:44:88:01
country_code=US
ieee80211d=0
hw_mode=g
ieee80211n=1
channel=8
beacon_int=240
dtim_period=2
max_num_sta=2007
rts_threshold=2347
fragm_threshold=2346
preamble=0
macaddr_acl=0
auth_algs=3
ignore_broadcast_ssid=0
# Enable HT modes if you want 300Mbps+ throughput.
#ht_capab=[HT20][HT40-][SHORT-GI-40]
#ht_capab=[HT20][HT40+][SHORT-GI-40]
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
ieee8021x=0
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=1
wpa_pairwise=TKIP CCMP
wpa_passphrase=vap-3x3-passwd


>
> Start on 5 GHZ AP with HT Only set.  Scan.  What rate are probes sent
> at for 2.4 GHz?

(Using slightly different hostapd.conf config file, of course)

On 5Ghz channels, they are sent at 6Mbps
On channel 3 (2.4Ghz), they are sent at 1Mbps


That seem right?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Daniel Halperin]

On Mon, Feb 7, 2011 at 12:04 PM, Ben Greear <greearb@candelatech.com> wrote:
>> Start on 5 GHZ AP with HT Only set.  Scan.  What rate are probes sent
>> at for 2.4 GHz?

No HT20 is not the same as HT-Only.  I'm not sure how to set that. Jouni?

> On 5Ghz channels, they are sent at 6Mbps
> On channel 3 (2.4Ghz), they are sent at 1Mbps
>
>
> That seem right?

Yes, for a HT20 but not HT Only AP.

Dan

Re: Scanning and channel types.

[Jouni Malinen]

On Mon, Feb 07, 2011 at 12:10:57PM -0800, Daniel Halperin wrote:
> No HT20 is not the same as HT-Only.  I'm not sure how to set that. Jouni?

What is a "HT-Only" AP and where is this defined? Are you saying that
there would be an AP that would be unable to receive a frame at 1 Mbps
on 2.4 GHz band or 6 Mbps on 5 GHz band? I would assume that normal way
of enforcing HT only BSS would be to reject non-HT STAs from associating
with it, but I would be a bit surprised if the AP actually disables RX
of non-MCS rates.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Scanning and channel types.

[Ben Greear]

On 02/07/2011 12:10 PM, Daniel Halperin wrote:
> On Mon, Feb 7, 2011 at 12:04 PM, Ben Greear<greearb@candelatech.com>  wrote:
>>> Start on 5 GHZ AP with HT Only set.  Scan.  What rate are probes sent
>>> at for 2.4 GHz?
>
> No HT20 is not the same as HT-Only.  I'm not sure how to set that. Jouni?

I found a post from a year or so ago that indicates hostapd doesn't
support this type of thing (that could have changed, of course).

Do you know of any commercial APs that support the HT-only feature?
(And/Or a general strategy for configuring it?)

>> On 5Ghz channels, they are sent at 6Mbps
>> On channel 3 (2.4Ghz), they are sent at 1Mbps
>>
>>
>> That seem right?
>
> Yes, for a HT20 but not HT Only AP.

Seems to me that the probe-request is to any/all APs,
so how could we possibly know that we should send it
at 6Mbps v/s 1Mbps until we discovered and communicated
with it?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Daniel Halperin]

On Mon, Feb 7, 2011 at 1:02 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 02/07/2011 12:10 PM, Daniel Halperin wrote:
>>
>> On Mon, Feb 7, 2011 at 12:04 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>>
>>>> Start on 5 GHZ AP with HT Only set.  Scan.  What rate are probes sent
>>>> at for 2.4 GHz?
>>
>> No HT20 is not the same as HT-Only.  I'm not sure how to set that. Jouni?
>
> I found a post from a year or so ago that indicates hostapd doesn't
> support this type of thing (that could have changed, of course).
>
> Do you know of any commercial APs that support the HT-only feature?
> (And/Or a general strategy for configuring it?)
>
>>> On 5Ghz channels, they are sent at 6Mbps
>>> On channel 3 (2.4Ghz), they are sent at 1Mbps
>>>
>>>
>>> That seem right?
>>
>> Yes, for a HT20 but not HT Only AP.
>
> Seems to me that the probe-request is to any/all APs,
> so how could we possibly know that we should send it
> at 6Mbps v/s 1Mbps until we discovered and communicated
> with it?

Just as there are G-only APs that don't advertise 1-11 Mbps in their
beacons, there are HT-only APs that don't advertise support for 1-11
or 6-54 Mbps in their beacons and *only* support MCS rates.

Dan

Re: Scanning and channel types.

[Ben Greear]

On 02/07/2011 03:53 PM, Daniel Halperin wrote:
> On Mon, Feb 7, 2011 at 1:02 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 02/07/2011 12:10 PM, Daniel Halperin wrote:
>>>
>>> On Mon, Feb 7, 2011 at 12:04 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>>
>>>>> Start on 5 GHZ AP with HT Only set.  Scan.  What rate are probes sent
>>>>> at for 2.4 GHz?
>>>
>>> No HT20 is not the same as HT-Only.  I'm not sure how to set that. Jouni?
>>
>> I found a post from a year or so ago that indicates hostapd doesn't
>> support this type of thing (that could have changed, of course).
>>
>> Do you know of any commercial APs that support the HT-only feature?
>> (And/Or a general strategy for configuring it?)
>>
>>>> On 5Ghz channels, they are sent at 6Mbps
>>>> On channel 3 (2.4Ghz), they are sent at 1Mbps
>>>>
>>>>
>>>> That seem right?
>>>
>>> Yes, for a HT20 but not HT Only AP.
>>
>> Seems to me that the probe-request is to any/all APs,
>> so how could we possibly know that we should send it
>> at 6Mbps v/s 1Mbps until we discovered and communicated
>> with it?
>
> Just as there are G-only APs that don't advertise 1-11 Mbps in their
> beacons, there are HT-only APs that don't advertise support for 1-11
> or 6-54 Mbps in their beacons and *only* support MCS rates.

Well, I don't think my changes would have made this any worse,
so if it worked before, it probably still works.

If anyone knows how to configure such a beast, I'll run some
tests.  Or, if someone else has an AP like this, please let
me know if you see any problems with these patches.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Scanning and channel types.

[Jouni Malinen]

On Mon, Feb 07, 2011 at 04:38:51PM -0800, Ben Greear wrote:
> On 02/07/2011 03:53 PM, Daniel Halperin wrote:
> >Just as there are G-only APs that don't advertise 1-11 Mbps in their
> >beacons, there are HT-only APs that don't advertise support for 1-11
> >or 6-54 Mbps in their beacons and *only* support MCS rates.

> If anyone knows how to configure such a beast, I'll run some
> tests.  Or, if someone else has an AP like this, please let
> me know if you see any problems with these patches.

As of today, the hostap.git snapshot of hostapd allows you to configure
the AP to require HT PHY support from every station trying to associate
with it. This can be configured with require_ht=1. This by itself does
not change the advertised rate sets, but when set, this allows following
configuration to remove all non-MCS rates to be disabled:

ieee80211n=1
require_ht=1
supported_rates=
basic_rates=

I'm not sure whether we currently handle such configuration correctly
everywhere, but at least this will remove the non-MCS rates from
Beacon/Probe Response frames from the AP. It does not prevent the AP
from actually receiving frames at non-MCS rates, so it may still reply
to Probe Request frames even if they are sent without using MCS rates. I
think I can make hostapd not reply to those frames if they do not
contain HT Capabilities IE, but still, you would likely see a response
to a Probe Request with that IE included even if it is sent at 1 Mbps.
Whether the response goes out using MCS in such a case is unknown to me
at this point, though.
 
-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Scanning and channel types.

[Ben Greear]

On 02/06/2011 11:59 AM, Felix Fietkau wrote:
> On 2011-02-06 8:54 PM, Ben Greear wrote:
>> On 02/06/2011 11:42 AM, Felix Fietkau wrote:
>>> On 2011-02-06 8:01 PM, Ben Greear wrote:
>>>> Current code always sets the channel type to NO_HT when scanning.
>>>>
>>>>    From what I can tell, we should be able to send NO_HT packets on
>>>> any channel type, and for passive scanning, it should not matter
>>>> at all what channel-type we are using.
>>>>
>>>> I tested relaxing scanning to use the current channel type
>>>> when scanning on the operating channel, and it seems to
>>>> work.
>>>>
>>>> Does anyone see any problems with this approach?
>>> One thing you should make sure is that once you're done associating to
>>> an NO_HT or HT20 AP (and you have no other interfaces to consider), the
>>> channel mode must not be HT40 - otherwise it could reduce throughput.
>>
>> That is currently handled correctly by the ieee80211_set_channel_type
>> method, as far as I can tell...
>>
>> Regardless of that, in my multi-vif testing, I see lower throughput when
>> using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP ath9k machine).
>> The VIFS all claim 300Mbps rate.
>> I haven't looked into this any further at this point...
> Well, with HT40 you take a hit from not just the busy time of the
> primary channel, but also from the busy time of the extension channel.
> If you have other wifi activity on the extension channel, then it's
> normal that this would reduce throughput.

I think you perfectly described the problem.  I had another system that
had a bunch of STAs configured and was making all sorts of noise.
With it powered down, latency & throughput looks quite nice
with 300Mbps HT40- (128 stas, 20kbps per sta tx and rx to other stas).

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com