Network Manager Plasmoid won't connect to "WPA Enterprise" AP's in Jaunty

Bug #334052 reported by Andrew M. on 2009-02-24
210
This bug affects 16 people
Affects Status Importance Assigned to Milestone
knetworkmanager
Fix Released
Medium
plasma-widget-network-manager (Ubuntu)
Medium
Unassigned
Jaunty
Medium
Andreas Wenning
plasma-widget-networkmanagement (Ubuntu)
Medium
Unassigned
Jaunty
Undecided
Unassigned

Bug Description

Binary package hint: plasma-widget-network-manager

Situation is as follows:
I have wireless networks at work and at school that the latest network manager plasmoid won't connect to. I've tried literally every combination of settings in the plasmoid, but still no connection. I am, however, able to connect to simple WPA-PSK networks with the plasmoid.

I can connect to the "enterprise" AP's every single time with the old knetworkmanager using the following settings:
-> Network 1 (School) <-
ESSID: tamulink-wpa (not hidden)
Security: WPA Enterprise
EAP Method: PEAP
EAP Identity: ****** (my username)
EAP Anonymous Identity: <blank>
EAP Password: ****** (my password)

EAP certificate/keyfile fields all blank.
Phase 2 Method: None

-> Network 2 (Work) <-
ESSID: EEE (hidden)
Security: IEEE 802.1X
Encryption: None
EAP Method: Leap
EAP Identity: ****** (my username)
EAP Anonymous Identity: <blank>
EAP Password: ****** (my password)
EAP certificate/keyfile fields all blank.

I'm testing the latest Jaunty with all current packages (updated daily at least).
plasma-widget-network-manager:
  Installed: 0.0+svn930811-0ubuntu1
  Candidate: 0.0+svn930811-0ubuntu1
  Version table:
 *** 0.0+svn930811-0ubuntu1 0
        500 http://us.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

knetworkmanager:
  Installed: 1:0.7svn864988-0ubuntu8
  Candidate: 1:0.7svn864988-0ubuntu8
  Version table:
 *** 1:0.7svn864988-0ubuntu8 0
        500 http://us.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Andrew M. (ender-neo) wrote :

This is a partial dup of 330811, but that defect only refers to the hidden SSID aspect. One of the networks that i'm having trouble with broadcasts ESSID.

Andrew M. (ender-neo) wrote :

I should also mention that 325252 might also be relevant, given that the non-hidden network (essid=tamulink-wpa) uses both AES and TKIP (as the user sees fit.)

jcurrier421 (jcurrier421) wrote :

I too am experiencing this same problem. I connect to WPA-PSK, WEP and Open/Public networks just fine. When I select my Companies network from the Plasma List or even manually try to configure it it says "Connecting to <network_name>" but then does nothing at all...I use WPA-Enterprise PEAP/MSCHAPv2 through steel-belted RADIUS. Had no problems whatsoever with it in Intrepid. I have updated just about everything I can and still no resolution. I have checked all my logs, but since it never actually makes an effort to connect, it does not show in any of them. Is this an issue across the board with Jaunty or are others able to connect via WPA-Enterprise?

Christophe Dumez (hydr0g3n) wrote :

I confirm the problem here. I'm no able to connect to my AP at work (using WPA enterprise PEAP/MSChap v2) with KDE network manager plasmoid. My AP is broadcasting its ESSID.

However, connection works fine with WPA/WPA2 personal APs.

Connection works fine on gnome with gnome network manager applet.

Christophe Dumez (hydr0g3n) wrote :

> cat /var/log/daemon.log

NetworkManager: <WARN> wait_for_connection_expired(): connection (2) /org/freedesktop/NetworkManagerSettings/1 failed to activate (timedout): (0) Connection was not provided by any settings service.

looks like it is not even trying to connect to the AP because I have nothing in wpa_supplicant log.

Christophe Dumez (hydr0g3n) wrote :
Changed in plasma-widget-network-manager:
importance: Undecided → Medium
status: New → Confirmed
Changed in knetworkmanager:
status: Unknown → New
jcurrier421 (jcurrier421) wrote :

