Ticket #1016 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

AR5212 802.11abg - WEP not working - OPEN works

Reported by: antonio.fiol@red.es Assigned to:
Priority: major Milestone: version 0.9.3
Component: madwifi: other Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

Hardware: IBM Thinkpad R51. Card reported by lspci as: "Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)" Linux distribution: Ubuntu Edgy Eft (6.10) Madwifi driver version: both ubuntu-supplied madwifi-ng and current (trunk) SVN as of Nov. 14.

Symptoms: Association to WEP access points, either with static keying or with 802.1x, does not work since I updatd from Dapper to Edgy. Dapper came with madwifi-old, and Edgy comes with madwifi-ng. I tried disabling it from linux-restricted-modules, and installing the SVN version, but with same results.

Association to open access points works without too much trouble. However, wpa_supplicant thinks it did not work, and triggers a re-scan. Weird... And also wpa_supplicant reports a timeout associating to AP 00:00:00:00:00:00, which is also strange.

Please tell me how I can provide more information (which debug options to activate, ...) and/or what I can test to track down the origin of the problem.

Attachments

madwifi-ng-0.9.2-allow-cipher-none.diff (0.6 kB) - added by jonh@jonh.net on 01/14/07 22:21:25.
patch to accept CIPHER_NONE requests, enabling wpa_supplicant to work

Change History

11/17/06 13:56:48 changed by mrenzmann

A quick, blind guess: could it (the problems with WEP) be this issue?

11/18/06 08:13:59 changed by Jeff Sadowski

It could be the wireless tools (iwconfig) try using wpa_supplicant and use the wpa_supplicant gui they work nice.

11/20/06 22:50:05 changed by paulrensing@verizon.net

I am seeing this as well. I just bought a NetGear? WG511T card. It reports itself as:

Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

I tried for a day to get it working. It sees my base station but just won't associate with it, presumably because of the WEP key.

I switched to the madwifi-old code and it worked first try without changing any configuration.

With madwifi-ng, I did try adding "iwpriv ath0 authmode 2". It did seem to change the behaviour a bit (less time scanning for a station), but it did not solve the problem.

I also tried using wpa_supplicant. It found the station, tried to get the IP address, failed, and started again.

I would be happy to try any debugging that people can suggest.

11/22/06 11:21:40 changed by anonymous

mrenzmann: I tried with one access point which uses static wep key using iwconfig and no wpa_supplicant and it seemed to work fine.

However, using wpa_supplicant and 

watch -n 1 "iwconfig ath0 ; iwpriv ath0 get_authmode"

I see the following:

  • When trying to connect to a 802.1x AP, authmode gets automatically set to 1, key appears, and association seems stable. But no traffic...
  • When disabling that net and enabling the static wep one, I see that authmode is set to 2 (by wpa_supplicant I suppose), but the key does not appear on the iwconfig output.

In the second case, wpa_cli output is: 

