1 (edited by key4078 2009-09-02 20:54:40)

Topic: HT40 mode

Hi, all.

I have an Intel-IXP425-based router board and an AR9106/9160-based 802.11n mini-pci radio,
and installed OpenWrt r17409 (w/ compat-wireless-2009-08-20) in the board.
Now, I'm evaluating the 802.11n performance of the platform.

I followed the instruction in http://linuxwireless.org and could set up the HT20 mode successfully.
I got around 60Mbps throughput at 130Mbps rate (MCS15 / 20MHz / LONG-GI).

However, when I set it as HT40 (at hostapd.conf), it seems hostapd still worked at HT20.
I also tried all the other available channels for HT40+/HT40- and updated hostapd from 0.6.9
to the current development tree (got it by git), but it didn't work.

I attached the current setting and test results.
I will appreciate if you let me know any good idea.
Thank you.


Before updating hostapd from 0.6.9 to the current development tree:

root@OpenWrt:/tmp# hostapd -dd /etc/hostapd.conf   
Configuration file: /etc/hostapd.conf
Opening raw packet socket for ifindex 0
BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits)
SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
nl80211: Added 802.11b mode based on 802.11g information
Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=27 dBm
Allowed channel: mode=2 chan=36 freq=5180 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=40 freq=5200 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=44 freq=5220 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=48 freq=5240 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=149 freq=5745 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=153 freq=5765 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=157 freq=5785 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=161 freq=5805 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=165 freq=5825 MHz max_tx_power=30 dBm
Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=27 dBm
HT40: control channel: 161  secondary channel: 157
RATE[0] rate=60 flags=0x2
RATE[1] rate=90 flags=0x0
RATE[2] rate=120 flags=0x2
RATE[3] rate=180 flags=0x0
RATE[4] rate=240 flags=0x2
RATE[5] rate=360 flags=0x0
RATE[6] rate=480 flags=0x0
RATE[7] rate=540 flags=0x0
Passive scanning not supported
Flushing old station entries
Deauthenticate all stations
Mode: IEEE 802.11a  Channel: 161  Frequency: 5805 MHz
Using interface wlan0 with hwaddr 00:15:6d:84:13:b4 and ssid 'test-tchang'
wlan0: Setup of interface done.
MGMT (TX callback) ACK
STA 00:15:6d:84:13:b8 sent probe request for our SSID
MGMT (TX callback) ACK
mgmt::proberesp cb
MGMT
mgmt::auth
authentication: STA=00:15:6d:84:13:b8 auth_alg=0 auth_transaction=1 status_code0
  New STA
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: authentication OK (open system)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-AUTHENTICATE.indication(00:15:6d:84:13:)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-DELETEKEYS.request(00:15:6d:84:13:b8)
authentication reply: STA=00:15:6d:84:13:b8 auth_alg=0 auth_transaction=2 resp=)
MGMT (TX callback) ACK
mgmt::auth cb
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: authenticated
MGMT
mgmt::assoc_req
association request: STA=00:15:6d:84:13:b8 capab_info=0x01 listen_interval=10
WME IE - hexdump(len=7): 00 50 f2 02 00 01 00
Validating WME IE: OUI 00:50:f2  OUI type 2  OUI sub-type 0  version 1
HT: STA 00:15:6d:84:13:b8 HT Capabilities Info: 0x104e
handle_assoc STA 00:15:6d:84:13:b8 - no greenfield, num of non-gf stations 1
hostapd_ht_operation_update current operation mode=0x0
hostapd_ht_operation_update new operation mode=0x7 changes=2
  new AID 1
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: association OK (aid 1)
MGMT (TX callback) ACK
mgmt::assoc_resp cb
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: associated (aid 1)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-ASSOCIATE.indication(00:15:6d:84:13:b8)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-DELETEKEYS.request(00:15:6d:84:13:b8)
wlan0: STA 00:15:6d:84:13:b8 RADIUS: starting accounting session 00000280-000000
MGMT (TX callback) ACK
mgmt::action cb
MGMT (TX callback) ACK
mgmt::action cb
MGMT (TX callback) ACK
mgmt::action cb
STA 00:0f:7d:07:46:60 sent probe request for broadcast SSID
MGMT (TX callback) ACK
mgmt::proberesp cb
MGMT (TX callback) ACK
mgmt::action cb
STA 00:0f:7d:07:42:60 sent probe request for broadcast SSID
MGMT (TX callback) ACK
mgmt::proberesp cb

