I needed to fix two issues with the new wpa_supplicant helper to succesfully associate with my WPA base station. 1) On my machine wpa_cli is installed in /usr/bin instead of /usr/sbin as assumed in the script's wpa_cli() function. 2) The association check in the wpa_supplicant_associated() function does not work for my configuration. The values I get for status are: key_mgmt WPA-PSK wpa_state ASSOCIATED and this is not detected as successful by the script. Right now I simplified the function to: [[ ${status[1]} == ASSOCIATED ]] but I doubt this will cover all situations. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r8 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r10 i686) ================================================================= System uname: 2.6.9-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1500MHz Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Oct 18 2004, 08:51:27)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.9.3, 1.6.3, 1.5, 1.4_p6, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r1 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-m -mno-sse2 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium-m -mno-sse2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.gentoo.skynet.be/pub/gentoo ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.be.gentoo.org/gentoo-portage" USE="X acpi alsa arts avi berkdb bindist bitmap-fonts cdr crypt cups dga dio directfb divx4linux dvd encode f77 fam fbcon flac foomaticdb fortran gdbm gif gpm i8x0 imagemagick imlib java jpeg junit kde libg++ libwww mad mikmod mmx motif mpeg msn ncurses nls oggvorbis opengl pam pcmcia pdflib perl png pnp ppds python qt quicktime readline real samba sdl slang spell sse ssl svga tcltk tcpd theora tiff truetype unicode usb userlocales wifi wmf x86 xml2 xmms xv xvid zlib video_cards_i830"
Created attachment 46149 [details, diff] Patches wpa_cli location and assoication test This patch should fix the problem with wpa_supplicant-0.3.x
I'm afraid that doesn't do the trick for the association test. wpa_supplicant doesn't promote to the COMPLETED state until the interface is brought up, which only happens further down the net init process. This is the behaviour for wpa_supplicant using ndiswrapper and WPA-PSK, I don't know if the other drivers or protocols behave in the same way.
Created attachment 46198 [details, diff] fixed assocation and file location and brings iface up OK - we now bring the interface up before launching wpa_supplicant Please test this patch
Works!
Had the same problem here. Patch did solve it. Thx!
ndiswrapper driver with wpa-psk and static ip tried to solve same problem by myself for weeks until found this patch it works like a charm! thanks a lot :)
In CVS - will be in baselayout-1.11.9
*** Bug 78367 has been marked as a duplicate of this bug. ***
This patch still doesn't cover my case since the error is in the array assignement. The value of key_mgmt is "IEEE 802.1X (no WPA)" witch is not valid with this kind of array association. Code: cpdc0w flash # patch -p0 < /home/marc.bourget/wpa_supplicant.patch patching file /lib/rcscripts/net.modules.d/wpa_supplicant cpdc0w flash # less /lib/rcscripts/net.modules.d/wpa_supplicant cpdc0w flash # cpdc0w flash # /etc/init.d/net.ath0 restart * Stopping ath0 * Bringing down ath0 * Stopping dhcpcd on ath0 ... [ ok ] * Shutting down ath0 ... [ ok ] * Stopping wpa_supplicant on ath0 ... [ ok ] * Starting ath0 * Starting wpa_supplicant on ath0 ... /lib/rcscripts/net.modules.d/wpa_supplicant: array assign: line 85: syntax error near unexpected token `(' /lib/rcscripts/net.modules.d/wpa_supplicant: array assign: line 85: `IEEE 802.1X (no WPA)'
Created attachment 49371 [details, diff] Patch to work with certificate authentication.
The patch above allows me to connect when authenticating with using certificates (EAP). The wpa_cli status output for my connection: bssid=00:0d:54:9f:c9:09 ssid=EngSoc pairwise_cipher=TKIP group_cipher=TKIP key_mgmt=WPA/IEEE 802.1X/EAP wpa_state=COMPLETED Supplicant PAE state=AUTHENTICATED suppPortStatus=Authorized EAP state=SUCCESS selectedMethod=13 (EAP-TLS) EAP TLS cipher=AES256-SHA Adding "echo ${status[0]} ${status[1]}" in the wpa_supplicant script: inspiron ~ # /etc/init.d/net.ath0 start * Starting ath0 * Starting wpa_supplicant on ath0 ... UNKNOWN DISCONNECTED UNKNOWN SCANNING UNKNOWN SCANNING WPA/IEEE 802.1X/EAP WPA/IEEE 802.1X/EAP WPA/IEEE 802.1X/EAP WPA/IEEE 802.1X/EAP However, based on other comments in this bug, it is clear that supporting all of the possible combinations with an if/elif/else block will be quite futile. There must be some saner way of checking? Maybe by [[ ${status[0] != UNKNOWN ]] or wpa_state being COMPLETED or something?
Your wpa_cli output shows: key_mgmt=WPA/IEEE 802.1X/EAP wpa_state=COMPLETED EAP state=SUCCESS I don't see how the current fix wouldn't cover your situation: wpa_supplicant_associated() { local -a status=( "$( wpa_cli -i${1} status | awk -F= '/^key_mgmt|^wpa_state|^EAP state/ { print "\""$2"\"" }' )" ) case ${status[0]} in "NONE" ) [[ ${status[1]} == "ASSOCIATED" ]] ;; "IEEE 802.1X (no WPA)") [[ ${status[2]} == "SUCCESS" ]] ;; *) [[ ${status[1]} == "COMPLETED" ]] ;; esac return $? }
I agree - the patch in bug #78367 should resolve everything @ Pat Suwalski - do you know which happens first? EAP or WPA? I'm guessing that EAP happens first and WPA last which means the patch is still valid as it tests for wpa_state=COMPLETED If WPA happens first then I need to redo it - but it's fairly simple :)
Fixed by baselayout-1.11.9