After the latest updates from 3/11/09 with NM and The latest Kernel I still cannot connect to WPA Enterprise using PEAP/MSCHAPv2 over 802.1x. Here are the lines from /var/log/daemon.log:
ar 12 07:12:14 ced143601lin NetworkManager: nm_setting_802_1x_get_pkcs11_engine_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
Mar 12 07:12:14 ced143601lin NetworkManager: nm_setting_802_1x_get_pkcs11_module_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
I might add this is the only log file in which I been able to come up with anything. As I previously stated it doesn't even act like it is trying to connect.
Thanks all for your work! Jaunty looks awesome!

jcurrier421 (jcurrier421) wrote :

One more addition from my daemon.log:

Mar 16 05:26:50 ced143601lin NetworkManager: <WARN> connection_get_settings_cb(): connection_get_settings_cb: Invalid connection: 'NMSetting8021x' / 'phase1-peaplabel' invalid: 1
Mar 16 05:26:56 ced143601lin NetworkManager: <WARN> wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/4 failed to activate (timeout): (0) Connection was not provided by any settings service
Thanks!

mrvanes (mrvanes) wrote :

I don't know if it helps, but I'm having connection problems with EAP network as well. Both plain wpa_supplicant and network-manager-gnome (nm_applet) work fine. This is de wpa_supplicant.conf part that makes wpa_supplicant tick:

network={
        ssid="ru-wlan" #(Visible)
        key_mgmt=WPA-EAP
        eap=TTLS
        phase2="auth=PAP"
        identity="***"
        password="***"
}

I also see the wait_for_connection_expired() in daemon.log

Luka Renko (lure) wrote :

I have tested this today on up-to-date Kubuntu/Jaunty. I used hidden network with following settings:
- WPA Enterprise,
- PEAP,
- MSCHAPv2

nm-applet 0.7.1~rc3-0ubuntu1: works!
knetworkmanager 1:0.7svn864988-0ubuntu8: works!
plasma-widget-network-manager 0.0+svn930811-0ubuntu2: does not even try to connect

I think that knetworkmanager task should be closed as Fixed, while there is for sure the problem with plasma-widget. I think when you add hidden network (Manage connections -> Add) and mark it to "Autoconnect", it does not even try to auto-connect and also does not show newly added network in the list of available SSIDs.

See attached syslog file - search for "==> TRY" to see different clients used.

Luka Renko (lure) wrote :

I think the root cause is linked to this messages from syslog:

Mar 18 15:09:47 lure NetworkManager: <WARN> list_connections_cb(): Couldn't retriev
e connections: No such method 'ListConnections' in interface 'org.freedesktop.Networ
kManagerSettings' at object path '/org/freedesktop/NetworkManagerSettings' (signatur
e '').
Mar 18 15:10:01 lure /USR/SBIN/CRON[5737]: (root) CMD ([ -x /usr/sbin/update-motd ]
&& /usr/sbin/update-motd 2>/dev/null)
Mar 18 15:11:01 lure NetworkManager: <WARN> connection_get_settings_cb(): connectio
n_get_settings_cb: Invalid connection: 'NMSetting8021x' / 'phase1-peaplabel' invalid
: 1

More info about my system:
HW: Lenovo x200s, Intel 5300 WiFi
SW: network-manager 0.7.1~rc3-0ubuntu2

Jonathan Thomas (echidnaman) wrote :

The knetworkmanager task is the upstream bug link, by the way.

I've created a patch which don't set the peaplabel setting when using peap version 0 and also don't set it when not configured (which currently is not possible using the GUI).

I've patched plasma-widget-network-manager and uploaded it to my PPA.
It works for me when using WPA-EAP with PEAP and MSCHAPv2 but I haven't tested it with any other configuration.

jcurrier421 (jcurrier421) wrote :

What is your PPA address?
Or is this attachment your patch?
Regards

Luka Renko (lure) wrote :

Does not work here, same setup, just that SSID is hidden - I think this is different problem actually.

jcurrier421 (jcurrier421) wrote :

The patch worked for me, I have successfully connected to my office network using WPA-EAP PEAP MSCHAPv2 802.1x RADIUS auth. Thanks for the work!

