mac80211/ath9k/hostapd: Some clients unable to associate with AP

mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Björn Smedman]

Hi all,

I'm trying to update from compat-wireless-2009-06-02 to
compat-wireless-2.6.32-rc1. After the update some clients can
no-longer associate with the access point (mac80211/ath9k/hostapd).
Specifically, it seems windows based clients do not accept the new
association response frame and choke or send deauth.

A tcpdump from a separate machine shows the story. After the update
with compat-wireless-2.6.32-rc1 the dump locks like this (notice the
deauth frame from the XP laptop at the end):

	19:59:18.973699 1573025241us tsft 1.0 Mb/s 2412 MHz (0x0080) -53dB
signal 0dB noise antenna 0 BSSID:ff:ff:ff:ff:ff:ff
DA:ff:ff:ff:ff:ff:ff SA:00:13:02:36:ab:37 Probe Request
(demo.venatech.net) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
	19:59:18.975919 1573026699us tsft 1.0 Mb/s 2412 MHz (0x0080) -57dB
signal 0dB noise antenna 0 BSSID:00:23:cd:de:2f:c5
DA:00:13:02:36:ab:37 SA:00:23:cd:de:2f:c5 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	19:59:18.977723 1573028524us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	19:59:18.981060 1573031853us tsft 1.0 Mb/s 2412 MHz (0x0080) -67dB
signal 0dB noise antenna 0 BSSID:00:23:cd:c7:c3:fd
DA:00:13:02:36:ab:37 SA:00:23:cd:c7:c3:fd Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	19:59:19.019827 1573071924us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -53dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 Authentication (Open
System)-1: Succesful
	19:59:19.022448 1573074291us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Authentication (Open
System)-2:
	19:59:19.022963 1573075062us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -52dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 Assoc Request
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit]
	19:59:19.096487 1573147524us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Assoc Response AID(2) ::
Succesful
	19:59:19.227409 1573279582us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -52dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 DeAuthentication:
Unspecified reason

With compat-wireless-2009-06-02 the (successful) dump locks like this:

	20:01:56.525502 433315165us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:ff:ff:ff:ff:ff:ff
DA:ff:ff:ff:ff:ff:ff SA:00:13:02:36:ab:37 Probe Request
(demo.venatech.net) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
	20:01:56.527462 433316613us tsft 1.0 Mb/s 2412 MHz (0x0080) -44dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	20:01:56.541231 433330271us tsft 1.0 Mb/s 2412 MHz (0x0080) -44dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	20:01:56.542509 433331546us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	20:01:56.543874 433332939us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	20:01:56.545297 433334332us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
1
	20:01:56.556071 433346142us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -41dB signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:25:86:d9:61:a7 SA:00:13:02:36:ab:37 Authentication (Open
System)-1: Succesful
	20:01:56.558199 433347993us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Authentication (Open
System)-2:
	20:01:56.558653 433348766us tsft short preamble 54.0 Mb/s 2412 MHz
(0x0080) -41dB signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:25:86:d9:61:a7 SA:00:13:02:36:ab:37 Assoc Request
(demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit]
	20:01:56.634096 433423226us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Assoc Response AID(2) ::
Succesful

I've also tried some other windows based clients, e.g. a laptop with
an old 11b 3Com PCMCIA card. Most seem to choke from the auth response
or assoc response frame. The hostapd/syslog on the AP side looks
something like this:

	MGMT
	mgmt::auth
	authentication: STA=00:04:75:c4:1e:a5 auth_alg=0 auth_transaction=1
status_code=0 wep=0
	ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authentication OK (open system)
	ap0: STA 00:04:75:c4:1e:a5 MLME:
MLME-AUTHENTICATE.indication(00:04:75:c4:1e:a5, OPEN_SYSTEM)
	ap0: STA 00:04:75:c4:1e:a5 MLME: MLME-DELETEKEYS.request(00:04:75:c4:1e:a5)
	authentication reply: STA=00:04:75:c4:1e:a5 auth_alg=0
auth_transaction=2 resp=0 (IE len=0)
	MGMT (TX callback) ACK
	mgmt::auth cb
	ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authenticated
	Jan  1 03:33:12 00:23:CD:DA:3C:04 daemon.info hostapd: ap0: STA