After updating hostapd to the current development tree:

root@OpenWrt:/sys/kernel/debug/ath9k/phy0# hostapd -dd /etc/hostapd.conf 
Configuration file: /etc/hostapd.conf
nl80211: Add own interface ifindex 4
nl80211: Add own interface ifindex 21
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
nl80211: Added 802.11b mode based on 802.11g information
Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=27 dBm
Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=27 dBm
Allowed channel: mode=2 chan=36 freq=5180 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=40 freq=5200 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=44 freq=5220 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=48 freq=5240 MHz max_tx_power=17 dBm
Allowed channel: mode=2 chan=149 freq=5745 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=153 freq=5765 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=157 freq=5785 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=161 freq=5805 MHz max_tx_power=30 dBm
Allowed channel: mode=2 chan=165 freq=5825 MHz max_tx_power=30 dBm
Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=27 dBm
Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=27 dBm
RATE[0] rate=60 flags=0x2
RATE[1] rate=90 flags=0x0
RATE[2] rate=120 flags=0x2
RATE[3] rate=180 flags=0x0
RATE[4] rate=240 flags=0x2
RATE[5] rate=360 flags=0x0
RATE[6] rate=480 flags=0x0
RATE[7] rate=540 flags=0x0
Scan for neighboring BSSes prior to enabling 40 MHz channel
Scan requested (ret=0) - scan timeout 10 seconds
Interface initialization will be completed in a callback
nl80211: Event message available
nl80211: Ignored unknown event (cmd=33)
nl80211: Event message available
nl80211: New scan results available
Received scan results (65 BSSes)
Switch own primary and secondary channel due to BSS overlap with 00:0f:7d:07:45:f6
Completing interface initialization
Mode: IEEE 802.11a  Channel: 40  Frequency: 5200 MHz
Flushing old station entries
Deauthenticate all stations
nl_set_encr: ifindex=4 alg=0 addr=(nil) key_idx=0 set_tx=1 seq_len=0 key_len=0
nl_set_encr: ifindex=4 alg=0 addr=(nil) key_idx=1 set_tx=0 seq_len=0 key_len=0
nl_set_encr: ifindex=4 alg=0 addr=(nil) key_idx=2 set_tx=0 seq_len=0 key_len=0
nl_set_encr: ifindex=4 alg=0 addr=(nil) key_idx=3 set_tx=0 seq_len=0 key_len=0
Using interface wlan0 with hwaddr 00:15:6d:84:13:b4 and ssid 'test-tchang'
nl80211: Set beacon (beacon_set=0)
wlan0: Setup of interface done.
MGMT (TX callback) ACK
STA 00:1e:c1:aa:f5:a6 sent probe request for broadcast SSID
MGMT (TX callback) fail
mgmt::proberesp cb
STA 00:15:6d:84:13:b8 sent probe request for our SSID
MGMT (TX callback) ACK
mgmt::proberesp cb
STA 00:15:6d:84:13:b8 sent probe request for our SSID
MGMT (TX callback) ACK
mgmt::proberesp cb
MGMT
mgmt::auth
authentication: STA=00:15:6d:84:13:b8 auth_alg=0 auth_transaction=1 status_code=0 wep=0
  New STA
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: authentication OK (open system)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-AUTHENTICATE.indication(00:15:6d:84:13:b8, OPEN_SYSTEM)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-DELETEKEYS.request(00:15:6d:84:13:b8)
authentication reply: STA=00:15:6d:84:13:b8 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
MGMT (TX callback) ACK
mgmt::auth cb
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: authenticated
MGMT
mgmt::assoc_req
association request: STA=00:15:6d:84:13:b8 capab_info=0x01 listen_interval=10
WMM IE - hexdump(len=7): 00 50 f2 02 00 01 00
Validating WMM IE: OUI 00:50:f2  OUI type 2  OUI sub-type 0  version 1  QoS info 0x0
HT: STA 00:15:6d:84:13:b8 HT Capabilities Info: 0x104e
handle_assoc STA 00:15:6d:84:13:b8 - no greenfield, num of non-gf stations 1
hostapd_ht_operation_update current operation mode=0x0
hostapd_ht_operation_update new operation mode=0x7 changes=2
nl80211: Set beacon (beacon_set=1)
  new AID 1
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: association OK (aid 1)
MGMT (TX callback) ACK
mgmt::assoc_resp cb
wlan0: STA 00:15:6d:84:13:b8 IEEE 802.11: associated (aid 1)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-ASSOCIATE.indication(00:15:6d:84:13:b8)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-DELETEKEYS.request(00:15:6d:84:13:b8)
wlan0: STA 00:15:6d:84:13:b8 RADIUS: starting accounting session 000002F7-00000000
STA 00:0f:7d:07:42:60 sent probe request for broadcast SSID
MGMT (TX callback) ACK
mgmt::proberesp cb
^CSignal 2 received - terminating
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-DEAUTHENTICATE.indication(00:15:6d:84:13:b8, 1)
wlan0: STA 00:15:6d:84:13:b8 MLME: MLME-DELETEKEYS.request(00:15:6d:84:13:b8)
Removing station 00:15:6d:84:13:b8
hostapd_ht_operation_update current operation mode=0x7
hostapd_ht_operation_update new operation mode=0x0 changes=2
nl80211: Set beacon (beacon_set=1)
Flushing old station entries
Deauthenticate all stations
root@OpenWrt:/# cat /etc/hostapd.conf 
interface=wlan0
driver=nl80211
ssid=test-11n
hw_mode=a
channel=153
ieee80211n=1
ht_capab=[HT40-]
wme_enabled=1
------------------------------------------------------------
Client connecting to 10.10.0.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.1.1 port 47758 connected with 10.10.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  7.11 MBytes  59.6 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  1.0- 2.0 sec  6.34 MBytes  53.1 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  2.0- 3.0 sec  6.34 MBytes  53.1 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  3.0- 4.0 sec  6.71 MBytes  56.3 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  4.0- 5.0 sec  8.20 MBytes  68.8 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  5.0- 6.0 sec  7.09 MBytes  59.4 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  6.0- 7.0 sec  7.46 MBytes  62.6 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  7.0- 8.0 sec  7.08 MBytes  59.4 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  8.0- 9.0 sec  7.09 MBytes  59.4 Mbits/sec
^C[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 9.3 sec  65.3 MBytes  59.0 Mbits/sec
root@OpenWrt:/sys/kernel/debug/ath9k/phy0# cat rcstat           
 Rate         Success  Retries  XRetries PER
  6.0:        0        0        0        0
  9.0:        0        0        0        0
 12.0:        0        0        0        0
 18.0:        0        0        0        0
 24.0:        0        0        0        0
 36.0:        0        0        0        0
 48.0:        0        0        0        0
 54.0:        0        0        0        0
  6.5:        0        0        0        0
 13.0:        0        0        0        0
 19.5:        0        0        0        0
 26.0:        0        0        0        0
 39.0:        0        0        0        0
 52.0:        0        0        0        0
 58.5:        0        0        0        0
 65.0:        0        0        0        0
 13.0:        0        0        0        0
 26.0:        0        0        0        0
 39.0:        0        0        0        0
 52.0:        0        0        0        0
 78.0:        4        0        0        0
104.0:       26        1        0        3
117.0:      129        7        0        7
130.0:    98697     5315        2        7
 13.5:        0        0        0        0
 27.5:        0        0        0        0
 40.5:        0        0        0        0
 54.0:        0        0        0        0
 81.5:        0        0        0        0
108.0:        0        0        0        0
121.5:        0        0        0        0
135.0:        0        0        0        0
150.0:        0        0        0        0
 27.0:        0        0        0        0
 54.0:        0        0        0        0
 81.0:        0        0        0        0
108.0:        0        0        0        0
162.0:        0        0        0        0
216.0:        0        0        0        0
243.0:        0        0        0        0
270.0:        0        0        0        0
300.0:        0        0        0        0

2 (edited by linuxb 2009-08-30 15:14:24)

Re: HT40 mode

In the bleeding edge of hostap.git the wme_ parameters have changed name to wmm_.  But maybe you tested the hostap-06.git  then its still called wme_.

Anway I think the reason for 130mbs is that you dont have the actual wme parameters in your hostapd.conf file.

wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0

Edit: It could be that 40Mhz is not allowed on channel 153, I dont know. But its allowed fore channels between 36-60.

Re: HT40 mode

Thank you for answering.
I already tried all the available channels for HT40+ and HT40-
and a full set of the wme_* parameters, however it didn't work.
"iw wlan0 set channel 153 HT40-" was also run.

Re: HT40 mode

I guess you probably know more than me regarding this, since I (now) see that you have enabled debugging and a custom hostapd installation.
But what do you mean with: the full set of the wme_* parameters didn't work?
Did it work but only at 130mbs? or maybe it didn't work at all?
If you are using the hostap current development tree, then you have to rename
wme_enabled=1 to wmm_enabled=1 to get hostap working. (+ rename all the parameters)

FWIW here's my hostapd.conf and Im connecting at 300mbps:
root@OpenWrt:~# cat /var/run/hostapd-wlan0.conf
ctrl_interface=/var/run/hostapd-wlan0
driver=nl80211
interface=wlan0
hw_mode=a
channel=48
bridge=br-lan
ssid=OpenWrt
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
wme_enabled=1
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
wpa=2
wpa_pairwise=CCMP
country_code=NO
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-40][DSSS_CCK-40]


