Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1030 (new defect)

Opened 15 years ago

Last modified 14 years ago

Cannot connect to non-encrypted AP with wpa_supplicant (and Network Manager)

Reported by: carlos.lst@eldiabloenlosdetalles.net Assigned to:
Priority: major Milestone:
Component: madwifi: other Version:
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Hi,

I'm running Debian/Sid (kernel 2.6.17). I have a Thinkpad t42p with a AR5212 card. Although I mostly connect to non-encrypted APs, I do need WEP/WPA occasionaly. I use network-manager as a frontend.

The Debian-provided madwifi source stop working for me for connecting to open APs with r1500. That means NM cannot get a IP address because wpa_supplicant fails to associate with the AP. If I turn both of them off, I can use dhclient to get an IP with no issues. So the problem seems to be between wpa_supplicant and madwifi. This is a typical output for a failed run:

with wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1

network={
       ssid="Atlantic"
       key_mgmt=NONE
       auth_alg=OPEN
 }

I get:

 wpa_supplicant -ddd -iath0 -cwpa_supplicant.conf  -Dwext
Initializing interface 'ath0' conf 'wpa_supplicant.conf' driver 'wext'
ctrl_interface 'N/A' bridge 'N/A'
Configuration file 'wpa_supplicant.conf' ->
'/home/cmoffat/wpa_supplicant.conf'
Reading configuration file '/home/cmoffat/wpa_supplicant.conf'
ctrl_interface='/var/run/wpa_supplicant'
eapol_version=1
ap_scan=1
fast_reauth=1
Line: 6 - start of a new network block
ssid - hexdump_ascii(len=8):
     41 74 6c 61 6e 74 69 63                           Atlantic
key_mgmt: 0x4
auth_alg: 0x1
Priority group 0
   id=0 ssid='Atlantic'
Initializing interface (2) 'ath0'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
SIOCGIWRANGE: WE(compiled)=20 WE(source)=13 enc_capa=0xf
  capabilities: key_mgmt 0xf enc 0xf
WEXT: Operstate: linkmode=1, operstate=5
Own MAC address: 00:05:4e:50:7d:bd
wpa_driver_wext_set_wpa
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_countermeasures
wpa_driver_wext_set_drop_unencrypted
Setting scan request: 0 sec 100000 usec
Added interface ath0
RTM_NEWLINK: operstate=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
Wireless event: cmd=0x8b06 len=8
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added
State: DISCONNECTED -> SCANNING
Starting AP scan (broadcast SSID)
Trying to get current scan results first without requesting a new scan
to speed up initial association
Received 1779 bytes of scan results (8 BSSes)
Scan results: 8
Selecting BSS from priority group 0
0: 00:02:2d:04:80:9b ssid='04809b' wpa_ie_len=0 rsn_ie_len=0 caps=0x11
   skip - no WPA/RSN IE
1: 00:13:80:31:f2:81 ssid='' wpa_ie_len=0 rsn_ie_len=0 caps=0x11
   skip - no WPA/RSN IE
2: 00:13:80:94:0f:81 ssid='' wpa_ie_len=0 rsn_ie_len=0 caps=0x11
   skip - no WPA/RSN IE
3: 00:0f:90:53:0e:21 ssid='' wpa_ie_len=0 rsn_ie_len=0 caps=0x11
   skip - no WPA/RSN IE
4: 00:30:65:24:5f:ad ssid='CICORair' wpa_ie_len=0 rsn_ie_len=0 caps=0x11
   skip - no WPA/RSN IE
5: 00:13:80:31:f2:80 ssid='Atlantic' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
   skip - no WPA/RSN IE
6: 00:13:80:94:0f:80 ssid='Atlantic' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
   skip - no WPA/RSN IE
7: 00:0f:90:53:0e:20 ssid='Atlantic' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
   skip - no WPA/RSN IE
   selected non-WPA AP 00:13:80:31:f2:80 ssid='Atlantic'
Trying to associate with 00:13:80:31:f2:80 (SSID='Atlantic' freq=2437
MHz)
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
Overriding auth_alg selection: 0x1
WPA: clearing AP WPA IE
WPA: clearing AP RSN IE
WPA: clearing own WPA/RSN IE
No keys have been configured - skip key clearing
wpa_driver_wext_set_drop_unencrypted
State: SCANNING -> ASSOCIATING
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
wpa_driver_wext_associate
ioctl[SIOCSIWAUTH]: Invalid argument
WEXT auth param 1 value 0x1 - Association request to the driver failed
Setting authentication timeout: 5 sec 0 usec
EAPOL: External notification - portControl=ForceAuthorized
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b06 len=8
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b04 len=12
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b1a len=17
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b06 len=8
Authentication with 00:00:00:00:00:00 timed out.
Added BSSID 00:13:80:31:f2:80 into blacklist
State: ASSOCIATING -> DISCONNECTED
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
No keys have been configured - skip key clearing
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
Setting scan request: 0 sec 0 usec
State: DISCONNECTED -> SCANNING
Starting AP scan (broadcast SSID)
Scan timeout - try to get results
Received 1779 bytes of scan results (8 BSSes)
Scan results: 8
Selecting BSS from priority group 0