00:04:75:c4:1e:a5 IEEE 802.11: authenticated
	STA 00:04:75:c4:1e:a5 sent probe request for broadcast SSID
	STA 00:04:75:c4:1e:a5 sent probe request for our SSID
	MGMT (TX callback) fail
	mgmt::proberesp cb
	MGMT (TX callback) fail
	mgmt::proberesp cb
	MGMT
	mgmt::auth
	authentication: STA=00:04:75:c4:1e:a5 auth_alg=0 auth_transaction=1
status_code=0 wep=0
	ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authentication OK (open system)
	ap0: STA 00:04:75:c4:1e:a5 MLME:
MLME-AUTHENTICATE.indication(00:04:75:c4:1e:a5, OPEN_SYSTEM)
	ap0: STA 00:04:75:c4:1e:a5 MLME: MLME-DELETEKEYS.request(00:04:75:c4:1e:a5)
	authentication reply: STA=00:04:75:c4:1e:a5 auth_alg=0
auth_transaction=2 resp=0 (IE len=0)
	STA 00:22:fa:f8:17:c8 sent probe request for broadcast SSID
	MGMT (TX callback) ACK
	mgmt::auth cb
	ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authenticated

        [And so on over and over...]

I've also tried some different versions of hostapd: 0.6.9 and two
different git snapshots from 0.7-branch (a35187e71a1dd23653fc03ed5
and 6d6f4bb87f33278aed133875d0d561eb55d7ae59) but it doesn't seem to
make any difference. My configuration file is really simple:

	driver=nl80211
	interface=ap0
	ctrl_interface=/var/run/
	hostapd-vtmd
	hw_mode=g
	channel=1
	ssid=demo.venatech.net
	ieee80211n=1
	ht_capab=

Does anybody recognize this? Any ideas on what to try next? Any help
would be greatly appreciated.

/Björn

Re: mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Björn Smedman]

Hi again,

I've now checked the latest compat-wireless snapshot (2009-10-21) and
it has the same problem: Windows based clients with 11g or 11b cards
cannot connect to a mac80211/ath9k/hostapd based AP. It used to work
with compat-wireless-2009-06-02.

I've tried an Intel PRO Wireless 3945ABG card and an older 3Com
3CRWE62092B card. The Intel card seems to accept the auth response but
chokes on the assoc response while the 3Com card ignores the auth
response and just sends auth request indefinitely. This time I used
hostapd 0.6.9 in all tests.

All the non-windows 11g clients I've tried all work (an iPhone and a
Google Dev G1). I only have access to one 11n capable windows based
client (Ralink noname card) but that one works just fine and connects
to the AP on the first attempt.

Any ideas on how to track this down? I can enable some logs and hack
together some patches to track this down, I'm just not sure where to
start. Bisecting is difficult for me as I can only build
compat-wireless and only on OpenWrt... Thanx for any help in advance.

/Björn