Andrew M. (ender-neo) wrote :

Per Hermansson, cheers.

Your patch allows me to successfully connect to the network at my school. I'll try it at work tomorrow, but I'll bet the "hidden SSID" issue with this plasmoid prevents that from working.

katoda (katoda-jabster) wrote :

I confirm this bug - can't connect to Eduroam network:
- WPA Enterprice
- TTLS
- PAP

The knetworkmanager application from KDE4 works fine.

Ax (ax-modra-ovce) wrote :

I can confirm this bug (Eduroam network, wpa enterprise/ttls/mschapv2). Can also confirm that it works with Per Hermanssons packages (Thanks Per!).

I've tried Per Hermanssons patch, but it doesn't seem to function for version 1 PEAP - in fact, it looks like it's hard-coding version 0. It seems to make a better attempt at connecting, but I get the following message in /var/log/daemon.log:

Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'ssid' value 'WC_AP'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'scan_ssid' value '1'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-EAP'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'auth_alg' value 'OPEN'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'password' value '<omitted>'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'eap' value 'PEAP'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'fragment_size' value '1300'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'phase1' value 'peapver=0'
Apr 6 14:20:32 nightfall NetworkManager: <info> Config: added 'phase2' value 'autheap=MSCHAPV2'

Charles good catch!
I've found that the widget stores the PEAP version settings as a string ("one" and "zero") but tried to load it as numbers so the loading always failed and the default value 0 was always used.

I've created a patched and updated my PPA (version 0.0+svn930811-0ubuntu3~ppa2) but testing this is not easy for me so if anybody could confirm that the patch works for peap version 1 would be great.

Changed in knetworkmanager:
status: New → Confirmed
Changed in plasma-widget-network-manager (Ubuntu):
status: Confirmed → Triaged

Thanks for the fix, /var/log/daemon.txt now reports that version 1 is being set. Unfortunately, I'm still not able to connect!

Apr 7 08:49:22 nightfall NetworkManager: <info> Activation (wlan0/wireless): association took too long.
Apr 7 08:49:22 nightfall NetworkManager: <info> (wlan0): device state change: 5 -> 6
Apr 7 08:49:22 nightfall NetworkManager: <info> Activation (wlan0/wireless): asking for new secrets
Apr 7 08:49:23 nightfall NetworkManager: <WARN> get_secrets_cb(): Couldn't get connection secrets: User refused to supply secrets.
Apr 7 08:49:23 nightfall NetworkManager: <info> (wlan0): device state change: 6 -> 9
Apr 7 08:49:23 nightfall NetworkManager: <info> Activation (wlan0) failed for access point (WC_AP)
Apr 7 08:49:23 nightfall NetworkManager: <info> Marking connection 'WC_AP' invalid.
Apr 7 08:49:23 nightfall NetworkManager: <info> Activation (wlan0) failed.

I suspect that it's possible that our own system here is misconfigured (it takes a LONG time to connect), but the fact remains that I *can* connect with nm-applet.

So I went through and compared the log messages from the (unsuccessful) plasmoid attempt to connect vs. the (successful) nm-applet attempt to connect to PEAP. There were two differences (before connection failure) that I saw:

PLASMOID:
Apr 7 08:48:22 nightfall NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-EAP'
Apr 7 08:48:22 nightfall NetworkManager: <info> Config: added 'auth_alg' value 'OPEN'
Apr 7 08:48:22 nightfall NetworkManager: <info> Config: added 'phase2' value 'autheap=MSCHAPV2'

NM-APPLET:
Apr 7 09:39:47 nightfall NetworkManager: <info> Config: added 'key_mgmt' value 'IEEE8021X'
Apr 7 09:39:47 nightfall NetworkManager: <info> Config: added 'phase2' value 'auth=MSCHAPV2'

There were intervening lines, but they were the same for each configuration. So, perhaps networkmanager isn't recognizing 'autheap' or 'WPA-EAP', whereas it DOES regcognize 'auth' and 'IEEE8021X'?