Pavel Roskin posted the following email in the madwifi-users list, related to this issue:

Hello!

I posted this to the hostap list, but I guess it really needs to be
cross-posted.

wpa_supplicant is supposed to work even without WPA and WEP.  I can make
it work with HostAP driver on the client side, even using the wext
driver in wpa_supplicant.

With the current (svn) madwifi, things are different.  Sometimes it
works, sometimes it doesn't.

That's what I'm seeing if the connection would work:

# wpa_supplicant -D wext -i ath0 -c hostap.conf 
Trying to associate with 00:0b:6b:56:01:bb (SSID='WDS1' freq=2437 MHz)
ioctl[SIOCSIWAUTH]: Invalid argument
WEXT auth param 1 value 0x1 - Association request to the driver failed
Associated with 00:0b:6b:56:01:bb
CTRL-EVENT-CONNECTED - Connection to 00:0b:6b:56:01:bb completed (auth)
[id=0 id_str=]

And that's what I'm seeing when no traffic can pass:

# wpa_supplicant -D wext -i ath0 -c hostap.conf 
Associated with 00:00:00:00:00:00
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Associated with 00:0b:6b:56:01:bb
CTRL-EVENT-CONNECTED - Connection to 00:0b:6b:56:01:bb completed (auth)
[id=0 id_str=]

Somehow, the error in ioctl indicates that the connection would work.
There is one trick to cause this.  Just sett ESSID to a bogus value.
Then you'll get the ioctl error, and the traffic would go through.

I'm using wpa_supplicant 0.5.6.  Linux kernel is current wireless-2.6
branch.

On Thu, 2006-11-30 at 20:10 -0500, Carlos Moffat wrote:

> Taking auth_alg=OPEN and keeping ap_scan=1 didn't help... the first
> time. If, while is going to the cycle of trying to connect, I cancel and
> try again right away, it associates with:

Adding and removing auth_alg=OPEN helps sometimes.  Changing ESSID helps
always.  I guess it forces the rescan, which fixes or initializes
something else.

"Associated with 00:00:00:00:00:00" may be the culprit.  Somebody
somewhere thinks that a station can be associated to 00:00:00:00:00:00.
I never see it with hostap driver:

# wpa_supplicant -D wext -i wlan0 -c hostap.conf 
Trying to associate with 00:0b:6b:56:01:bb (SSID='WDS1' freq=2437 MHz)
Associated with 00:0b:6b:56:01:bb
CTRL-EVENT-CONNECTED - Connection to 00:0b:6b:56:01:bb completed (auth) [id=0 id_str=]

Her's the dump around that place:

Added interface ath0
RTM_NEWLINK: operstate=0 ifi_flags=0x1002 ()
Wireless event: cmd=0x8b06 len=12
Ignore event for foreign ifindex 5
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b15 len=24
Wireless event: new AP: 00:0b:6b:56:01:bb
State: DISCONNECTED -> ASSOCIATED
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
Associated with 00:00:00:00:00:00
WPA: Association event - clear replay counter
EAPOL: External notification - portEnabled=0

It looks like wpa_supplicant_event_assoc() cannot get the right bssid.
And in case of hostap driver, there are no events for association to
00:00:00:00:00:00.

I guess Madwifi shouldn't be sending such events either.

On the other hand, disabling ieee80211_notify_node_leave() doesn't help,
so the problem is a bit deeper.

I went through all the recent snapshots available, and found that Network Manager is able to use successfully 0.9.0 and 0.9.1. 0.9.2 fails. Looking more closely into the revisions available in snapshots.madwifi.org, I found that r1663 works and r1668 fails.

I'll be happy to provide any other debugging information you might need. Please remember I'm not a programmer!

Thanks, Carlos

Attachments

wpa_supplicant-fix.diff (0.5 kB) - added by john@movingsucks.org on 02/28/07 09:19:40.
diff against r1842 that fixes the problem for me

Change History

12/02/06 22:54:00 changed by carlos.lst@eldiabloenlosdetalles.net

I found the guilty revision is r1664.

12/15/06 13:45:56 changed by bugs@no-more-secrets.ch

Hi all!

I have the same problem. Madwifi-svn, Network-manager, thinkpad, Debian etch.

If i want to connect to a unencrypted network, network-manager doesn't connect. I can temporarily fix this behaviour either be reverting the patch (uncommenting the preemt_scan() function and it's call) or i simply tell the card to use the wireless-g mode: iwpriv $wlan mode 3.

No problem now for network-manager to find the network and to connect.