2009/10/20 Björn Smedman <bjorn.smedman@venatech.se>:
> Hi all,
>
> I'm trying to update from compat-wireless-2009-06-02 to
> compat-wireless-2.6.32-rc1. After the update some clients can
> no-longer associate with the access point (mac80211/ath9k/hostapd).
> Specifically, it seems windows based clients do not accept the new
> association response frame and choke or send deauth.
>
> A tcpdump from a separate machine shows the story. After the update
> with compat-wireless-2.6.32-rc1 the dump locks like this (notice the
> deauth frame from the XP laptop at the end):
>
>        19:59:18.973699 1573025241us tsft 1.0 Mb/s 2412 MHz (0x0080) -53dB
> signal 0dB noise antenna 0 BSSID:ff:ff:ff:ff:ff:ff
> DA:ff:ff:ff:ff:ff:ff SA:00:13:02:36:ab:37 Probe Request
> (demo.venatech.net) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
>        19:59:18.975919 1573026699us tsft 1.0 Mb/s 2412 MHz (0x0080) -57dB
> signal 0dB noise antenna 0 BSSID:00:23:cd:de:2f:c5
> DA:00:13:02:36:ab:37 SA:00:23:cd:de:2f:c5 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        19:59:18.977723 1573028524us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
> signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
> DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        19:59:18.981060 1573031853us tsft 1.0 Mb/s 2412 MHz (0x0080) -67dB
> signal 0dB noise antenna 0 BSSID:00:23:cd:c7:c3:fd
> DA:00:13:02:36:ab:37 SA:00:23:cd:c7:c3:fd Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        19:59:19.019827 1573071924us tsft short preamble 54.0 Mb/s 2412 MHz
> (0x0080) -53dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
> DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 Authentication (Open
> System)-1: Succesful
>        19:59:19.022448 1573074291us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
> signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
> DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Authentication (Open
> System)-2:
>        19:59:19.022963 1573075062us tsft short preamble 54.0 Mb/s 2412 MHz
> (0x0080) -52dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
> DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 Assoc Request
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit]
>        19:59:19.096487 1573147524us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
> signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
> DA:00:13:02:36:ab:37 SA:00:23:cd:da:3c:05 Assoc Response AID(2) ::
> Succesful
>        19:59:19.227409 1573279582us tsft short preamble 54.0 Mb/s 2412 MHz
> (0x0080) -52dB signal 0dB noise antenna 0 BSSID:00:23:cd:da:3c:05
> DA:00:23:cd:da:3c:05 SA:00:13:02:36:ab:37 DeAuthentication:
> Unspecified reason
>
> With compat-wireless-2009-06-02 the (successful) dump locks like this:
>
>        20:01:56.525502 433315165us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
> signal 0dB noise antenna 0 BSSID:ff:ff:ff:ff:ff:ff
> DA:ff:ff:ff:ff:ff:ff SA:00:13:02:36:ab:37 Probe Request
> (demo.venatech.net) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
>        20:01:56.527462 433316613us tsft 1.0 Mb/s 2412 MHz (0x0080) -44dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        20:01:56.541231 433330271us tsft 1.0 Mb/s 2412 MHz (0x0080) -44dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        20:01:56.542509 433331546us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        20:01:56.543874 433332939us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        20:01:56.545297 433334332us tsft 1.0 Mb/s 2412 MHz (0x0080) -43dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Probe Response
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] CH:
> 1
>        20:01:56.556071 433346142us tsft short preamble 54.0 Mb/s 2412 MHz
> (0x0080) -41dB signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:25:86:d9:61:a7 SA:00:13:02:36:ab:37 Authentication (Open
> System)-1: Succesful
>        20:01:56.558199 433347993us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Authentication (Open
> System)-2:
>        20:01:56.558653 433348766us tsft short preamble 54.0 Mb/s 2412 MHz
> (0x0080) -41dB signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:25:86:d9:61:a7 SA:00:13:02:36:ab:37 Assoc Request
> (demo.venatech.net) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit]
>        20:01:56.634096 433423226us tsft 1.0 Mb/s 2412 MHz (0x0080) -42dB
> signal 0dB noise antenna 0 BSSID:00:25:86:d9:61:a7
> DA:00:13:02:36:ab:37 SA:00:25:86:d9:61:a7 Assoc Response AID(2) ::
> Succesful
>
> I've also tried some other windows based clients, e.g. a laptop with
> an old 11b 3Com PCMCIA card. Most seem to choke from the auth response
> or assoc response frame. The hostapd/syslog on the AP side looks
> something like this:
>
>        MGMT
>        mgmt::auth
>        authentication: STA=00:04:75:c4:1e:a5 auth_alg=0 auth_transaction=1
> status_code=0 wep=0
>        ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authentication OK (open system)
>        ap0: STA 00:04:75:c4:1e:a5 MLME:
> MLME-AUTHENTICATE.indication(00:04:75:c4:1e:a5, OPEN_SYSTEM)
>        ap0: STA 00:04:75:c4:1e:a5 MLME: MLME-DELETEKEYS.request(00:04:75:c4:1e:a5)
>        authentication reply: STA=00:04:75:c4:1e:a5 auth_alg=0
> auth_transaction=2 resp=0 (IE len=0)
>        MGMT (TX callback) ACK
>        mgmt::auth cb
>        ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authenticated
>        Jan  1 03:33:12 00:23:CD:DA:3C:04 daemon.info hostapd: ap0: STA
> 00:04:75:c4:1e:a5 IEEE 802.11: authenticated
>        STA 00:04:75:c4:1e:a5 sent probe request for broadcast SSID
>        STA 00:04:75:c4:1e:a5 sent probe request for our SSID
>        MGMT (TX callback) fail
>        mgmt::proberesp cb
>        MGMT (TX callback) fail
>        mgmt::proberesp cb
>        MGMT
>        mgmt::auth
>        authentication: STA=00:04:75:c4:1e:a5 auth_alg=0 auth_transaction=1
> status_code=0 wep=0
>        ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authentication OK (open system)
>        ap0: STA 00:04:75:c4:1e:a5 MLME:
> MLME-AUTHENTICATE.indication(00:04:75:c4:1e:a5, OPEN_SYSTEM)
>        ap0: STA 00:04:75:c4:1e:a5 MLME: MLME-DELETEKEYS.request(00:04:75:c4:1e:a5)
>        authentication reply: STA=00:04:75:c4:1e:a5 auth_alg=0
> auth_transaction=2 resp=0 (IE len=0)
>        STA 00:22:fa:f8:17:c8 sent probe request for broadcast SSID
>        MGMT (TX callback) ACK
>        mgmt::auth cb
>        ap0: STA 00:04:75:c4:1e:a5 IEEE 802.11: authenticated
>
>        [And so on over and over...]
>
> I've also tried some different versions of hostapd: 0.6.9 and two
> different git snapshots from 0.7-branch (a35187e71a1dd23653fc03ed5
> and 6d6f4bb87f33278aed133875d0d561eb55d7ae59) but it doesn't seem to
> make any difference. My configuration file is really simple:
>
>        driver=nl80211
>        interface=ap0
>        ctrl_interface=/var/run/
>        hostapd-vtmd
>        hw_mode=g
>        channel=1
>        ssid=demo.venatech.net
>        ieee80211n=1
>        ht_capab=
>
> Does anybody recognize this? Any ideas on what to try next? Any help
> would be greatly appreciated.
>
> /Björn
>