I'm no expert on wireless security so perhaps someone else can answer on this but from looking at the man page of wpa_supplicant.conf (http://linux.die.net/man/5/wpa_supplicant.conf) and the knetworkmanager program there seems to be a difference between using security with WPA-EAP (as you do on plasmoid) and IEEE8021X (used on NM-APPLET).

I don't think there are any support in plasmoid to configure the connection to use IEEE8021X so that may be the reason why it doesn't work for you.

Thanks. For what it's worth, I've filed a new bug report (as this seems to be a different issue than this bug) under #357170.

Divan (divan-santana) wrote :

Ok I had the same problem as everyone else.

Trying to connect to WPA-EAP with PEAP and MSCHAP v2 with CA cert etc. and it wouldn't work...

#tail -f /var/log/daemon.log
NetworkManager: <WARN> wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/1 failed to activate (timeout): (0) Connection was not provided by any
settings service

Added "deb http://ppa.launchpad.net/hermansson-per/ppa/ubuntu jaunty main" patch and upgraded and after reboot.

Connected perfectly fine!

Awesome thanks for the patch!

But if this works and fixes a bug so nicely why is it not in the official ubuntu updates repo? Or is this patch still going to be uploaded?

I have the same problem but found something else in my logfile:
Network manager connects to the wlan and tries to receive an IP from the DHCP server - this fails.
I only see DHCPDISCOVER loglines but no DHCPOFFER.

Using the same DHCP server with a network cable works out of the box. Also several other laptops
work smoothless with the same WLAN. Ubuntu 9.04 beta stopped working some time ago after on of the
updates (don't know which one exactly). After updating 8.10 to 9.04 it was still working correct,
so the problem must be introduced sometimes in the last weeks.

awidegreen (awidegreen) wrote :

I confirm this bug.
After upgrading my system on 9.04 rc1 ... my WPA-EAP with TTLS and PAP connection stopped working. Previously, no problems with knetworkmanager.

I also tested the patch mentioned before (by hermansson). It neither worked (TTLS and PAP) for me. After updating the plasma-widget-network-manager from the given ppa, I wasn't even able to established a connection to an unencrypted network.

Hi, thanks for trying my fix with TTLS. In helping the troubleshooting can you provide parts of your /var/log/daemon.log log that shows all lines starting with NetworkManager when you try to connect.

Also can you tell a little bit about your wireless connection like if your are using certificates.

awidegreen (awidegreen) wrote :

Hej, thanks for reply - sorry for my delayed answer, I wasn't able to test it yesterday.
Here the output of the daemon.log... it seems that the configuration isn't even stored correctly:

NetworkManager: <WARN> connection_get_settings_cb(): connection_get_settings_cb: Invalid connection: 'NMSetting8021x' / 'phase2-autheap' invalid: 1
NetworkManager: <WARN> wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/4 failed to activate (timeout): (0) Connection was not providedb by any settings service

Furthermore I also tested to connect with the xfce-networkmanager, to exclude driver-issues derived from madwifi. It works correctly.

Some additional information to the network:
- wpa-eap tunneled TLS (TTLS) with PAP
- no ca certificate
- anonymous identity: <email address hidden>
- identity: <email address hidden>
- <password>

bye a

I have to confirm this bug, too. I attached a certificate chain (.pem), but the message is the same as reported bei aweight.

Benoit Grégoire (benoitg) wrote :

This doesn't seem to be the same issue as match the comment, but seems to match the configuration of the original submitter:

I am not able to specify "LEAP" as an eap method, it's simply not offered. I'm attaching a screenshot of my (working) configuration in gnome's nm-applet.

Felix (apoapo) wrote :

Won't connect either here on a wpa-eap with ttls, tkip (no option at all?) and pap without any certificate.

It says: "connecting to xyz" but the tray icon does not show this shiny animation ;)

The patch from the ppa listed here does not work for my setup either.

Great news, both my patches has been commited upstream.
But no new news on the ttls issues yet.

direx (direx.1) wrote :

I also have the TTLS issue. I am using TTLS, a CA certificate and PAP (for connecting to the eduroam network). This is my log:

May 4 11:34:36 [kernel] input: b43-phy0 as /devices/virtual/input/input6
May 4 11:34:37 [kernel] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
May 4 11:34:37 [kernel] Registered led device: b43-phy0::radio
May 4 11:34:37 [NetworkManager] <info> (wlan0): device state change: 2 -> 3_
May 4 11:34:37 [NetworkManager] <info> (wlan0): supplicant interface state: starting -> ready_
May 4 11:34:53 [NetworkManager] <WARN> wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/5 failed to activate (timeout): (0) Connection was not provided by any settings service_

BTW: I have also tried the latest SVN code of the plasmoid - but it is still not working.

I've changed the properties that the application sends to Network Manager so WPA-EAP with TTLS should now work. Can anyone experience problems using TTLS try version ppa3 in my PPA and report if it works.

Also the changes also apply to WPA-EAP with PEAP so I would like if those who got PEAP to work with my previous versions also tested the new version to ensure it still works.

I'm attaching a debdiff over the changes I made.

And PEAP still isn't working with the intel 3945 controller. I don't know if this is a driver problem or a network manager problem. Does *anyone* use an intel 3945 with PEAP and the networkmanager plasmoid?

Felix (apoapo) wrote :

I testet your newest ppa version withWPA2 enterprise, TTLS and PAP and a certificate.

+the icon is showing an animation now
+tries to connect for about 1 minute

-connection times out

daemon.log enclosed

You're doing a great job. Thank you!

48 comments hidden view all 122 comments

Version: (using KDE 4.2.2)
OS: Linux
Installed from: Ubuntu Packages

When configuring WPA-Enterprise connections the plasma widget gives four auth methods that can be used with PEAP and TTLS.

During transmission over DBUS to network manager the auth method is send using the "autheap" key in which not all auth methods are available. Changing the key to "auth" makes all specified auth methods work.

The provided patch updates the widget to set the auth variable instead of the autheap one. Note this might break already configured connections.

The fix is reported to work by me and here https://bugs.launchpad.net/ubuntu/+source/plasma-widget-network-manager/+bug/334052/comments/42

Created attachment 33638
patch for using auth instead of autheap

Sorry invalid, wrong component

thanks for moving moving this, should be correct now

