* Scanning and channel types. @ 2011-02-06 19:01 Ben Greear 2011-02-06 19:42 ` Felix Fietkau 0 siblings, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-06 19:01 UTC (permalink / raw) To: linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 19:01 Scanning and channel types Ben Greear @ 2011-02-06 19:42 ` Felix Fietkau 2011-02-06 19:54 ` Ben Greear 0 siblings, 1 reply; 19+ messages in thread From: Felix Fietkau @ 2011-02-06 19:42 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 19:42 ` Felix Fietkau @ 2011-02-06 19:54 ` Ben Greear 2011-02-06 19:59 ` Felix Fietkau 0 siblings, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-06 19:54 UTC (permalink / raw) To: Felix Fietkau; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 19:54 ` Ben Greear @ 2011-02-06 19:59 ` Felix Fietkau 2011-02-06 20:07 ` Ben Greear 2011-02-07 18:23 ` Ben Greear 0 siblings, 2 replies; 19+ messages in thread From: Felix Fietkau @ 2011-02-06 19:59 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 19:59 ` Felix Fietkau @ 2011-02-06 20:07 ` Ben Greear 2011-02-06 20:23 ` Daniel Halperin 2011-02-07 18:23 ` Ben Greear 1 sibling, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-06 20:07 UTC (permalink / raw) To: Felix Fietkau; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 20:07 ` Ben Greear @ 2011-02-06 20:23 ` Daniel Halperin 2011-02-06 21:07 ` Ben Greear 0 siblings, 1 reply; 19+ messages in thread From: Daniel Halperin @ 2011-02-06 20:23 UTC (permalink / raw) To: Ben Greear; +Cc: Felix Fietkau, linux-wireless 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 20:23 ` Daniel Halperin @ 2011-02-06 21:07 ` Ben Greear 2011-02-06 21:09 ` Felix Fietkau 0 siblings, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-06 21:07 UTC (permalink / raw) To: Daniel Halperin; +Cc: Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 21:07 ` Ben Greear @ 2011-02-06 21:09 ` Felix Fietkau 2011-02-07 5:42 ` Daniel Halperin 0 siblings, 1 reply; 19+ messages in thread From: Felix Fietkau @ 2011-02-06 21:09 UTC (permalink / raw) To: Ben Greear; +Cc: Daniel Halperin, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 21:09 ` Felix Fietkau @ 2011-02-07 5:42 ` Daniel Halperin 2011-02-07 18:03 ` Ben Greear 0 siblings, 1 reply; 19+ messages in thread From: Daniel Halperin @ 2011-02-07 5:42 UTC (permalink / raw) To: Felix Fietkau; +Cc: Ben Greear, linux-wireless 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 5:42 ` Daniel Halperin @ 2011-02-07 18:03 ` Ben Greear 2011-02-07 18:32 ` Daniel Halperin 0 siblings, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-07 18:03 UTC (permalink / raw) To: Daniel Halperin; +Cc: Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 18:03 ` Ben Greear @ 2011-02-07 18:32 ` Daniel Halperin 2011-02-07 20:04 ` Ben Greear 0 siblings, 1 reply; 19+ messages in thread From: Daniel Halperin @ 2011-02-07 18:32 UTC (permalink / raw) To: Ben Greear; +Cc: Felix Fietkau, linux-wireless 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 > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 18:32 ` Daniel Halperin @ 2011-02-07 20:04 ` Ben Greear 2011-02-07 20:10 ` Daniel Halperin 0 siblings, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-07 20:04 UTC (permalink / raw) To: Daniel Halperin; +Cc: Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 20:04 ` Ben Greear @ 2011-02-07 20:10 ` Daniel Halperin 2011-02-07 21:01 ` Jouni Malinen 2011-02-07 21:02 ` Ben Greear 0 siblings, 2 replies; 19+ messages in thread From: Daniel Halperin @ 2011-02-07 20:10 UTC (permalink / raw) To: Ben Greear, j; +Cc: Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 20:10 ` Daniel Halperin @ 2011-02-07 21:01 ` Jouni Malinen 2011-02-07 21:02 ` Ben Greear 1 sibling, 0 replies; 19+ messages in thread From: Jouni Malinen @ 2011-02-07 21:01 UTC (permalink / raw) To: Daniel Halperin; +Cc: Ben Greear, Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 20:10 ` Daniel Halperin 2011-02-07 21:01 ` Jouni Malinen @ 2011-02-07 21:02 ` Ben Greear 2011-02-07 23:53 ` Daniel Halperin 1 sibling, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-07 21:02 UTC (permalink / raw) To: Daniel Halperin; +Cc: j, Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 21:02 ` Ben Greear @ 2011-02-07 23:53 ` Daniel Halperin 2011-02-08 0:38 ` Ben Greear 0 siblings, 1 reply; 19+ messages in thread From: Daniel Halperin @ 2011-02-07 23:53 UTC (permalink / raw) To: Ben Greear; +Cc: j, Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-07 23:53 ` Daniel Halperin @ 2011-02-08 0:38 ` Ben Greear 2011-02-09 13:22 ` Jouni Malinen 0 siblings, 1 reply; 19+ messages in thread From: Ben Greear @ 2011-02-08 0:38 UTC (permalink / raw) To: Daniel Halperin; +Cc: j, Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-08 0:38 ` Ben Greear @ 2011-02-09 13:22 ` Jouni Malinen 0 siblings, 0 replies; 19+ messages in thread From: Jouni Malinen @ 2011-02-09 13:22 UTC (permalink / raw) To: Ben Greear; +Cc: Daniel Halperin, Felix Fietkau, linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Scanning and channel types. 2011-02-06 19:59 ` Felix Fietkau 2011-02-06 20:07 ` Ben Greear @ 2011-02-07 18:23 ` Ben Greear 1 sibling, 0 replies; 19+ messages in thread From: Ben Greear @ 2011-02-07 18:23 UTC (permalink / raw) To: Felix Fietkau; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2011-02-09 13:22 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-06 19:01 Scanning and channel types Ben Greear 2011-02-06 19:42 ` Felix Fietkau 2011-02-06 19:54 ` Ben Greear 2011-02-06 19:59 ` Felix Fietkau 2011-02-06 20:07 ` Ben Greear 2011-02-06 20:23 ` Daniel Halperin 2011-02-06 21:07 ` Ben Greear 2011-02-06 21:09 ` Felix Fietkau 2011-02-07 5:42 ` Daniel Halperin 2011-02-07 18:03 ` Ben Greear 2011-02-07 18:32 ` Daniel Halperin 2011-02-07 20:04 ` Ben Greear 2011-02-07 20:10 ` Daniel Halperin 2011-02-07 21:01 ` Jouni Malinen 2011-02-07 21:02 ` Ben Greear 2011-02-07 23:53 ` Daniel Halperin 2011-02-08 0:38 ` Ben Greear 2011-02-09 13:22 ` Jouni Malinen 2011-02-07 18:23 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.