Ubuntu
linux-restricted-modules-2.6.22 package

[gutsy] ath_pci not running well w/ 11g

Bug #139391 reported by jbj on 2007-09-13

This bug report is a duplicate of: Bug #208306: [ath_pci] cannot connect to hidden ap. Edit Remove

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	linux-restricted-modules-2.6.22 (Ubuntu)	New	Undecided	Unassigned

Bug Description

I have a Thinkpad T60p with AR5212 atheros chip, and it works somewhat with 11b, however a LEAP access point with hidden ESSID it fails to work with consistantly:
/home/jbj/Dwpa_supplicant -Dwext -c wpa_supplicant.conf -i ath0
Trying to associate with SSID '<SSID>'
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with SSID '<SSID>'
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with SSID '<SSID>'
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with SSID '<SSID>'
Associated with 00:12:7f:75:cf:b0
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Trying to associate with SSID '<SSID>'
Associated with 00:12:7f:75:cf:b0
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Trying to associate with SSID '<SSID>'
Associated with 00:12:7f:75:cf:b0
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Trying to associate with SSID '<SSID>'
....

However wpa_supplicant can operate if set to 11b:
# iwpriv ath0 mode 11b;wpa_supplicant -Dwext -c wpa_supplicant.conf -i ath0
Trying to associate with SSID '<SSID>'
Associated with 00:17:0f:e4:83:70
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 17 (LEAP) selected
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
CTRL-EVENT-CONNECTED - Connection to 00:17:0f:e4:83:70 completed (auth) [id=0 id_str=]

However DHCP still doesn't work....

$ sudo dhclient ath0
There is already a pid file /var/run/dhclient.pid with pid 7433
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.5
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wifi0: unknown hardware address type 801
wifi0: unknown hardware address type 801
Listening on LPF/ath0/00:19:7d:88:fd:31
Sending on LPF/ath0/00:19:7d:88:fd:31
Sending on Socket/fallback
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 12

It works completely against a WPA2-personal AP, but only in mode 11b.

Revision history for this message

jbj (jbj-ubu) wrote on 2007-09-14:

To follow up, on the dhclient failure, I do see this if I enablesufficient debug:
Sep 14 09:33:47 vorfeed kernel: [ 2777.084000] [ath0:00:05:4e:45:d8:42] discard data frame, unauthorized port: ether type 0x800 len 92
Sep 14 09:33:48 vorfeed kernel: [ 2777.704000] [ath0:00:d0:05:9d:64:0a] discard data frame, unauthorized port: ether type 0x806 len 60
Sep 14 09:33:48 vorfeed kernel: [ 2777.704000] [ath0:00:05:4e:45:d8:42] discard data frame, unauthorized port: ether type 0x800 len 92
Sep 14 09:33:48 vorfeed kernel: [ 2778.516000] [ath0:00:12:da:f5:ea:80] discard data frame, unauthorized port: ether type 0x806 len 60
Sep 14 09:33:49 vorfeed kernel: [ 2778.576000] [ath0:00:12:7f:75:cf:b0] discard frame, multicast echo
Sep 14 09:33:49 vorfeed kernel: [ 2778.584000] [ath0:00:d0:05:9d:64:0a] discard data frame, unauthorized port: ether type 0x800 len 342
Sep 14 09:33:49 vorfeed kernel: [ 2779.344000] [ath0:00:05:4e:45:d8:42] discard data frame, unauthorized port: ether type 0x800 len 92
Sep 14 09:33:50 vorfeed kernel: [ 2779.748000] [ath0:00:02:8a:5c:b0:a1] discard data frame, unauthorized port: ether type 0x800 len 92
Sep 14 09:33:50 vorfeed kernel: [ 2779.952000] [ath0:00:d0:05:9d:64:0a] discard data frame, unauthorized port: ether type 0x806 len 60
Sep 14 09:33:50 vorfeed kernel: [ 2780.092000] [ath0:00:05:4e:45:d8:42] discard data frame, unauthorized port: ether type 0x800 len 92

Note the line with a len of 342. A DHCPOFFER would be 342 bytes in length...

Revision history for this message

jbj (jbj-ubu) wrote on 2007-09-14:

I did digging in the driver, and found that line 868 of ieee80211_input.c was the part giving the message, traced the node_is_authorized and found that exceptions are made for 8021X (LEAP notably). I didn't dig deep as to how a node was to be authorized in 8021X as opposed to WPA2, so I just noted the exceptions like:

if (ni->ni_authmode != IEEE80211_AUTH_8021X)
ieee80211_node_authorize(ni);

In ieee80211_input.c: 1314
and ieee80211_proto.c:1535

And changed them to:
/* if (ni->ni_authmode != IEEE80211_AUTH_8021X) */
ieee80211_node_authorize(ni);

And now LEAP works (but still only if mode 11b is issued). This is now definitely two separate issues. This workaround is probably not the correct way with respect to security, so someone who knows the madwifi driver must comment as to what is probably going wrong.

Revision history for this message

jbj (jbj-ubu) wrote on 2007-09-22:

On the 11g front, the latest svn snapshot of madwifi trunk worked fine 11g on my WPA2 home box, but didn't work at all for LEAP (i.e. regressed). I'm going to try ndiswrapper as my solution, that works at home, will see about LEAP networks on monday.

Revision history for this message

Gareth Fitzworthington (mapping-gp-deactivatedaccount) wrote on 2008-04-05:

This is a Network Manager bug.
Fix released for Hardy.

Marking as duplicate.
Any backport requests should be first examined against:
https://help.ubuntu.com/community/UbuntuBackports
Then filed against the main bug stream. Unless this duplicate message is viewed as errant. In which case please un-duplicate.