Changed in plasma-widget-network-manager (Ubuntu):
status: Triaged → Fix Released
Changed in plasma-widget-network-manager (Ubuntu):
assignee: nobody → H.i.M (hir-i-mogul-gmail)
status: Fix Released → Confirmed
Changed in plasma-widget-network-manager (Ubuntu):
assignee: H.i.M (hir-i-mogul-gmail) → nobody
Martin Pitt (pitti) on 2009-06-19
tags: added: verification-needed
Changed in plasma-widget-network-manager (Ubuntu Jaunty):
status: New → Fix Committed
assignee: nobody → Andreas Wenning (andreas-wenning)
Changed in plasma-widget-network-manager (Ubuntu):
assignee: nobody → Andreas Wenning (andreas-wenning)
Changed in plasma-widget-network-manager (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Martin Pitt (pitti) on 2009-06-19
Changed in plasma-widget-network-manager (Ubuntu Jaunty):
status: Fix Released → Triaged
tags: removed: verification-needed

I'm looking hard at this right now but I can't commit the patch as is as it will break connections that do use autheap as the phase2 auth style.

To make it work right i have to rework a lot of the UI.

*** Bug 186325 has been marked as a duplicate of this bug. ***

Changed in knetworkmanager:
status: Confirmed → Invalid
Changed in knetworkmanager:
status: Invalid → Unknown
Changed in plasma-widget-network-manager (Ubuntu):
assignee: Andreas Wenning (andreas-wenning) → nobody
status: Confirmed → Won't Fix
Changed in plasma-widget-networkmanagement (Ubuntu Jaunty):
status: New → Invalid
Changed in plasma-widget-network-manager (Ubuntu):
status: Won't Fix → Invalid
Changed in plasma-widget-networkmanagement (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in plasma-widget-network-manager (Ubuntu Jaunty):
importance: Undecided → Medium
Changed in knetworkmanager:
status: Unknown → In Progress

*** Bug 191040 has been marked as a duplicate of this bug. ***

Fixed, please test with knetworkmanager trunk and kdebase-workspace 4.3 branch.

Changed in knetworkmanager:
status: In Progress → Fix Released
Changed in plasma-widget-networkmanagement (Ubuntu):
status: Triaged → Fix Released

I didn't get my university network to work with the new revision, too, trying both PEAP and TTLS.
The applet tries to connect, but after some time it asks again for the security settings.

I attach the log of a failed connection attempt. Something seems wrong with the certificate, at least the name does not conform with the certificates I wrote in ("use system CA certs" is unchecked).

Created attachment 36434
log of NetworkManager - failed connection

Cyril: Are you using SVN or packages? which revision?

Aug 25 13:37:29 linux-oqzl NetworkManager: <WARN> connection_get_settings_cb(): connection_get_settings_cb: Invalid connection: 'NMSettingConnection' / 'id' invalid: 1

This indicates one of your connections is invalid. Can you delete all other connections and see if NM still prints this warning when you start KNetworkManager (tail -f /var/log/whatever-ubuntu-uses-for-nm-logs). If it persists, delete and recreate the EAP-PEAP connection too.

Aug 25 13:37:33 linux-oqzl NetworkManager: <info> Config: added 'ca_cert' value 'blob://-org-freedesktop-NetworkManagerSettings-9-ca_cert'

This is something NM uses to describe the ca-cert sent by NM as a series of bytes.

Thanks for the hints!

I use OpenSuse packages:
NetworkManager 0.7.0.r4359-15.2.2
knetworkmanager 0.9.svn1012598-93.2

I'll delete my connections and retry connecting ASAP.

Changed in knetworkmanager:
status: Fix Released → Confirmed

I deleted all my connections and after reboot tried again, but still without success.
I'll attach the log.
My university network prefers WPA2 and AES encryption, but WPA and RC4 or TKIP should work fine, too (I see no possibility to set this manually in order to test).

Created attachment 36618
log of NetworkManager - failed connection II

Changed in plasma-widget-networkmanagement (Ubuntu):
status: Fix Released → Won't Fix
status: Won't Fix → Triaged

I just upgraded to the plasmoid-widget-network-manager version 0.1~svn1017841-0ubuntu2~jaunty3 package, and there's no joy - I'm still NOT getting PEAP authentication.

/var/log/daemon.log and qdbus output is attached.

Created attachment 36792
qdbus output under plasma-widget-networkmanager

Created attachment 36793
/var/log/daemon.log output under plasma-widget-networkmanager

Charlie: sounds like you are suffering bug 188085 too.

SVN commit 1022361 by wstephens:

When a connection's wireless security type is changed, previous wireless security
setting state was not being fully reset, leading to duplicate and
incorrect settings to be sent, that are marked invalid by
NetworkManager.

Charlie: Either delete and recreate this connection or change the
wireless security type away from WPA Enterprise and back again to reset
the state and get rid of the dupe WEP ciphers seen in your log in
comment #16.

BUG: 192597

 M +2 -1 internals/setting.h
 M +20 -0 internals/settings/802-11-wireless-security.cpp
 M +2 -0 internals/settings/802-11-wireless-security.h
 M +9 -1 ui/security/wirelesssecuritysettingwidget.cpp
 M +2 -1 ui/security/wirelesssecuritysettingwidget.h

WebSVN link: http://websvn.kde.org/?view=rev&revision=1022361

Will, I hate to tell you, but that doesn't seem to have had any effect. I tried both solutions you mentioned, as well as deleteing the .kde/share/config/networkmanagementrc file (wiping out all connection information), and it *still* does the same thing - I've reattached the latest /var/log/daemon.log, but I'm pretty sure it's the same.

Created attachment 36871
/var/log/daemon.log after fix suggested by W. Stephenson

/var/log/daemon.log after fix suggested by W. Stephenson

Created attachment 36872
/var/log/daemon.log output under nm-applet

/var/log/daemon.log output under nm-applet

It looks like knetworkmanager is still setting key_mgmt as 'WPA-EAP', NOT 'IEEE8021X'. I don't know if that's significant, but it seems that it might be so. And again, this is a fresh configuration.

BKO is down so I'm replying directly.

Just to make sure, are you already running the code I committed today?

And I don't mind you telling me it doesn't work - this is the only way to
debug these things. Thanks for giving it your time.

Will

On Friday 11 September 2009 18:24:53 Charles Figura wrote:
> https://bugs.kde.org/show_bug.cgi?id=192597
>
>
>
>
>
> --- Comment #22 from Charles Figura <charles figura wartburg edu>
> 2009-09-11 18:24:52 --- It looks like knetworkmanager is still setting
> key_mgmt as 'WPA-EAP', NOT 'IEEE8021X'. I don't know if that's
> significant, but it seems that it might be so. And again, this is a fresh
> configuration.
>

Changed in plasma-widget-networkmanagement (Ubuntu):
status: Triaged → Fix Committed
Changed in knetworkmanager:
status: Confirmed → Fix Released
visibility: public → private
visibility: private → public
Changed in plasma-widget-network-manager (Ubuntu Jaunty):
status: Triaged → Won't Fix
Changed in plasma-widget-networkmanagement (Ubuntu):
status: Fix Committed → Fix Released
28 comments hidden view all 122 comments
rabauke (sven-burmeister) wrote :

If using certificates, make sure you do not run into another issue, which is purely NetworkManagers fault. https://bugzilla.gnome.org/show_bug.cgi?id=594466

Felix (apoapo) wrote :

@Andreas Wenning
You said you were using WPA Enterprise/TTLS/PAP.

There is an anonymous Identity with a certificate. Did you leave this option blank? Or did you use System CA Certs?

@rabauke

A friend of mine is using Jaunty. The login works on that machine. I think he's using a similar version of NetworkManager concerning the issue you linked to?

@apo
No certificates used at all. CA certs field left blank; and use system CA certs not ticked.

Felix (apoapo) wrote :

I retried it today and it didn't work with certificate, without, or the System CA certs. I wonder what this msg from syslog means:

Sep 16 16:05:45 -laptop NetworkManager: <info> Config: added 'ca_cert' value 'blob://-org-freedesktop-NetworkManagerSettings-7-ca_cert'

This is not my certificate i added. It stays with this msg. Doesn't matter what i choose (my cert, system cert, none)
Full log enclosed.

26 comments hidden view all 122 comments

I'm sorry, the newest revision doesn't do it for me, too.
After some time I'm still asked again and again for the connection settings (the previous ones are now shown correctly).

Just for testing I once put in a wrong password, but the behaviour was the same, so maybe the connection doesn't even reach the stage where the password is checked.

I upgraded to the Karmic beta over the weekend, and tried the network manager plasmoid again, version 0.9~svn1029786-0ubuntu1. No joy - I'm still not able to connect.

Download full text (3.8 KiB)

With Fedora 11 (0.12.20090519svn.fc11), I still experience this problem.
Here is the log, with plasmoid:

Nov 6 11:06:16 bastard kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Nov 6 11:06:16 bastard NetworkManager: <info> (wlan0): device state change: 2 -> 3 (reason 0)
Nov 6 11:06:16 bastard NetworkManager: <info> (wlan0): supplicant interface state: starting -> ready
Nov 6 11:06:46 bastard NetworkManager: <WARN> wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/1 failed to activate (timeout): (0) Connection was not provided by any settings service

altough with nm-applet, I can connect to the network without any problem.

Here is the log, of nm-applet connecting to the same network:

Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) starting connection 'Auto GUESTS'
Nov 6 11:07:15 bastard NetworkManager: <info> (wlan0): device state change: 3 -> 4 (reason 0)
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Nov 6 11:07:15 bastard NetworkManager: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0/wireless): access point 'Auto GUESTS' has security, but secrets are required.
Nov 6 11:07:15 bastard NetworkManager: <info> (wlan0): device state change: 5 -> 6 (reason 0)
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Nov 6 11:07:15 bastard NetworkManager: <info> (wlan0): device state change: 6 -> 4 (reason 0)
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Nov 6 11:07:15 bastard NetworkManager: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Nov 6 11:07:15 bastard NetworkManager: <info> Activation (wlan0/wireless): connection 'Auto GUESTS' has security, and secrets exist. No new secrets needed.
Nov 6 11:07:15 bastard NetworkManager: <info> Config: added 'ssid' value 'GUESTS'
Nov 6 11:07:15 bastard NetworkManager: <info> Config: added 'scan_ssid' value '1'
Nov 6 11:07:15 bastard NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Nov 6 11:07:15 bastard NetworkManager: <info> Config: added 'psk' value '<omitted>'
Nov 6 11:07:15 bastard...