-- 
Venatech AB
Ideon Innovation
Ole Römers väg 12
SE-22370 LUND
Sweden

+46 (0) 46 286 86 20
info@venatech.se
http://www.venatech.se

Re: mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Jouni Malinen]

On Wed, Oct 21, 2009 at 01:48:09PM +0200, Björn Smedman wrote:

> I've now checked the latest compat-wireless snapshot (2009-10-21) and
> it has the same problem: Windows based clients with 11g or 11b cards
> cannot connect to a mac80211/ath9k/hostapd based AP. It used to work
> with compat-wireless-2009-06-02.

> Any ideas on how to track this down? I can enable some logs and hack
> together some patches to track this down, I'm just not sure where to
> start. Bisecting is difficult for me as I can only build
> compat-wireless and only on OpenWrt... Thanx for any help in advance.

Would you be able to send me a wireless capture log (i.e., the binary
file with all the frames, not such a text dump of some information)
showing the frames exchanged in the failure and success cases? I would
be especially interested in seeing the Beacon frames which were not
shown in your previous message. I'm currently traveling and cannot
easily try to reproduce this before returning home.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Will Dyson]

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

Jouni Malinen wrote:
> Would you be able to send me a wireless capture log (i.e., the binary
> file with all the frames, not such a text dump of some information)
> showing the frames exchanged in the failure and success cases? I would
> be especially interested in seeing the Beacon frames which were not
> shown in your previous message. I'm currently traveling and cannot
> easily try to reproduce this before returning home.


I also have an ath9k-based OpenWrt router, and see the same issue when
running the latest builds.

I've reproduced the problem with the very latest svn (which uses
compat-wireless 2009-10-09 and kernel 2.6.30.8) and the tree as of
2009-06-20 (which uses compat-wirless 2009-06-02 and a local patch to
use kernel 2.6.30). Both have hostapd 0.6.9.

The router's MAC is 00:90:cc:f4:9b:98.
The client is an IPW2200 (linux driver from 2.6.28) with MAC 00:12:f0:74:ae:f9

There is a WPA2-PSK passphrase of "testpass" set.