wpa_passphrase=xxxxxxx

Re: HT40 mode

My hostapd works only at 130Mbps/HT20 as you can see from the rcstat results.
I also tried all the possible configurations, including your hostapd.conf, but couldn't enable HT40.
hostapd.conf says

Please note that 40 MHz channels may switch their primary and secondary
channels if needed or creation of 40 MHz channel maybe rejected based
on overlapping BSSes. These changes are done automatically when hostapd
is setting up the 40 MHz channel.

However, I haven't seen any message regarding the rejection of 40MHz channel creation.
(It seems the debug mode with "debug=0xffffffff" doesn't give any useful HT-mode info to me.)
And, my bleeding-edge hostapd doesn't use wmm_*. I will get and test a new one.

Thank you.

Re: HT40 mode

Here can you see the 2 hostap git versions:
http://hostap.epitest.fi/gitweb/gitweb.cgi

I think you are using the hostap-06.git and not the most bleeding edge.
But that shouldnt matter because Im using the default openwrt version(0.6.9) and it works.

7 (edited by key4078 2009-09-02 21:58:02)

Re: HT40 mode

I got the most recent hostapd (2009-09-01) and the following messages while running it.

...
Scan for neighboring BSSes prior to enabling 40 MHz channel
Scan requested (ret=0) - scan timeout 10 seconds
Interface initialization will be completed in a callback
nl80211: Event message available
nl80211: Ignored unknown event (cmd=33)
nl80211: Event message available
nl80211: New scan results available
Received scan results (68 BSSes)
unknown vendor specific information element ignored (vendor OUI 00:10:18 len=9)
Switch own primary and secondary channel due to BSS overlap with 00:0f:7d:07:45:f6
Completing interface initialization
Mode: IEEE 802.11a  Channel: 149  Frequency: 5745 MHz
...

I set the primary channel as ch153 at hostapd.conf, however hostapd moved it to ch149. All the STAs were also associated in ch149.
(Probably it is because of the more strict 40MHz-channel rule in the new hostapd. http://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg01138.html
However, it is strange to me. The 5 GHz channels in my environment are not very crowded. I got 60Mbps throughput at 130Mbps/HT20 mode at every 5 GHz channel.
And, I couldn't find any AP having the MAC address of 00:0f:7d:07:45:f6 by iw wlan0 scan.)

I also tried all the other channels. In 5 GHz I got the same results (the primary channel was moved to the adjacent channel all the time),
but when I tested in 2.4 GHz the channel was not moved. Here are the messages I got with the ch11 setting.

...
40 MHz affected channel range: [2427,2477] MHz
Neighboring BSS: 00:0f:7d:07:41:e5 freq=2437 pri=0 sec=0
...
Neighboring BSS: 00:0f:7d:07:39:e7 freq=2437 pri=0 sec=0
Completing interface initialization
Mode: IEEE 802.11g  Channel: 11  Frequency: 2462 MHz
...

Anyway, the new hostapd also worked only at 130Mbps/HT20 (in both 2.4 and 5 Ghz). Orz

Re: HT40 mode

I just tried HT40 on some other channels, like 52,56,60,64. And my xp client would only connect with 130Mbps when I used these channels. But connected at 300Mbps again if I used channels between 36 - 48.  My ht_capab= HT40-/+ SHORT-GI-40  and DSSS_CCK-40

Re: HT40 mode

key4078,

I had the same problem as you with probably the same card. I eventually got it working. Could you post your whole dmesg output and also you /var/run/hostapd-wlan0.conf output ?

tanguy

Re: HT40 mode

Im connecting at 300mbps, but Im now seeing asymmetric file transfere speeds. Uploading a file from my windows client to my AP is allmost twice as fast as downloading the same file.
I have tried with sevral different clients and they all have this asymmetric throughput.

11 (edited by key4078 2009-09-16 21:07:15)

Re: HT40 mode

I tried all the available HT40+/- channel sets with MikroTik's (AR9220-based) R52N again, however hostapd still didn't work in HT40.
And, I got the same speed (around 60Mbps) while uploading and downloading.
The dmesg output with R52N is as following.

Linux version 2.6.28.10 (tchang@localhost.localdomain) (gcc version 4.1.2) #70 Wed Sep 16 19
CPU: XScale-IXP42x Family [690541c2] revision 2 (ARMv5TE), cr=000039ff
CPU: VIVT data cache, VIVT instruction cache
Machine: ADI Engineering Pronghorn
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat c052a208, node_mem_map c0544000
  DMA zone: 128 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 16256 pages, LIFO batch:3
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,10
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 59512KB available (2064K code, 184K data, 3104K init)
Calibrating delay loop... 532.48 BogoMIPS (lpj=2662400)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 428 bytes
NET: Registered protocol family 16
IXP4xx: Using 16MiB expansion bus window size
PCI: IXP4xx is host
PCI: IXP4xx Using direct access for memory space
pci 0000:00:10.0: reg 10 32bit mmio: [0x000000-0x00ffff]
pci 0000:00:10.0: PME# supported from D0 D3hot
pci 0000:00:10.0: PME# disabled
PCI: bus0: Fast back to back transfers enabled
pci 0000:00:10.0: dmabounce: registered device
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
IXP4xx Queue Manager initialized.
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  ?© 2001-2006 Red Hat, Inc.
msgmni has been set to 116
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xc8001000 (irq = 13) is a XScale
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xc8000000 (irq = 15) is a XScale
eth0: MII PHY 0 on NPE-B
eth1: MII PHY 1 on NPE-C
IXP4XX-Flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
IXP4XX-Flash.0: Found an alias at 0x1000000 for the chip at 0x0
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
Using auto-unlock on power-up/resume
cfi_cmdset_0001: Erase suspend on write enabled
erase region 0: offset=0x0,size=0x8000,blocks=4
erase region 1: offset=0x20000,size=0x20000,blocks=127
Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0xfe0000
5 RedBoot partitions found on MTD device IXP4XX-Flash.0
Creating 5 MTD partitions on "IXP4XX-Flash.0":
0x00000000-0x00060000 : "RedBoot"
0x00060000-0x00780000 : "linux"
0x00fa0000-0x00fe0000 : "mampf_nvram"
0x00fe0000-0x00fff000 : "FIS directory"
0x00fff000-0x01000000 : "RedBoot config"
i2c /dev entries driver
IXP4xx Watchdog Timer: heartbeat 60 sec
Registered led device: pronghorn:green:status
TCP westwood registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
XScale DSP coprocessor detected.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing init memory: 3104K
aead: exports duplicate symbol crypto_alloc_aead (owned by kernel)
crypto_hash: exports duplicate symbol crypto_hash_type (owned by kernel)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
        (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
        (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
        (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
PCI: enabling device 0000:00:10.0 (0340 -> 0342)
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'ath9k_rate_control'
Registered led device: ath9k-phy0::radio
Registered led device: ath9k-phy0::assoc
Registered led device: ath9k-phy0::tx
Registered led device: ath9k-phy0::rx
phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xc49a0000, irq=7
cfg80211: Calling CRDA for country: US
PPP generic driver version 2.4.2
cfg80211: Regulatory domain changed to country: US
        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
        (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
        (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
        (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
net eth0: firmware: requesting NPE-B
NPE-B: firmware's license can be found in /usr/share/doc/LICENSE.IPL
NPE-B: firmware functionality 0x2, revision 0x2:1
eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

Now, I'm looking at the source code of hostapd/compat_wireless,
and it seems it sets up the HT40 mode correctly until association.
In my environment, all the 2.4/5-GHz channels are shared with other non-11n APs (but not very busy).
I guess hostapd doesn't allow to use a shared channel as secondary
and always sends packets in HT20 regardless of the current HT mode.
I also found the following code in hostapd.default/hostapd/hw_features.c, which might give some hints.

static int ieee80211n_check_40mhz_5g(struct hostapd_iface *iface, struct wpa_scan_results *scan_res) {
...
    /* Switch PRI/SEC channels if Beacons were detected on selected SEC channel, but not on selected PRI channel. */
    pri_bss = sec_bss = 0;
    for (i = 0; i < scan_res->num; i++) {
        struct wpa_scan_res *bss = scan_res->res[i];
        if (bss->freq == pri_freq)
            pri_bss++;
        else if (bss->freq == sec_freq)
            sec_bss++;
    }
    if (sec_bss && !pri_bss) {
        wpa_printf(MSG_INFO, "Switch own primary and secondary channel to get secondary channel with no Beacons from other BSSes");
        ieee80211n_switch_pri_sec(iface);
    }

    /* Match PRI/SEC channel with any existing HT40 BSS on the same channels that we are about to use (if already mixed order in existing BSSes, use own preference). */
    match = 0;
    for (i = 0; i < scan_res->num; i++) {
        struct wpa_scan_res *bss = scan_res->res[i];
        ieee80211n_get_pri_sec_chan(bss, &bss_pri_chan, &bss_sec_chan);
        if (pri_chan == bss_pri_chan && sec_chan == bss_sec_chan) {
            match = 1;
            break;
        }
    }
    if (!match) {
        for (i = 0; i < scan_res->num; i++) {
            struct wpa_scan_res *bss = scan_res->res[i];
            ieee80211n_get_pri_sec_chan(bss, &pri_chan, &sec_chan);
            if (pri_chan == bss_sec_chan && sec_chan == bss_pri_chan) {
                wpa_printf(MSG_INFO, "Switch own primary and secondary channel due to BSS overlap with " MACSTR, MAC2STR(bss->bssid));
                ieee80211n_switch_pri_sec(iface);
                break;
            }
        }
    }
    return 1;
}

Re: HT40 mode

key4078,

I thought your problem was like mine: a regdomain problem. But this is not the case for you, as the 40 is allowed for your 5Ghz frequencies.
Unfortunately I cannot help you. A question: how did you manage to install the new hostapd (0.7) on Openwrt? I could install it under Ubuntu but not under Openwrt.

Thanks,

tanguy

13 (edited by key4078 2009-09-22 15:28:25)

Re: HT40 mode

tanguy, I downloaded the bleeding-edge hostapd and put its compressed file in /dl.
You will also have to modify package/hostapd/Makefile to change the filename (PKG_VERSION) and md5 checksum (PKG_MD5SUM)
and delete (or modify) some unneccesary patch files in /package/hostapd/patches/.


I found that sta->ht_cap.cap in rc.c was set as 0012 = 0x000c ( = IEEE80211_HT_CAP_SM_PS ),
but in both AR9160 and AR9220, it is supposed to be 4174 = 0x104e
( = IEEE80211_HT_CAP_DSSSCCK40 | IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SUP_WIDTH_20_40 ).
It seems the ht_cap parameter was delivered between STA and AP incorrectly while association.
So, I made ath_rate_init() set ath_rc_priv->ht_cap as 15 (not 9) all the time and could set up the HT40 mode.

However, after debugging, the throughput in TCP was still low (around 63Mbps @ 300Mbps/MCS15/40MHz/Short-GI & 7% PER).
I also found that the ping latency in the link is not asymmetric.
When I pinged from STA to AP, I got the latency around 2~3ms.
But, in case of pinging from AP to STA, the ping latency was large and irregular.

root@OpenWrt:/sys/kernel/debug/ieee80211/phy0/stations/c2dec224# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=64 time=95.110 ms
64 bytes from 192.168.1.2: seq=1 ttl=64 time=113.471 ms
64 bytes from 192.168.1.2: seq=2 ttl=64 time=30.123 ms
64 bytes from 192.168.1.2: seq=3 ttl=64 time=48.701 ms
64 bytes from 192.168.1.2: seq=4 ttl=64 time=67.194 ms
64 bytes from 192.168.1.2: seq=5 ttl=64 time=85.808 ms
64 bytes from 192.168.1.2: seq=6 ttl=64 time=103.953 ms
64 bytes from 192.168.1.2: seq=7 ttl=64 time=20.985 ms
64 bytes from 192.168.1.2: seq=8 ttl=64 time=39.249 ms
64 bytes from 192.168.1.2: seq=9 ttl=64 time=58.064 ms
64 bytes from 192.168.1.2: seq=10 ttl=64 time=76.601 ms
64 bytes from 192.168.1.2: seq=11 ttl=64 time=95.182 ms
64 bytes from 192.168.1.2: seq=12 ttl=64 time=113.767 ms
64 bytes from 192.168.1.2: seq=13 ttl=64 time=30.333 ms
64 bytes from 192.168.1.2: seq=14 ttl=64 time=48.956 ms
64 bytes from 192.168.1.2: seq=15 ttl=64 time=67.230 ms
64 bytes from 192.168.1.2: seq=16 ttl=64 time=85.793 ms
64 bytes from 192.168.1.2: seq=17 ttl=64 time=104.701 ms
64 bytes from 192.168.1.2: seq=18 ttl=64 time=21.567 ms
64 bytes from 192.168.1.2: seq=19 ttl=64 time=39.950 ms
64 bytes from 192.168.1.2: seq=20 ttl=64 time=58.474 ms
64 bytes from 192.168.1.2: seq=21 ttl=64 time=77.017 ms
64 bytes from 192.168.1.2: seq=22 ttl=64 time=197.599 ms
64 bytes from 192.168.1.2: seq=23 ttl=64 time=113.756 ms
64 bytes from 192.168.1.2: seq=24 ttl=64 time=30.809 ms
64 bytes from 192.168.1.2: seq=25 ttl=64 time=49.370 ms
64 bytes from 192.168.1.2: seq=26 ttl=64 time=67.873 ms
64 bytes from 192.168.1.2: seq=27 ttl=64 time=86.687 ms

It might be because another parameter (power saving?) was set incorrectly. I'm still looking at the source code.

Re: HT40 mode

Nice find.

Im using an ar5416 in as AP.  (ar5418 as STA)
I just checked and I do have the same large and irregular latency when pinging from AP to STA. 
So it could be the reason for my asymmetric throughput.

Re: HT40 mode

Thanks key4078,

I could install it, but the results are not better than with the 0.6.9. I've got also a max throughput of 83 Mbps at 300/40 with my AR9160. This is not satisfactory. However the ping is good.
I could not find what to modify in the rc.c. Are you talking about the rc.c of ath9k?

tanguy

16 (edited by key4078 2009-09-29 20:11:23)

Re: HT40 mode

The version of ath9k OpenWrt uses may vary depending on the target platform.
I'm using ath9k in compat-wireless-2009-09-14 (updated from 2009-09-03).
I just checked the bleeding-edge one (2009-09-21), and ath_rate_init() in rc.c was still the same.
My patch for rc.c is as following.

    } else if (sc->sc_ah->opmode == NL80211_IFTYPE_AP) {
        /* cur_rate_table would be set on init through config() */
        rate_table = sc->cur_rate_table;
    }

-    ath_rc_priv->ht_cap = ath_rc_build_ht_caps(sc, sta, is_cw40, is_sgi40);
+    ath_rc_priv->ht_cap = 15;
    ath_rc_init(sc, priv_sta, sband, sta, rate_table);

I also got a LiteStation-SR71 board w/ an SR71-A radio and did various tests.
Interestingly, it worked with my IXP425 board very well in both STA and AP mode.
(got 95Mbps inTCP/HT40/300Mbps; it was limited by the 100Mbps Ethernet port).
Without the "=15" patch, LS-SR71 set ht_cap to 13 (not 9) in AP mode.

UPDATE:

This patch for nl80211_new_station() in /net/wireless/nl80211.c also will work.
(This patch is for nl80211. Choose either one between ath9k patch and nl80211 patch.)

    if (info->attrs[NL80211_ATTR_HT_CAPABILITY])
-        params.ht_capa = nla_data(info->attrs[NL80211_ATTR_HT_CAPABILITY]);
+        params.ht_capa->cap_info = cpu_to_le16(4174);

    if (parse_station_flags(info, &params))
        return -EINVAL;

These patches fix the operation mode at SMPS/HT40/SGI40/DSSSCCK40.
If you want to test other modes, look at /include/linux/ieee80211.h and
choose a desired combination of IEEE80211_HT_CAP_* (in dec, not in hex).
FYI: Without patch, mac80211 chooses 3072=0x0c00 for AR9220 (instead of 4174=0x104e).

I'm still trying to figure out why the original code doesn't give the correct ht_cap value.

17

Re: HT40 mode

The ht_cap mismatch was a bug in hostapd. I fixed it in r18405, please try a recent version and let me know if you manage to get the full HT40 throughput

Re: HT40 mode

It's not possible, because it should be wmm instead of wme in /lib/wifi/hostapd.sh with the version 0.7 of hostapd ;-)

Re: HT40 mode

Now it works well without my patch. Thank you.
In the throughput test (w/r18615, iperf, RouterStation Pro/R52N, @300Mbps/HT40),
I got 140Mbps in uni-directional UDP and 90Mbps (per direction) in bi-directional UDP.
However, I'm still getting 60Mbps in TCP (one-way transfer, 60%@AP & 70%@STA CPU idle).
Probably I have to study more about how TCP works with 802.11n. smile