Read more...

The plasmoid is way out of date, you need knetworkmanager to have a chance.

Download full text (4.8 KiB)

No, it's still screwed up.

I just did a clean install of Karmic on a new Dell Latitude E6400. Karmic installs plasma-widget-networkmanagement by default. There is NO knetworkmanager package listed at all. If there's a different package I should be installing, I'll apparently need a ppa for it.

Under plasma-widget-networkmanagement, version 0.9~svn1029786+ag1-0ubuntu1, I get the following log messages in /var/log/daemon:

Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) starting connection 'WC_AP'
Nov 6 08:25:36 nightfall NetworkManager: <info> (wlan0): device state change: 3 -> 4 (reason 0)
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Nov 6 08:25:36 nightfall NetworkManager: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0/wireless): access point 'WC_AP' has security, but secrets are required.
Nov 6 08:25:36 nightfall NetworkManager: <info> (wlan0): device state change: 5 -> 6 (reason 0)
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Nov 6 08:25:36 nightfall NetworkManager: <WARN> secrets_update_setting(): Failed to update connection secrets: 1 ipv4
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Nov 6 08:25:36 nightfall NetworkManager: <info> (wlan0): device state change: 6 -> 4 (reason 0)
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Nov 6 08:25:36 nightfall NetworkManager: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Nov 6 08:25:36 nightfall NetworkManager: <info> Activation (wlan0/wireless): connection ...