I discovered this because it looks like (with iwconfig) the driver is scanning the wireless-a area much more often than the b/g area.

thx Thomas Kallenberg

(follow-up: ↓ 12 ) 02/14/07 15:50:31 changed by anonymous

I have the same problem. Networkmanager used to work and then started failing after a madwifi update. Debian etch, madwifi-source 1:0.9.2+r1842.20061207-2, networkmanager 0.6.4-6, wpasupplicant 0.5.5-4, IBM thinkpad T42p, Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01). An interesting twist is that my T42p developed a system board problem so my hard drive was put in a T42 with an AR5211 ethernet controller and network manager worked fine. When I got the T42p back, network manager still didn't work. I tested the controller on the T42p from dual boot windows XP to make sure it was working and it worked fine from windows. As in the above posts, iwpriv ath0 mode 3 makes network manager work. Is there a good way to automatically do the iwpriv command in networkmanager or somewhere so I don't have to do it manually until madwifi is fixed? Is madwifi going to be fixed?

Thanks, Brent

02/14/07 17:28:51 changed by dcbw

This is partly due to ambiguities in WEXT. But for now, the driver should be setting the correct mode (a/bg) when told to associate with a particular SSID. The driver obviously has scan results, or if not must scan to determine the BSSID to associate with, so it obviously knows the channel/band. The driver should, for now with WEXT, just pick a BSSID to associate with. If there is the same SSID in both bands, it should pick one at random.

d80211 and cfg80211 will fix this ambiguity of WEXT. But for now the driver needs to work around it, as the userspace tools are _not_ going to cater to the private ioctls of every driver.

02/14/07 17:32:29 changed by anonymous

Clarification; if there are BSSIDs with the ssid 'foo' on both A and B/G bands, and there is an association request for SSID 'foo', obviously the driver needs to pick the BSSID that best matches the settings from userspace, like privacy, requested WPA IE, etc. So it shouldn't just pick a BSSID at random; but it should basically ignore the band completely, satisfy the constraints, and pick one of the remaining BSSIDs, irregardless of band.

02/18/07 14:56:40 changed by lawrence@transmelodic.com

You guys are a bit too technical for me. My daughter's T42 worked fine with the wifi WEP. After I switched the network over to WPA, all other computers work fine, but not the T42. When adjusting the authentification in WIndows, there is no WPA selection (only WEP). What do I do????????

Help! Regards, Mark

02/28/07 09:17:52 changed by john@movingsucks.org

I've been having this problem for a long time (and have been getting around it by using ndiswrapper). I finally came across this, so I figured I'd look into it more.

In r1664, the there is a call to the new function "preempt_scan" (also defined in that revision), with max_grace and max_wait parameters of 100 (in ms). This seems ridiculously small--I've seen my card take a second, sometimes more, to scan. Increasing the arguments to 1000 fixes the problem for me.

I'm about to attach a diff against r1842, since that's what I've tested it against, but it applies against HEAD as well.

02/28/07 09:19:40 changed by john@movingsucks.org

  • attachment wpa_supplicant-fix.diff added.

diff against r1842 that fixes the problem for me

02/28/07 18:43:40 changed by warlord@mit.edu

Unfortunately this attachment didn't help me. I've got an unencrypted, "hidden SSID" network and NM/WPA-Supplicant still cannot connect to it, even with this patch. Even the "iwpriv ath0 mode 3" doesn't work for me, either. On the other hand like everyone else just using ifup + setting the ESSID (without NM/WPA_Supp) does work for me. I haven't tried backing out r1664 to see if that makes a difference. Perhaps I'll try that next.

03/01/07 03:38:22 changed by warlord@mit.edu

Even more unfortunately, even backing out r1664 did not help me with an unencrypted, non-broadcast SSID network with my T42p 5512 a/b/g card (where the AP is on g). Even with r1664 backed out, the 'iwpriv ath0 mode 3' workaround didn't help me, either. So alas, this is still a major issue in 0.9.2.1.

03/09/07 02:48:57 changed by andrew.bates@gmail.com

I had great luck by changing those values to 1000. I have a Lenovo T60p with the AR5212.. I could do a trick of rmmod, modprobe, then wpa_supplicant all executed serially right after each other and get one association. Now I have no problems.

Thanks for the hack/fix/whatever... i can actually use this beast now.

04/26/07 19:53:59 changed by anonymous

Changing the values to 1000 didn't work for me on my T42p.

Brent

(in reply to: ↑ 3 ) 08/02/07 23:07:57 changed by rubin@xs4all.nl

I have had this problem on various distributions, on and off in the last year or two. I've seen it on Fedora, Arch Linux and Debian 4 (Which I'm playing around with as we speak).

I can confirm that setting the card to "G" mode using:

iwpriv ath0 mode 3

Works. association is immediate. Just FYI, I had the exact symptoms described above.