Scanning and channel types.
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 11 lines · Ben Greear
Current code always sets the channel type to
NO_HTwhen scanning.From what I can tell, we should be able to send
NO_HTpackets 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
Quoted 7 lines · Felix Fietkau
Quoted 6 lines · Ben Greear
Current code always sets the channel type to
NO_HTwhen scanning.From what I can tell, we should be able to send
NO_HTpackets on
any channel type, and for passive scanning, it should not matter at all what channel-type we are using.
Quoted 8 lines
Quoted 5 lines
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_HTor 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
Quoted 2 lines
- Felix
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 17 lines · Ben Greear
Quoted 7 lines · Felix Fietkau
Quoted 6 lines · Ben Greear
Current code always sets the channel type to
NO_HTwhen scanning.From what I can tell, we should be able to send
NO_HTpackets on
any channel type, and for passive scanning, it should not matter at all what channel-type we are using.Quoted 8 lines
Quoted 5 lines
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_HTor HT20 AP (and you have no other interfaces to consider), the channel mode must not be HT40 - otherwise it could reduce throughput.
Quoted 7 lines
That is currently handled correctly by the
ieee80211_set_channel_typemethod, 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
Quoted 21 lines · Felix Fietkau
Quoted 20 lines · Ben Greear
Quoted 7 lines · Felix Fietkau
Quoted 6 lines · Ben Greear
Current code always sets the channel type to
NO_HTwhen scanning.From what I can tell, we should be able to send
NO_HTpackets on
any channel type, and for passive scanning, it should not matter at all what channel-type we are using.Quoted 8 lines
Quoted 5 lines
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_HTor 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_typemethod, as far as I can tell...
Quoted 8 lines
Quoted 4 lines
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
Quoted 6 lines
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
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
Quoted 67 lines · Ben Greear
Quoted 32 lines · Felix Fietkau
Quoted 21 lines · Ben Greear
Quoted 13 lines · Felix Fietkau
Quoted 11 lines · Ben Greear
Current code always sets the channel type to
NO_HTwhen scanning.From what I can tell, we should be able to send
NO_HTpackets 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.
Quoted 5 lines
Quoted 1 line
Does anyone see any problems with this approach?
One thing you should make sure is that once you're done associating to an
NO_HTor HT20 AP (and you have no other interfaces to consider), the channel mode must not be HT40 - otherwise it could reduce throughput.Quoted 8 lines
That is currently handled correctly by the
ieee80211_set_channel_typemethod, 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...Quoted 4 lines
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,
BenQuoted 7 lines
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
Ben Greear <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · 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_HTpackets? 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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 7 lines · Ben Greear
Quoted 5 lines · 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_HTpackets? Could that be why there might need to be a channel change sometimes?
Quoted 8 lines
I don't know. The code and comments in
ieee80211_set_channel_typemake me think that it's always possible to sendNO_HTpackets regardless of hardware's channel type.One thing I haven't figured out yet: What actually tells the hardware to send
NO_HTv/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
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
Quoted 22 lines · Felix Fietkau
Quoted 7 lines · Ben Greear
Quoted 5 lines · 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_HTpackets? Could that be why there might need to be a channel change sometimes?Quoted 8 lines
I don't know. The code and comments in ieee80211_set_channel_type make me think that it's always possible to send
NO_HTpackets regardless of hardware's channel type.One thing I haven't figured out yet: What actually tells the hardware to send
NO_HTv/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
Quoted 8 lines · 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?
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
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
Quoted 46 lines · Ben Greear
Quoted 9 lines · 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?
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_HTif we are scanning off the operating channel. Since test 1 appears to function properly, I think that verifies that we can safely sendNO_HTrequests 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Quoted 3 lines · 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.
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
Quoted 3 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 2 lines · Ben Greear
Quoted 2 lines
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?
Quoted 5 lines
On 5Ghz channels, they are sent at 6Mbps
On channel 3 (2.4Ghz), they are sent at 1MbpsThat seem right?
Yes, for a HT20 but not HT Only AP.
Dan
Quoted 1 line · Daniel Halperin
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 5 lines · Daniel Halperin
Quoted 2 lines · Ben Greear
Quoted 2 lines
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?)
Quoted 7 lines
Quoted 5 lines
On 5Ghz channels, they are sent at 6Mbps
On channel 3 (2.4Ghz), they are sent at 1MbpsThat 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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 20 lines · Ben Greear
Quoted 8 lines · Daniel Halperin
Quoted 3 lines · Ben Greear
Quoted 3 lines
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?)
Quoted 4 lines
Quoted 4 lines
On 5Ghz channels, they are sent at 6Mbps
On channel 3 (2.4Ghz), they are sent at 1Mbps
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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
Quoted 25 lines · Daniel Halperin
Quoted 24 lines · Ben Greear
Quoted 8 lines · Daniel Halperin
Quoted 3 lines · Ben Greear
Quoted 3 lines
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?)
Quoted 7 lines
Quoted 5 lines
On 5Ghz channels, they are sent at 6Mbps
On channel 3 (2.4Ghz), they are sent at 1MbpsThat seem right?
Yes, for a HT20 but not HT Only AP.
Quoted 8 lines
Quoted 4 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 8 lines · Ben Greear
Quoted 3 lines · Daniel Halperin
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 21 lines · Felix Fietkau
Quoted 20 lines · Ben Greear
Quoted 7 lines · Felix Fietkau
Quoted 6 lines · Ben Greear
Current code always sets the channel type to
NO_HTwhen scanning.From what I can tell, we should be able to send
NO_HTpackets on
any channel type, and for passive scanning, it should not matter at all what channel-type we are using.Quoted 8 lines
Quoted 5 lines
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_HTor 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_typemethod, as far as I can tell...
Quoted 8 lines
Quoted 4 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com