Attached are the complete binary dumps, fail.pcap and win.pcap.

Interestingly, Linux 2.6.32-rc5 with a rt61 pci card crashes with a
BUG_ON() when I try to associate with the bad version.

kernel BUG at net/mac80211/agg-rx.c:90!
invalid opcode: 0000 [#1] PREEMPT SMP

I've recompiled with debug info turned and will follow up to the
appropriate mailing list next time I am ready to crash my workstation
:p

-- 
Will Dyson

[-- Attachment #2: fail.pcap.gz --]
[-- Type: application/x-gzip, Size: 25075 bytes --]

[-- Attachment #3: win.pcap.gz --]
[-- Type: application/x-gzip, Size: 33907 bytes --]

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Jouni Malinen]

On Thu, Oct 22, 2009 at 07:45:29PM -0400, Will Dyson wrote:

> I also have an ath9k-based OpenWrt router, and see the same issue when
> running the latest builds.
> 
> I've reproduced the problem with the very latest svn (which uses
> compat-wireless 2009-10-09 and kernel 2.6.30.8) and the tree as of
> 2009-06-20 (which uses compat-wirless 2009-06-02 and a local patch to
> use kernel 2.6.30). Both have hostapd 0.6.9.

> Attached are the complete binary dumps, fail.pcap and win.pcap.

Thanks! This seems to confirm that the issue is indeed related to the
sequence number on the frames not being set correctly (for other than
Beacon frames).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Joerg Pommnitz]

Since Jouni has confirmed my suspicion about the invalid sequence number I will refrain from spamming the list with tcpdumps. 
Will, thanks for bringing me into the loop of this discussion!

 -- 
Regards 
Joerg 


      

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Björn Smedman]

Hi all,

It seems the problem is a typo in net/mac80211/tx.c that causes
injected frames from hostapd not to be associated with the correct ap
interface before going into ieee80211_tx_h_sequence(). This tiny patch
solves my problems (and looks reasonable to me in any case):

diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
compat-wireless-2009-10-21/net/mac80211/tx.c
--- compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
 2009-10-23 17:20:52.000000000 +0200
+++ compat-wireless-2009-10-21/net/mac80211/tx.c        2009-10-23
17:21:28.000000000 +0200
@@ -1445,7 +1445,7 @@
                                if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
                                        continue;
                                if (compare_ether_addr(tmp_sdata->dev->dev_addr,
-                                                      hdr->addr2)) {
+                                                      hdr->addr2) == 0) {
                                        dev_hold(tmp_sdata->dev);
                                        dev_put(sdata->dev);
                                        sdata = tmp_sdata;


/Björn

2009/10/23 Björn Smedman <bjorn.smedman@venatech.se>
>
> Hi all,
> Thanks for your help. I will also keep my tcpdumps to myself for now.
> Is anybody working on a fix? I suspect it's a misunderstanding between hostapd and mac80211 about who should set the sequence number on injected frames, correct? Could you describe the outlines of the appropriate patch so I could experiment and verify that this is my problem?
> /Björn
> On Fri, Oct 23, 2009 at 11:15 AM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
>>
>> Since Jouni has confirmed my suspicion about the invalid sequence number I will refrain from spamming the list with tcpdumps.
>> Will, thanks for bringing me into the loop of this discussion!
>>
>>  --
>> Regards
>> Joerg
>>
>>
>>
>
>
>
> --
> Venatech AB
> Ideon Innovation
> Ole Römers väg 12
> SE-22370 LUND
> Sweden
>
> +46 (0) 46 286 86 20
> info@venatech.se
> http://www.venatech.se

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Jouni Malinen]

On Fri, Oct 23, 2009 at 05:27:27PM +0200, Björn Smedman wrote:

> It seems the problem is a typo in net/mac80211/tx.c that causes
> injected frames from hostapd not to be associated with the correct ap
> interface before going into ieee80211_tx_h_sequence(). This tiny patch
> solves my problems (and looks reasonable to me in any case):

Thanks! Would you be able to make the same patch against the
wireless-testing.git repository and add a Signed-off-by line to meet the
kernel submission requirements?

> diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
> compat-wireless-2009-10-21/net/mac80211/tx.c
> @@ -1445,7 +1445,7 @@
>                                 if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
>                                         continue;
>                                 if (compare_ether_addr(tmp_sdata->dev->dev_addr,
> -                                                      hdr->addr2)) {
> +                                                      hdr->addr2) == 0) {
>                                         dev_hold(tmp_sdata->dev);
>                                         dev_put(sdata->dev);
>                                         sdata = tmp_sdata;

This does indeed look like a typo. Though, I'm not sure how this would
have caused a regression between compat-wireless-2009-06-02 and
compat-wireless-2.6.32-rc1. The incorrect compare_ether_addr() use seems
to be there in the original commit that added this code
(25d834e16294c8dfd923dae6bdb8a055391a99a5 from September 12, 2008)..

Johannes: Any idea why the sequence number allocation for injected
frames from hostapd would have changed between 2009-06-02 and now? This
bug seems to be too old to explain that ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Johannes Berg]

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

On Fri, 2009-10-23 at 09:30 -0700, Jouni Malinen wrote:

> > diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
> > compat-wireless-2009-10-21/net/mac80211/tx.c
> > @@ -1445,7 +1445,7 @@
> >                                 if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
> >                                         continue;
> >                                 if (compare_ether_addr(tmp_sdata->dev->dev_addr,
> > -                                                      hdr->addr2)) {
> > +                                                      hdr->addr2) == 0) {
> >                                         dev_hold(tmp_sdata->dev);
> >                                         dev_put(sdata->dev);
> >                                         sdata = tmp_sdata;
> 
> This does indeed look like a typo. Though, I'm not sure how this would
> have caused a regression between compat-wireless-2009-06-02 and
> compat-wireless-2.6.32-rc1. The incorrect compare_ether_addr() use seems
> to be there in the original commit that added this code
> (25d834e16294c8dfd923dae6bdb8a055391a99a5 from September 12, 2008)..
> 
> Johannes: Any idea why the sequence number allocation for injected
> frames from hostapd would have changed between 2009-06-02 and now? This
> bug seems to be too old to explain that ;-).

Indeed, I have no idea though.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Björn Smedman]

2009/10/23 Jouni Malinen <j@w1.fi>:
> On Fri, Oct 23, 2009 at 05:27:27PM +0200, Björn Smedman wrote:
>
>> It seems the problem is a typo in net/mac80211/tx.c that causes
>> injected frames from hostapd not to be associated with the correct ap
>> interface before going into ieee80211_tx_h_sequence(). This tiny patch
>> solves my problems (and looks reasonable to me in any case):
>
> Thanks! Would you be able to make the same patch against the
> wireless-testing.git repository and add a Signed-off-by line to meet the
> kernel submission requirements?

It's time i learn. :) I'll give it a shot tomorrow.

>
>> diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
>> compat-wireless-2009-10-21/net/mac80211/tx.c
>> @@ -1445,7 +1445,7 @@
>>                                 if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
>>                                         continue;
>>                                 if (compare_ether_addr(tmp_sdata->dev->dev_addr,
>> -                                                      hdr->addr2)) {
>> +                                                      hdr->addr2) == 0) {
>>                                         dev_hold(tmp_sdata->dev);
>>                                         dev_put(sdata->dev);
>>                                         sdata = tmp_sdata;
>
> This does indeed look like a typo. Though, I'm not sure how this would
> have caused a regression between compat-wireless-2009-06-02 and
> compat-wireless-2.6.32-rc1. The incorrect compare_ether_addr() use seems
> to be there in the original commit that added this code
> (25d834e16294c8dfd923dae6bdb8a055391a99a5 from September 12, 2008)..

Interesting puzzle. :) It looks like there was a complementary bug
(the pointer hdr was set to point len_rthdr * sizeof(struct
ieee80211_hdr) bytes into the skbuff) in that commit:
...
+		len_rthdr = ieee80211_get_radiotap_len(skb->data);
+		hdr = (struct ieee80211_hdr *)skb->data + len_rthdr;
...
So the frame source address used to be compared with random data which
was likely to result in inequality, causing the first ap interface to
be "found" and the code to work as expected. I guess the pointer bug
was fixed somewhere between 2006-06-02 and now "causing" the sequence
number problem.

