Bugzilla – Bug 464870
Networkmanager unable to connect to WPA-Enterprise
Last modified: 2009-01-15 15:52:29 UTC
I'm unable to connect to WPA-Enterprise (with TTLS and PAP) with NM. When changing network interface to ifup it works. I had exactly the same configuration in openSuse 11.0 and there it worked with NM. My Configuration: opensuse 11.1, 64 bit, Wifi: Bus 001 Device 003: ID 148f:2573 Ralink Technology, Corp. RT2501USB Wireless Adapter, driver: rt73usb Here's my NM-log: Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) starting connection 'TU-Berlin_802.1x' Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 3 -> 4 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 4 -> 5 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0/wireless): access point 'TU-Berlin_802.1x' has security, but secrets are required. Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 5 -> 6 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 6 -> 3 Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): deactivating device (reason: 0). Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) starting connection 'TU-Berlin_802.1x' Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 3 -> 4 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 4 -> 5 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0/wireless): access point 'TU-Berlin_802.1x' has security, but secrets are required. Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 5 -> 6 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Jan 9 15:51:15 linux-8mno NetworkManager: <WARN> get_secrets_cb(): Couldn't get connection secrets: Requested setting is empty. Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 6 -> 9 Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) failed for access point (TU-Berlin_802.1x) Jan 9 15:51:15 linux-8mno NetworkManager: <info> Marking connection 'TU-Berlin_802.1x' invalid. Jan 9 15:51:15 linux-8mno NetworkManager: <info> Activation (wlan0) failed. Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): device state change: 9 -> 3 Jan 9 15:51:15 linux-8mno NetworkManager: <info> (wlan0): deactivating device (reason: 0). Here's the part out of message-log: Jan 9 15:51:14 linux-8mno kernel: wlan0: authenticate with AP 00:23:04:c8:8e:f0 Jan 9 15:51:14 linux-8mno kernel: wlan0: authenticate with AP 00:23:04:c8:8e:f0 Jan 9 15:51:14 linux-8mno kernel: wlan0: authenticated Jan 9 15:51:14 linux-8mno kernel: wlan0: associate with AP 00:23:04:c8:8e:f0 Jan 9 15:51:14 linux-8mno kernel: wlan0: RX ReassocResp from 00:23:04:c8:8e:f0 (capab=0x11 status=0 aid=57) Jan 9 15:51:14 linux-8mno kernel: wlan0: associated Jan 9 15:51:14 linux-8mno kernel: wlan0: disassociating by local choice (reason=3) And the part of wpa_supplicant.log (as there's no time indicated I'm not sure if I copied the right part of it): CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:23:04:89:06:32 (SSID='TU-Berlin_802.1x' freq=2437 MHz) CTRL-EVENT-SCAN-RESULTS Authentication with 00:23:04:89:06:32 timed out.
I have the same problem on 11.1. All worked fine under 11.0. My hardware is lenovo x61s and iwl3945 (03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02))
No reaction? This bug is a serious problem for me. Can someone take a look please?
As a workaround, I switched off Networkmanager and used the "Traditional Method" with ifup in Yast. This worked for me, but for sure, it would be better to have it implemented in NM again... Good luck! BTW, I read somewhere on the internet, that a reinstall of the kernel-source solved the problem (the official Suse kernel from the official repository with yast). As I have to rely on my computer this time, I don't want to try this, but perhaps you can try it and post the result!
I can confirm this bug: After update from 11.0 to 11.1 WPA-Enterprise (PEAP, TTLS) doesn't work anymore (WPA-personal works fine). I can give some additional information: kernel 2.6.27-default (x86_64) NetworkManager 0.7.0.r4323-1.11 No matter whether KDE 4.1.3 or 4.2rc When trying to connect it just times out (reason=3) after 20 seconds, before getting an IP address. The problem seems to be that knetworkmanager doesn't write the encryption input I give to the config file, when I open the "configure connection"-dialogue again, the settings for phase-2-encryption (Mschapv2, PAP) and the path to the CA-certificate are gone. A manual connection via wpa_supplicant isn't possible either (ifup works).
Seems that the problem exists already some time, see https://bugzilla.novell.com/show_bug.cgi?id=396347 *** This bug has been marked as a duplicate of bug 396347 ***