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 #2004 (new defect)

Opened 13 years ago

Last modified 13 years ago

wpa_supplicant -Dwext does not connect to hostapd

Reported by: anonymous Assigned to:
Priority: minor Milestone:
Component: madwifi: driver Version: trunk
Keywords: wext wpa_supplicant hostapd Cc:
Patch is attached: 0 Pending:

Description

AMD Geode computer
Atheros AR5006X 5gig card
Linux 2.6.21.5-smp kernel
Madwifi-trunk-r3727
hostapd/wpa_supplicant 0.5.10

Using r3727, wpa_supplicant -Dwext will not connect to hostapd.
Using r3727, wpa_supplicant -Dmadwifi works fine.

===== wpa_supplicant.conf ====

# /sbin/wpa_supplicant -Bw -P/mnt/rd/wpa_pid.ath0 -Dwext -bbr0 -iath0 -c<config file> 

#DAEMON: wpa_supplicant
#
# WPA Supplicant control information
#
ctrl_interface=/mnt/rd/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1
#
# Connection information
#
network={
   scan_ssid=1
   ssid="<ssid>"
   proto=RSN
   key_mgmt=WPA-PSK
   pairwise=TKIP CCMP
   group=CCMP TKIP
   psk=<wpa-psk>
   #psk_phrase="<wpa-phrase>"
}

===== hostapd configuration ====

# /sbin/hostapd -B -P /mnt/rd/wpa_pid.ath0 <config file> 

#DAEMON: hostapd
# Basic hostapd control stuff
#
# country_code=US     # Default
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
debug=2
dump_file=/mnt/rd/hostapd.dump
ctrl_interface=/mnt/rd/hostapd
ctrl_interface_group=<control group>
ap_max_inactivity=30
eapol_key_index_workaround=0
#
# Interface information
#
eapol_version=1
auth_algs=3
# keyck=WPAX
wpa=3    # 1=WPA 2=IEEE802.11i/RSN (WPA2) 3=both
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
wpa_psk=<wpa-psk>
#wpa_phrase=<wpa-phrase>
ssid=Emerald-N
interface=ath0
driver=madwifi
bridge=br0

Attachments

wpa_debug_wext.ath0 (28.4 kB) - added by Ken Roberts <ken@glaserelectronics.com> on 06/19/08 02:07:03.
wpa_supplicant -Dwext -dd dump
wpa_debug_wext.2.ath0 (21.4 kB) - added by Ken Roberts <ken@glaserelectronics.com> on 06/19/08 02:37:25.
wpa_supplicant -Dwext -dd dump (updated)
80211debug_madwifi.ath0 (92.8 kB) - added by Ken Roberts <ken@glaserelectronics.com> on 06/19/08 19:22:12.
80211debug output of -Dmadwifi (good connection)
80211debug_wext.ath0 (45.5 kB) - added by Ken Roberts <ken@glaserelectronics.com> on 06/19/08 19:22:55.
80211debug output of -Dwext (client says connected, ap says not connected)
80211debug-wext-wpa2.ath0 (16.3 kB) - added by Ken Roberts <ken@glaserelectronics.com> on 06/20/08 20:47:43.
80211debug output of -Dwext (redux) (client says connected, ap says not connected)

Change History

06/19/08 02:07:03 changed by Ken Roberts <ken@glaserelectronics.com>

  • attachment wpa_debug_wext.ath0 added.

wpa_supplicant -Dwext -dd dump

06/19/08 02:14:04 changed by Ken Roberts <ken@glaserelectronics.com>

sorry - missed the reported-by box. If you want, change the reported-by to me.

06/19/08 02:37:25 changed by Ken Roberts <ken@glaserelectronics.com>

  • attachment wpa_debug_wext.2.ath0 added.

wpa_supplicant -Dwext -dd dump (updated)

06/19/08 02:38:33 changed by Ken Roberts <ken@glaserelectronics.com>

use wpa_debug_wext.2.ath0. First one missed the bridge option to wpa_supplicant.

06/19/08 19:22:12 changed by Ken Roberts <ken@glaserelectronics.com>

  • attachment 80211debug_madwifi.ath0 added.

80211debug output of -Dmadwifi (good connection)

06/19/08 19:22:55 changed by Ken Roberts <ken@glaserelectronics.com>

  • attachment 80211debug_wext.ath0 added.

80211debug output of -Dwext (client says connected, ap says not connected)

06/20/08 03:09:31 changed by mentor

Hmm, the debug output with -Dwext does not seem to include a portion where an association attempt takes place. This may be an issue of itself, but it does not agree with the data from the wpa_supplicant log.

06/20/08 20:47:43 changed by Ken Roberts <ken@glaserelectronics.com>

  • attachment 80211debug-wext-wpa2.ath0 added.

80211debug output of -Dwext (redux) (client says connected, ap says not connected)

06/26/08 21:58:36 changed by predefining@gmail.com

I've experienced that my three Microsoft Windows XP machines didn't have any problems connecting. The connection wasn't that stable but it worked. Though it crashed very often. My Linux machines aren't able at all to connect to my access point (using ndiswrapper, b43 module). I've tested this on three machines. What's the difference between the Microsoft Windows XP supplicant and the wpa_supplicant for Linux?

06/27/08 23:10:15 changed by tobi@oetiker.ch

I am seeing the same here on my Ubuntu hardy with 2.6.25.3 + r3746, connecting to a netgear prosafe WG102 AP works only with -Dmadwifi ... it seem that the problem depends on the AP, since connecting to a Zyxel AP in another location workes fine ...

(follow-up: ↓ 7 ) 06/28/08 12:29:36 changed by distupgrade@gmail.com

All my problems got fixed after changing the channel and adding this to the postup-function of /etc/conf.d/net: pastebin.ca/1057409 The interesting part is that there weren't any other access points on the previous channel. I've experienced that the higher the channel is, the faster is the connection. My best result was 2 MB/s. On my Microsoft Windoes XP and Linux machines the connection doesn't drop at all and the ping times (I was pinging the router - 192.168.0.1 - while testing all the different setups) are very good (< 1 ms). The ping latences are getting *much* higher (500 ms - 1s) when I'm transferring data but I could solve this by enabling traffic shaping to 0.5 ms - 1 ms. By the way, I'm compiled HostAP and MadWifi from source using the latest revisions. Here is my hostapd.conf: pastebin.ca/1057407

(in reply to: ↑ 6 ; follow-up: ↓ 9 ) 06/30/08 07:54:57 changed by mrenzmann

Replying to distupgrade@gmail.com:

All my problems got fixed after changing the channel and adding this to the postup-function of /etc/conf.d/net:

So, is the following summary correct: the reported issue was not caused by MadWifi, it's been solved and this ticket can be closed now?

06/30/08 21:03:17 changed by distupgrade@gmail.com

My access point is now running for three days without any problems. I hope, this has also worked for the reporter of this bug. If you ask me, you can close this ticket.

(in reply to: ↑ 7 ) 07/01/08 08:22:59 changed by Ken Roberts <ken@glaserelectronics.com>

Replying to mrenzmann:

Replying to distupgrade@gmail.com:

All my problems got fixed after changing the channel and adding this to the postup-function of /etc/conf.d/net:

So, is the following summary correct: the reported issue was not caused by MadWifi, it's been solved and this ticket can be closed now?

Well, distupgrade@gmail.com's problem may be solved, but mine is still an issue.