Read more...

Is this bug really fixed? Looking through the history I can't see it as such. If it is, can you tell me in what level so I can verify if the fix is in KUbuntu Karmic (as I can't connect to WPA LEAP with kde)

@Anton, and anyone else -
No, it's not fixed. It still doesn't work. I don't think I've been able to use knetworkmanager on our school PEAP/LEAP network since before knetworkmanager 0.7. I've been using nm-applet quite successfully - the only problem is that it gets really annoying to have to unlock a kde wallet AND a gnome keyring. But I've never gotten the kde network-manager plasmoid to work on PEAP/LEAP. Not once, not ever.

31 comments hidden view all 122 comments
molecule-eye (niburu1) wrote :

I'm using Lucid and can't connect in Kubuntu, but Lucid Ubuntu works fine with the same settings.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2010 01:28, molecule-eye wrote:
> I'm using Lucid and can't connect in Kubuntu, but Lucid Ubuntu works
> fine with the same settings.
what type of encryption you have to connect to?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAkyD5ZkACgkQggfXXPAclJG8JgCXdMfKlX+ZAQuVqqUwSVKYskXl
bgCcD3o+lqVHlx6fTouM0U4TLUwAP18=
=zzFe
-----END PGP SIGNATURE-----

31 comments hidden view all 122 comments

I confirm that the bug is NOT fixed, I still can't connect to the eduroam network with the (newly official) NM plasmoid in SC 4.5.1. :-(
I tried all workarounds presented in this (seemingly duplicate) thread, nothin helped: https://bugs.kde.org/show_bug.cgi?id=209673

Changed in knetworkmanager:
importance: Unknown → Medium

after upgrading to kde 4.10 i can't connect to wpa-protected wifi networks (i can connect to non-encripted networks)
i this bug is back?

kubuntu 12.10, kde 4.10 from the repository kubuntu-ppa-backports-quantal

I haven't been able to connect to a WPA2 network for at least two years on multiple laptops, although it has always worked with NetworkManager and Gnome. I'm not sure whether the reason is that the PEAP auth methods aren't correctly sent (as the title of this bug report says), but all the bugs I can find about the networkmanager plasmoid not connected to WPA enterprise are marked as duplicates of this one, and the problem is defnitely *not* resolved.

Displaying first 40 and last 40 comments. View all 122 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.