Bug 981679
Summary: | Wifi not working with PEAP, MSCHAPv2 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | matias.sundman |
Component: | wpa_supplicant | Assignee: | Dan Williams <dcbw> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | alekcejk, dcbw, gansalmon, itamar, jogreene, jonathan, kernel-maint, madhu.chinakonda |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | F18 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-01-20 16:10:07 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
matias.sundman
2013-07-05 13:08:39 UTC
What wireless card/driver is this? Can you attach the output of dmesg please? I have tested with the Internal Wifi controller on my Dell Laptop E6530. 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34) and an external Usb one, Bus 003 Device 005: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter I get the same type of behaviour. Hm. Not quite sure on this one. Stanislaw, Dan? This does not look like kernel bug.
Jul 5 15:05:40 localhost kernel: [ 6073.620415] wlan0: deauthenticated from 00:0f:61:5d:58:11 (Reason: 2)
Reason 2 mean "Previous authentication no longer valid". I would check if NM settings are correct (i.e. password, protocol version etc ...)
> I have been able to connect to the secure Wifi network with an other Distribution.
If settings are fine, we would like to know what version of NM and wpa_supplicant other Distributions use, or other possible differences that make things not work on Fedora.
Appears that the connection is PEAP without certificates. Jul 5 15:05:09 localhost NetworkManager[700]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Jul 5 15:05:37 localhost NetworkManager[700]: get_secret_flags: assertion `is_secret_prop (setting, secret_name, error)' failed Jul 5 15:05:37 localhost NetworkManager[700]: ifcfg-rh: warning: missing IEEE_8021X_CA_CERT for EAP method 'peap'; this is insecure! ^^^^^^^^^^^^^^^^^^^^^^^^^^ Says it's doesn't have a certificate..but. Jul 5 15:05:37 localhost NetworkManager[700]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Jul 5 15:05:37 localhost NetworkManager[700]: <info> Activation (wlan0/wireless): connection 'EWA@ECN 1' has security, and secrets exist. No new secrets needed. That's apparently ok...Plan B Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'ssid' value 'EWA@ECN' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'scan_ssid' value '1' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'key_mgmt' value 'WPA-EAP' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'proto' value 'WPA RSN' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'password' value '<omitted>' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'eap' value 'PEAP' ^^^^^^^^ PEAP comes in 2 flavors, PEAPv0 and PEAPv1, assume this is PEAPv0, which do you need? IT guys can tell you.. Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'fragment_size' value '1300' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'phase2' value 'auth=MSCHAPV2' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'identity' value 'etxaahh' ^^^^^^^^^^^^^^ IS THIS right for this site? Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'bgscan' value 'simple:30:-45:300' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: added 'proactive_key_caching' value '1' Jul 5 15:05:37 localhost NetworkManager[700]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Jul 5 15:05:37 localhost NetworkManager[700]: <info> Config: set interface ap_scan to 1 Jul 5 15:05:37 localhost NetworkManager[700]: <info> (wlan0): supplicant interface state: disconnected -> scanning Jul 5 15:05:40 localhost kernel: [ 6073.556435] wlan0: authenticate with 00:0f:61:5d:58:11 Jul 5 15:05:40 localhost kernel: [ 6073.560740] wlan0: send auth to 00:0f:61:5d:58:11 (try 1/3) Jul 5 15:05:40 localhost kernel: [ 6073.564862] wlan0: authenticated Jul 5 15:05:40 localhost kernel: [ 6073.565999] wlan0: associate with 00:0f:61:5d:58:11 (try 1/3) Jul 5 15:05:40 localhost NetworkManager[700]: <info> (wlan0): supplicant interface state: scanning -> authenticating Jul 5 15:05:40 localhost kernel: [ 6073.568676] wlan0: RX AssocResp from 00:0f:61:5d:58:11 (capab=0xc31 status=0 aid=1) Jul 5 15:05:40 localhost kernel: [ 6073.573487] wlan0: associated Jul 5 15:05:40 localhost NetworkManager[700]: <info> (wlan0): supplicant interface state: authenticating -> associating Jul 5 15:05:40 localhost NetworkManager[700]: <info> (wlan0): supplicant interface state: associating -> associated Jul 5 15:05:40 localhost kernel: [ 6073.620415] wlan0: deauthenticated from 00:0f:61:5d:58:11 (Reason: 2) Appears the AP is told by the authenticator to kick the STA off, not happy with credentials..hence: "deauth'ed from..reason 2" message.. AP kicked you off. "Leaving by local choice reason 3" means the STA left of it's own. So either the EAP identity/password is wrong or the MSCHAPv2 identify/password are, best guess. The identities aren't always the same, and must be perfect. Additionally wpa_supplicant logging (-dd) will give you more details to isolate why the connection is failing. Hope that helps. Hi there, I used `fedup` yesterday and upgraded to Fedora 19 due to other reasons but as a side bonus my Wifi including PEAP, MSCHAPv2 is now working - I am using the same settings as before. Previously I was using Ubuntu 12.04 and it worked as well. Thanks for your support, I am not going back to 18 now so this can be closed ( I assume ). Thanks // Matias This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Closed upon request, fix in F18 fedup upgrade.. |