Summary: | WPA association problems with wpa_supplicant helper in baselayout-1.11.8 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jos Delbar <jos.delbar> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | henrik, okapi, pat, xmit |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 66472 | ||
Attachments: |
Patches wpa_cli location and assoication test
fixed assocation and file location and brings iface up Patch to work with certificate authentication. |
Description
Jos Delbar
2004-12-16 09:01:21 UTC
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 |