<2>Trying to associate with 00:15:fa:b3:d6:81 (SSID='tmpevent' freq=2417 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:15:fa:b3:d6:81 (SSID='tmpevent' freq=2417 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:16:47:0c:d6:c1 (SSID='tmpevent' freq=2412 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:16:47:0c:d6:c1 (SSID='tmpevent' freq=2412 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:50:e8:05:01:b0 (SSID='InternetRural-VS-BT' freq=2462 MHz)
<2>Association request to the driver failed
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:03:52:eb:81:f0 (SSID='InternetRural' freq=2422 MHz)
<2>Association request to the driver failed
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:03:52:eb:81:f0 (SSID='InternetRural' freq=2422 MHz)
<2>Association request to the driver failed
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:50:e8:05:01:b0 (SSID='InternetRural-VS-BT' freq=2462 MHz)
<2>Association request to the driver failed

tmpevent is configured with static WEP key, and the rest are open. None works, even the open ones. Well, at least, wpa_supplicant does not think it worked.

11/22/06 11:23:52 changed by anonymous

Jeff Sadowski: it seems it's about the contrary. iwconfig + iwpriv seems to give me good results, but not wpa_supplicant.

11/27/06 09:32:46 changed by antonio.fiol@red.es

I'd suggest to change the title, "OPEN works" -> "OPEN works unless using wpa_supplicant"

12/15/06 22:12:50 changed by anonymous

I have the same problem. Been using wpa_supplicant just fine with ndiswrapper and the windows bcmwl5 driver for my Broadcom 4306 card. I use gentoo and I don't remember what versions of things I was using but I just upgraded everything for the first time in several months. Now I can get connections to open wireless networks, but if I use wpa_supplicant to connnect to an WPA-PSK AP (same one I used to connect to) I get the same errors shown above, Authentication with 00:00..... It worked, now it doesn't. This must be a new feature.

12/15/06 22:48:41 changed by anonymous

in above post I should have said works with "unencrypted" network, not "open". Anyway, obviously my problem is not a madwifi problem.

01/13/07 07:12:53 changed by jonh@jonh.net

I'm debugging this same problem on an AR5212 in a Lenovo Z61p, with no WEP configured. wpa_supplicant is puking in its call to

if (wpa_driver_wext_set_auth_param(drv,

IW_AUTH_CIPHER_PAIRWISE, value) < 0)

where value==1 (IW_AUTH_CIPHER_NONE). The ioctl in wpa_driver_wext_set_auth_param returns errno 859.

param->pairwise_suite == CIPHER_NONE

That's as far as I've gotten (I'm okay with gdb, but don't ask me to kgdb ... yet. :v)

01/13/07 07:14:58 changed by jonh@jonh.net

Sorry for the awful wikiformatting. Trying again.

I'm debugging this same problem on an AR5212 in a Lenovo Z61p, with no WEP configured. wpa_supplicant is puking in its call to

if (wpa_driver_wext_set_auth_param(drv, IW_AUTH_CIPHER_PAIRWISE, value) < 0)

where value==1 (IW_AUTH_CIPHER_NONE). The ioctl in wpa_driver_wext_set_auth_param returns errno 859.

param->pairwise_suite == CIPHER_NONE

Note that I can manually configure and associate this card with iwconfig just fine (I'm not trying to set any encryption parameters). That's as far as I've gotten (I'm okay with gdb, but don't ask me to kgdb ... yet. :v)

01/13/07 08:24:22 changed by jonh@jonh.net

Well, who says you need a kernel debugger to debug kernel modules? How can I forget my old buddy printk()?

Turns out the driver returns the failure in ieee80211_ioctl_setparam, in case IEEE80211_PARAM_CASTCIPHER, because cipher2cap(6) returns 0; that is, cipher2cap() doesn't know about IEEE80211_CIPHER_NONE.

I still don't know whose fault this is (madwifi for not handling this IEEE80211_CIPHER_NONE value, or wpa_supplicant for asking for it) but it's a little suspicious that madwifi knows about the value but then doesn't know how to send it on to the card.

01/13/07 08:29:21 changed by jonh@jonh.net

It occurs to me that the failure case is this test:

if ((rsn->rsn_ucastcipherset & cipher2cap(value)) == 0) { return -EINVAL; }

cipher2cap() selects the appropriate bit from a mask; obviously, there's no bit for CIPHER_NONE. That suggests that either (a) the test is wrong; the driver should just send down value 0 in the CIPHER_NONE case; or (b) the caller should never call with CIPHER_NONE, and should express that to the card some other way.

01/13/07 08:36:41 changed by jonh@jonh.net

Well, it looks like the last version in the stale CVS (2005 oct) wouldn't have had this behavior; it would just pass 0 through to the driver. I don't see a web interface to the new subversion source code control, and I'm just a little too lazy to learn subversion tonight. But I suspect that the problem was the ambitious introduction of the -EINVAL check. I'll try special-casing CIPHER_NONE, and setting rsn_ucastcipherset=0 in that case...

01/13/07 08:48:24 changed by jonh@jonh.net

Yup, that was it! I changed the test to:

if ((value!=IEEE80211_CIPHER_NONE) && ((rsn->rsn_ucastcipherset & cipher2cap(value)) == 0)) { return -EINVAL; }

It makes sense, too: the only purpose of cipher2cap is to *test* the capability bit (is the cipher supported?) -- after that, we go on to record the cipher by its original enum (6==IEEE80211_CIPHER_NONE). So in fact the test WAS wrong: it doesn't make sense to ask if we have the "capability" to use no cipher.

Yahoo. I just connected to my home wireless network using Gnome NetworkManager (using wpa_supplicant, using madwifi-ng, using ath_pci). Now, how do I get this patch into the official tree?

01/13/07 09:01:01 changed by jonh@jonh.net

I should probably mention that I did all this debugging against madwifi-ng-0.9.2.1, which I got with ACCEPT_KEYWORDS="~x86" emerge madwifi-ng in gentoo (with a day-old emerge --sync).

01/13/07 09:11:02 changed by jonh@jonh.net

To my great relief, I note that this bug is still present in the current subversion snapshot (20070113), so this wasn't an evening wasted in the netherworld of gdb.

01/14/07 10:33:05 changed by mrenzmann

@jonh: Could you provide a patch for the solution you have found? That would make it easier to review and eventually commit it. Don't forget to sign it off.

01/14/07 22:18:53 changed by jonh@jonh.net

Sorry, I meant to do that. A patch is attached to my gentoo bugzilla report here:

http ://bugs.gentoo.org/show_bug.cgi?id=157677

I will also attach the patch directly to this thread. (Please also read the gentoo report. It's a little more terse than this one. :v)

Signed-off-by: Jon Howell <jonh@jonh.net>

01/14/07 22:21:25 changed by jonh@jonh.net

  • attachment madwifi-ng-0.9.2-allow-cipher-none.diff added.

patch to accept CIPHER_NONE requests, enabling wpa_supplicant to work

01/15/07 05:20:11 changed by mrenzmann

  • patch_attached set to 1.
  • milestone set to version 0.9.3.

01/15/07 21:58:35 changed by jonh@jonh.net

mrenzmann: I think the MULTICAST_CIPHER case has exactly the same bug, so you might want to kill that bird with the same stone. My patch doesn't because I don't have a test case for that code path, and I'm not very familiar with this code.

01/24/07 12:27:18 changed by antonio.fiol@red.es

If I can help testing, I am willing to do so. I will download the current trunk, and apply the patch if it is not yet applied (not clear from previous messages).

Please email me directly if you'd like me to perform some specific test, as I don't monitor this page that often.

01/26/07 21:34:41 changed by bschlining@gmail.com

I've been having this same issue and was hoping to apply this fix. Has the patch been applied to the trunk?

02/06/07 15:08:25 changed by mentor

  • status changed from new to closed.
  • resolution set to fixed.

I believe this to be fixed in r2081. The structure member rsn_ucastcipherset appears to be used in terms of ciphers not capabilities, as such the logic has been updated to use ciphers, which should also fix this problem.

reopen if necessary.

02/06/07 16:28:54 changed by antonio.fiol@red.es

I do not intend to reopen the issue, but with r2082...

The following scenarios work: 

WPA-PSK against a 3Com 7760 AP with static IP
WPA-PSK against a 3Com 7760 AP with DHCP

But the following does not: 

802.1X against an Enterasys RoamAbout R2

wpa_action.log says: 

########## 15:57:56  2007-02-06 ##########
IFACE=ath0 ACTION=CONNECTED
WPA_ID=0 WPA_ID_STR=redes
WPA_CTRL_DIR=/var/run/wpa_supplicant
Mapping logical interface via id_str: redes
ifup ath0=redes
There is already a pid file /var/run/dhclient.ath0.pid with pid 134993416
Internet Systems Consortium DHCP Client V3.0.4
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:0e:9b:91:bb:12
Sending on   LPF/ath0/00:0e:9b:91:bb:12
Sending on   Socket/fallback
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 1
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
bssid=00:01:f4:ef:ee:86
ssid=red.es
id=0
id_str=redes
pairwise_cipher=NONE
group_cipher=NONE
key_mgmt=IEEE 802.1X (no WPA)
wpa_state=COMPLETED
Supplicant PAE state=AUTHENTICATED
suppPortStatus=Authorized
EAP state=SUCCESS
selectedMethod=13 (EAP-TLS)
EAP TLS cipher=DHE-RSA-AES256-SHA

So wpa_supplicant thinks it's connected, but DHCP does not get through.

A tcpdump on ath0 shows some traffic: 

16:18:32.970151 EAP code=1 id=0 length=13 
16:18:42.504187 EAP code=1 id=0 length=11 
16:18:42.504308 EAP code=1 id=0 length=13 
16:19:02.969863 EAP code=1 id=0 length=11 
16:19:02.969968 EAP code=1 id=0 length=13 
16:19:12.506757 EAP code=1 id=0 length=11 
16:19:12.506876 EAP code=1 id=0 length=13 
16:19:32.970893 EAP code=1 id=0 length=11 
16:19:32.970993 EAP code=1 id=0 length=13 
16:19:38.083487 IP 172.21.11.175.137 > 172.21.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:19:38.902683 IP 172.21.11.175.137 > 172.21.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:19:39.619483 IP 172.21.11.175.137 > 172.21.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:19:42.506692 EAP code=1 id=0 length=11 
16:19:42.506899 EAP code=1 id=0 length=13 
16:19:44.637044 IP 172.21.11.175.137 > 172.21.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:19:45.353849 IP 172.21.11.175.137 > 172.21.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:19:46.070632 IP 172.21.11.175.137 > 172.21.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:20:02.972363 EAP code=1 id=0 length=11 
16:20:02.972525 EAP code=1 id=0 length=13 
16:20:12.507244 EAP code=1 id=0 length=11 
16:20:12.507396 EAP code=1 id=0 length=13 
16:20:13.021106 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:20:19.000967 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:20:19.045206 arp who-has 172.21.11.200 tell 172.21.11.1
16:20:20.067108 arp who-has 172.21.11.200 tell 172.21.11.1
16:20:21.105887 arp who-has 172.21.11.200 tell 172.21.11.1
16:20:25.001345 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:20:32.972956 EAP code=1 id=0 length=11 
16:20:32.973113 EAP code=1 id=0 length=13 
16:20:37.002089 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:20:42.508297 EAP code=1 id=0 length=11 
16:20:42.508458 EAP code=1 id=0 length=13 
16:20:45.002590 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:20:59.003465 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:21:02.974017 EAP code=1 id=0 length=11 
16:21:02.974171 EAP code=1 id=0 length=13 
16:21:06.003904 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0e:9b:91:bb:12, length: 300
16:21:12.509793 EAP code=1 id=0 length=11 
16:21:12.509950 EAP code=1 id=0 length=13 
16:21:19.067236 EAP code=1 id=0 length=11 
16:21:19.067426 EAP code=1 id=0 length=13 
16:21:20.470911 EAP code=1 id=0 length=11 
16:21:20.471032 EAP code=1 id=0 length=13 
16:21:25.335147 EAP code=1 id=0 length=11 
16:21:25.335273 EAP code=1 id=0 length=13 
16:21:27.347051 EAP code=1 id=0 length=4 
16:21:30.641189 EAP code=1 id=0 length=11 
16:21:30.641308 EAP code=1 id=0 length=13 
16:21:30.778146 EAP code=1 id=0 length=11 
16:21:30.825779 EAP code=1 id=0 length=11 
16:21:30.834121 EAP code=1 id=0 length=11

Then some strange thing happened 

tcpdump: pcap_loop: recvfrom: Network is down

And at the same time, the following starts on the wpa_cli: 

<2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
<2>Associated with 00:01:f4:ef:ee:86
<2>CTRL-EVENT-EAP-STARTED EAP authentication started
<2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
<2>Trying to associate with 00:15:fa:b3:d6:81 (SSID='tmpevent' freq=2417 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:15:fa:b3:d6:81 (SSID='tmpevent' freq=2417 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.

tmpevent is another network. Maybe I have an old key for it. Buth why did it disconnect? And why is it 00:00:00:00:00:00?

02/06/07 19:00:16 changed by mentor

  • status changed from closed to reopened.
  • resolution deleted.

Is 802.1x not working a regression from 0.9.2? Is it specifically caused by r2081?

02/07/07 17:55:41 changed by mentor

  • status changed from reopened to closed.
  • resolution set to fixed.

02/08/07 06:41:30 changed by mrenzmann

The ticket is closed (again), basically since the last report is about a different topic than the original topic of this ticket, and since there was no answer about whether 802.1x not working is a regression from 0.9.2 or not. That should not block the release of 0.9.3.

@antonio.fiol: please open a new ticket about the 802.1x issue.

02/12/07 14:37:06 changed by antonio.fiol@red.es

802.1X not working is NOT a regression since 0.9.2. See the original post.

Association to WEP access points, either with static keying or with 802.1x, does not work since I updatd from Dapper to Edgy

@mrenzmann: I don't see how the last report is so different than the original issue, being me who reported it initially, and last. What I see, and why this report was written, is that madwifi-ng, for me, is a regression as a whole. I understand it may be better in many ways, but it, most of the time, does not work for me, on the networks I usually try to connect to.

02/20/07 08:31:52 changed by antonio.fiol@red.es

Recent tests allow me to explain the 11/22/06 11:21:40 comment wpa_cli output.

Apparently, the driver works fine in most situations, as long as it does not try a WEP association. Whenever it tries a WEP association, the association fails, and the driver reaches "sort of" an inconsistent state, where it cannot associate anymore to any of the access points it had associated a couple of minutes before.

01/11/08 19:06:12 changed by Ayusch

Im quite new to linux and have been working on AR5212 (802.11abg) (rev 01)my basic problem is that i get no internet conection i thing it is some sord of asociation problem but its an open conection no WEP i realy would like to know what i kann do about that it sipmly doesnt connect to the router, but the radio works fine. i tryed every thing confic posible no result anny answers be aprecheated

01/12/08 21:08:34 changed by anonymous

Have a look at ticket #1343, at the bottom ... :)

Install subversion (look for the details also on this site), download latest trunk MadWifi version, make and install.

Works like a charm. Also confirmed by several other people using this chip on IBM laptops ...

All the best !

Add/Change #1016 (AR5212 802.11abg - WEP not working - OPEN works)