/Björn

Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Johannes Berg]

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

On Sat, 2009-10-24 at 05:12 +0200, Björn Smedman wrote:

> >> diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
> >> compat-wireless-2009-10-21/net/mac80211/tx.c
> >> @@ -1445,7 +1445,7 @@
> >>                                 if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
> >>                                         continue;
> >>                                 if (compare_ether_addr(tmp_sdata->dev->dev_addr,
> >> -                                                      hdr->addr2)) {
> >> +                                                      hdr->addr2) == 0) {
> >>                                         dev_hold(tmp_sdata->dev);
> >>                                         dev_put(sdata->dev);
> >>                                         sdata = tmp_sdata;
> >
> > This does indeed look like a typo. Though, I'm not sure how this would
> > have caused a regression between compat-wireless-2009-06-02 and
> > compat-wireless-2.6.32-rc1. The incorrect compare_ether_addr() use seems
> > to be there in the original commit that added this code
> > (25d834e16294c8dfd923dae6bdb8a055391a99a5 from September 12, 2008)..
> 
> Interesting puzzle. :) It looks like there was a complementary bug
> (the pointer hdr was set to point len_rthdr * sizeof(struct
> ieee80211_hdr) bytes into the skbuff) in that commit:
> ...
> +		len_rthdr = ieee80211_get_radiotap_len(skb->data);
> +		hdr = (struct ieee80211_hdr *)skb->data + len_rthdr;
> ...
> So the frame source address used to be compared with random data which
> was likely to result in inequality, causing the first ap interface to
> be "found" and the code to work as expected. I guess the pointer bug
> was fixed somewhere between 2006-06-02 and now "causing" the sequence
> number problem.

Heh, indeed, interesting. I remember somebody fixing that, but was
unaware of the second bug (obviously).

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

RE: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

[Joerg Pommnitz]

I'll test tomorrow. Something is bothering me here: I have a current wireless-testing kernel
with ath5k and ath9 driver. I have traces that show that Win Vista successfully associates
with ath5k running in AP mode but fails with ath9k. How is this difference possible if the bug
is in the common code? Might there be another offsetting bug in ath5k?

 -- 
Regards 
Joerg 




----- Ursprüngliche Mail ----
Von: Jouni Malinen <j@w1.fi>
An: Björn Smedman <bjorn.smedman@venatech.se>
CC: Joerg Pommnitz <pommnitz@yahoo.com>; Will Dyson <will.dyson@gmail.com>; Johannes Berg <johannes@sipsolutions.net>; ath9k-devel@venema.h4ckr.net; linux-wireless@vger.kernel.org
Gesendet: Freitag, den 23. Oktober 2009, 18:30:01 Uhr
Betreff: Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP

On Fri, Oct 23, 2009 at 05:27:27PM +0200, Björn Smedman wrote:

> It seems the problem is a typo in net/mac80211/tx.c that causes
> injected frames from hostapd not to be associated with the correct ap
> interface before going into ieee80211_tx_h_sequence(). This tiny patch
> solves my problems (and looks reasonable to me in any case):

Thanks! Would you be able to make the same patch against the
wireless-testing.git repository and add a Signed-off-by line to meet the
kernel submission requirements?

> diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
> compat-wireless-2009-10-21/net/mac80211/tx.c
> @@ -1445,7 +1445,7 @@
>                                 if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
>                                         continue;
>                                 if (compare_ether_addr(tmp_sdata->dev->dev_addr,
> -                                                      hdr->addr2)) {
> +                                                      hdr->addr2) == 0) {
>                                         dev_hold(tmp_sdata->dev);
>                                         dev_put(sdata->dev);
>                                         sdata = tmp_sdata;

This does indeed look like a typo. Though, I'm not sure how this would
have caused a regression between compat-wireless-2009-06-02 and
compat-wireless-2.6.32-rc1. The incorrect compare_ether_addr() use seems
to be there in the original commit that added this code
(25d834e16294c8dfd923dae6bdb8a055391a99a5 from September 12, 2008)..

Johannes: Any idea why the sequence number allocation for injected
frames from hostapd would have changed between 2009-06-02 and now? This
bug seems to be too old to explain that ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA