Version: 0.9.svn1028043 (using KDE 4.3.1) OS: Linux Installed from: SuSE RPMs I tried to connect to an eduroam like WPA-Enterprise (PEAP/MSCHAPv2) network with KDE 4.3.1's knetworkmanager. I copied the CA certificate to /usr/local/LOCALHOST/nyme.pem, and tried to validate the radius server's certificate against this CA certificate. Gnome's nm-applet was able to use this file, but KDE4's knetworkmanager was not. (I also tried to use the system certificates but that doesn't work with any of the mentioned desktop environments, so it may be the fault of NetworkManager (or wpa_supplicant.) knetworkmanager's connection entry looks like this in dbus: [Argument: a{sa{sv}} { "802-11-wireless" = [Argument: a{sv} { "mode" = [Variant(QString): "infrastructure"], "security" = [Variant(QString): "802-11-wireless-security"], "seen-bssids" = [Variant(QStringList): {"00:1D:70:92:EC:40", "00:1D:70:27:6D:A2"}], "ssid" = [Variant(QByteArray): {78, 89, 77, 69, 49}] }], "802-11-wireless-security" = [Argument: a{sv} { "key-mgmt" = [Variant(QString): "wpa-eap"] }], "802-1x" = [Argument: a{sv} { "ca-cert" = [Variant(QByteArray): {45, 45, 45, 45, 45, 66, 69, 71, 73, 78, 32, 67, 69, 82, 84, 73, 70, 73, 67, 65, 84, 69, 45, 45, 45, 45, 45, 10, 77, 73, 73, 69, 107, 84, 67, 67, 65, 47, 113, 103, 65, 119, 73, 66, 65, 103, 73, 74, 65, 78, 65, 115, 84, 89, 114, 112, 122, 120, 117, 111, 77, 65, 48, 71, 67, 83, 113, 71, 83, 73, 98, 51, 68, 81, 69, 66, 66, 65, 85, 65, 77, 73, 72, 104, 77, 81, 115, 119, 67, 81, 89, 68, 10, 86, 81, 81, 71, 69, 119, 74, 73, 86, 84, 69, 97, 77, 66, 103, 71, 65, 49, 85, 69, 67, 66, 77, 82, 82, 51, 108, 118, 99, 105, 49, 78, 98, 51, 78, 118, 98, 105, 49, 84, 98, 51, 66, 121, 98, 50, 52, 120, 68, 122, 65, 78, 66, 103, 78, 86, 66, 65, 99, 84, 66, 108, 78, 118, 10, 99, 72, 74, 118, 98, 106, 69, 110, 77, 67, 85, 71, 65, 49, 85, 69, 67, 104, 77, 101, 86, 71, 104, 108, 73, 70, 86, 117, 97, 88, 90, 108, 99, 110, 78, 112, 100, 72, 107, 103, 98, 50, 89, 103, 86, 50, 86, 122, 100, 67, 66, 73, 100, 87, 53, 110, 89, 88, 74, 53, 77, 84, 65, 119, 10, 76, 103, 89, 68, 86, 81, 81, 76, 69, 121, 100, 74, 98, 109, 90, 118, 99, 109, 49, 104, 100, 71, 108, 118, 98, 105, 66, 84, 101, 88, 78, 48, 90, 87, 49, 122, 73, 70, 78, 108, 99, 110, 90, 112, 89, 50, 86, 122, 73, 69, 82, 108, 99, 71, 70, 121, 100, 71, 49, 108, 98, 110, 81, 120, 10, 76, 68, 65, 113, 66, 103, 78, 86, 66, 65, 77, 84, 73, 49, 86, 88, 83, 67, 66, 68, 90, 88, 74, 48, 97, 87, 90, 112, 89, 50, 70, 48, 90, 83, 66, 66, 99, 51, 78, 108, 99, 110, 82, 112, 98, 50, 52, 103, 77, 106, 65, 119, 78, 105, 48, 121, 77, 68, 69, 119, 77, 82, 119, 119, 10, 71, 103, 89, 74, 75, 111, 90, 73, 104, 118, 99, 78, 65, 81, 107, 66, 70, 103, 49, 104, 90, 71, 49, 112, 98, 107, 66, 117, 101, 87, 49, 108, 76, 109, 104, 49, 77, 66, 52, 88, 68, 84, 65, 50, 77, 68, 77, 120, 77, 122, 65, 53, 78, 68, 65, 48, 78, 70, 111, 88, 68, 84, 69, 119, 10, 77, 68, 99, 119, 77, 84, 65, 53, 78, 68, 65, 48, 78, 70, 111, 119, 103, 101, 69, 120, 67, 122, 65, 74, 66, 103, 78, 86, 66, 65, 89, 84, 65, 107, 104, 86, 77, 82, 111, 119, 71, 65, 89, 68, 86, 81, 81, 73, 69, 120, 70, 72, 101, 87, 57, 121, 76, 85, 49, 118, 99, 50, 57, 117, 10, 76, 86, 78, 118, 99, 72, 74, 118, 98, 106, 69, 80, 77, 65, 48, 71, 65, 49, 85, 69, 66, 120, 77, 71, 85, 50, 57, 119, 99, 109, 57, 117, 77, 83, 99, 119, 74, 81, 89, 68, 86, 81, 81, 75, 69, 120, 53, 85, 97, 71, 85, 103, 86, 87, 53, 112, 100, 109, 86, 121, 99, 50, 108, 48, 10, 101, 83, 66, 118, 90, 105, 66, 88, 90, 88, 78, 48, 73, 69, 104, 49, 98, 109, 100, 104, 99, 110, 107, 120, 77, 68, 65, 117, 66, 103, 78, 86, 66, 65, 115, 84, 74, 48, 108, 117, 90, 109, 57, 121, 98, 87, 70, 48, 97, 87, 57, 117, 73, 70, 78, 53, 99, 51, 82, 108, 98, 88, 77, 103, 10, 85, 50, 86, 121, 100, 109, 108, 106, 90, 88, 77, 103, 82, 71, 86, 119, 89, 88, 74, 48, 98, 87, 86, 117, 100, 68, 69, 115, 77, 67, 111, 71, 65, 49, 85, 69, 65, 120, 77, 106, 86, 86, 100, 73, 73, 69, 78, 108, 99, 110, 82, 112, 90, 109, 108, 106, 89, 88, 82, 108, 73, 69, 70, 122, 10, 99, 50, 86, 121, 100, 71, 108, 118, 98, 105, 65, 121, 77, 68, 65, 50, 76, 84, 73, 119, 77, 84, 65, 120, 72, 68, 65, 97, 66, 103, 107, 113, 104, 107, 105, 71, 57, 119, 48, 66, 67, 81, 69, 87, 68, 87, 70, 107, 98, 87, 108, 117, 81, 71, 53, 53, 98, 87, 85, 117, 97, 72, 85, 119, 10, 103, 90, 56, 119, 68, 81, 89, 74, 75, 111, 90, 73, 104, 118, 99, 78, 65, 81, 69, 66, 66, 81, 65, 68, 103, 89, 48, 65, 77, 73, 71, 74, 65, 111, 71, 66, 65, 79, 74, 109, 121, 98, 90, 43, 122, 105, 86, 120, 71, 79, 106, 77, 68, 97, 100, 90, 99, 120, 66, 98, 74, 89, 69, 120, 10, 89, 50, 122, 71, 108, 102, 49, 74, 105, 119, 100, 85, 75, 110, 122, 75, 81, 116, 66, 78, 48, 81, 99, 108, 104, 72, 117, 90, 116, 72, 109, 106, 107, 52, 47, 56, 114, 109, 108, 78, 119, 104, 89, 116, 113, 69, 55, 72, 117, 79, 52, 54, 98, 74, 43, 107, 82, 51, 71, 57, 77, 86, 99, 70, 10, 117, 48, 76, 117, 102, 113, 115, 70, 82, 71, 54, 77, 121, 66, 56, 55, 114, 122, 74, 66, 74, 57, 103, 101, 51, 118, 111, 98, 65, 78, 48, 77, 82, 83, 72, 66, 87, 117, 85, 109, 88, 66, 86, 52, 114, 67, 99, 117, 52, 104, 111, 50, 112, 120, 70, 85, 68, 102, 72, 90, 47, 65, 52, 54, 10, 80, 122, 112, 117, 69, 65, 47, 54, 73, 47, 55, 69, 47, 43, 113, 74, 65, 103, 77, 66, 65, 65, 71, 106, 103, 103, 70, 78, 77, 73, 73, 66, 83, 84, 65, 100, 66, 103, 78, 86, 72, 81, 52, 69, 70, 103, 81, 85, 49, 85, 75, 70, 111, 108, 83, 118, 112, 43, 119, 118, 100, 74, 68, 121, 10, 71, 48, 75, 71, 72, 114, 43, 65, 120, 85, 73, 119, 103, 103, 69, 89, 66, 103, 78, 86, 72, 83, 77, 69, 103, 103, 69, 80, 77, 73, 73, 66, 67, 52, 65, 85, 49, 85, 75, 70, 111, 108, 83, 118, 112, 43, 119, 118, 100, 74, 68, 121, 71, 48, 75, 71, 72, 114, 43, 65, 120, 85, 75, 104, 10, 103, 101, 101, 107, 103, 101, 81, 119, 103, 101, 69, 120, 67, 122, 65, 74, 66, 103, 78, 86, 66, 65, 89, 84, 65, 107, 104, 86, 77, 82, 111, 119, 71, 65, 89, 68, 86, 81, 81, 73, 69, 120, 70, 72, 101, 87, 57, 121, 76, 85, 49, 118, 99, 50, 57, 117, 76, 86, 78, 118, 99, 72, 74, 118, 10, 98, 106, 69, 80, 77, 65, 48, 71, 65, 49, 85, 69, 66, 120, 77, 71, 85, 50, 57, 119, 99, 109, 57, 117, 77, 83, 99, 119, 74, 81, 89, 68, 86, 81, 81, 75, 69, 120, 53, 85, 97, 71, 85, 103, 86, 87, 53, 112, 100, 109, 86, 121, 99, 50, 108, 48, 101, 83, 66, 118, 90, 105, 66, 88, 10, 90, 88, 78, 48, 73, 69, 104, 49, 98, 109, 100, 104, 99, 110, 107, 120, 77, 68, 65, 117, 66, 103, 78, 86, 66, 65, 115, 84, 74, 48, 108, 117, 90, 109, 57, 121, 98, 87, 70, 48, 97, 87, 57, 117, 73, 70, 78, 53, 99, 51, 82, 108, 98, 88, 77, 103, 85, 50, 86, 121, 100, 109, 108, 106, 10, 90, 88, 77, 103, 82, 71, 86, 119, 89, 88, 74, 48, 98, 87, 86, 117, 100, 68, 69, 115, 77, 67, 111, 71, 65, 49, 85, 69, 65, 120, 77, 106, 86, 86, 100, 73, 73, 69, 78, 108, 99, 110, 82, 112, 90, 109, 108, 106, 89, 88, 82, 108, 73, 69, 70, 122, 99, 50, 86, 121, 100, 71, 108, 118, 10, 98, 105, 65, 121, 77, 68, 65, 50, 76, 84, 73, 119, 77, 84, 65, 120, 72, 68, 65, 97, 66, 103, 107, 113, 104, 107, 105, 71, 57, 119, 48, 66, 67, 81, 69, 87, 68, 87, 70, 107, 98, 87, 108, 117, 81, 71, 53, 53, 98, 87, 85, 117, 97, 72, 87, 67, 67, 81, 68, 81, 76, 69, 50, 75, 10, 54, 99, 56, 98, 113, 68, 65, 77, 66, 103, 78, 86, 72, 82, 77, 69, 66, 84, 65, 68, 65, 81, 72, 47, 77, 65, 48, 71, 67, 83, 113, 71, 83, 73, 98, 51, 68, 81, 69, 66, 66, 65, 85, 65, 65, 52, 71, 66, 65, 78, 66, 49, 90, 74, 87, 98, 121, 84, 55, 87, 86, 66, 116, 52, 10, 114, 73, 54, 114, 97, 103, 51, 57, 110, 90, 48, 75, 102, 89, 73, 88, 107, 47, 120, 55, 97, 77, 79, 105, 85, 118, 99, 98, 52, 78, 79, 101, 116, 49, 66, 109, 68, 82, 74, 89, 74, 53, 118, 72, 116, 70, 74, 75, 85, 74, 79, 53, 100, 102, 50, 120, 120, 106, 103, 120, 48, 78, 53, 49, 10, 81, 85, 76, 104, 78, 82, 71, 90, 87, 86, 115, 113, 76, 49, 106, 49, 89, 106, 88, 116, 107, 97, 103, 112, 70, 122, 43, 85, 87, 118, 87, 116, 71, 90, 82, 78, 122, 101, 54, 104, 87, 76, 116, 54, 88, 76, 121, 111, 109, 83, 83, 53, 78, 75, 98, 55, 114, 108, 52, 90, 65, 118, 69, 55, 10, 50, 69, 49, 73, 51, 51, 56, 100, 105, 120, 73, 73, 107, 85, 110, 67, 121, 57, 83, 53, 86, 48, 101, 66, 100, 65, 50, 97, 10, 45, 45, 45, 45, 45, 69, 78, 68, 32, 67, 69, 82, 84, 73, 70, 73, 67, 65, 84, 69, 45, 45, 45, 45, 45, 10}], "ca-path" = [Variant(QString): "/usr/local/LOCALHOST/nyme.pem"], "eap" = [Variant(QStringList): {"peap"}], "identity" = [Variant(QString): "nice"], "phase2-auth" = [Variant(QString): "mschapv2"], "system-ca-certs" = [Variant(bool): false] }], "connection" = [Argument: a{sv} { "autoconnect" = [Variant(bool): false], "id" = [Variant(QString): "NYME1"], "timestamp" = [Variant(uint): 1254838966], "type" = [Variant(QString): "802-11-wireless"], "uuid" = [Variant(QString): "ba4cfd3e-f1d5-4f7b-b808-cfc86461ca0a"] }] }] Network manager add the cacert like this: Oct 6 17:24:15 milleniumfalcon NetworkManager: <info> Config: added 'ca_cert' value 'blob://-org-freedesktop-NetworkManagerSettings-1-ca_cert' And wpa_supplicant fails to authenticate like this: CTRL-EVENT-EAP-STARTED EAP authentication started OpenSSL: tls_connection_ca_cert - Failed to parse ca_cert_blob error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag OpenSSL: pending error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error TLS: Failed to set TLS connection parameters EAP-PEAP: Failed to initialize SSL. EAP: Failed to initialize EAP method: vendor 0 method 25 (PEAP) CTRL-EVENT-EAP-FAILURE EAP authentication failed At the same time, the Radius server logs these events: Tue Oct 6 17:24:02 2009 : Auth: Login incorrect: [nice] (from client nyme2 port 13747 cli 00-18-DE-A3-12-52) When I omit certificate valitadion, knetworkmanager will be able to connect to the mentioned network! In addition to this, I learned that Gnome's nm-applet handles the same ca cert file differently, and it can use it successfully: [Argument: a{sa{sv}} { "802-11-wireless" = [Argument: a{sv} { "mode" = [Variant(QString): "infrastructure"], "seen-bssids" = [Variant(QStringList): {"00:1d:70:92:f7:31", "00:1d:70:27:6d:a2", "00:1d:70:92:ec:40"}], "ssid" = [Variant(QByteArray): {78, 89, 77, 69, 49}], "security" = [Variant(QString): "802-11-wireless-security"] }], "ipv4" = [Argument: a{sv} { "routes" = [Variant: [Argument: aau {}]], "addresses" = [Variant: [Argument: aau {}]], "method" = [Variant(QString): "auto"], "dns" = [Variant: [Argument: au {}]] }], "802-11-wireless-security" = [Argument: a{sv} { "key-mgmt" = [Variant(QString): "wpa-eap"] }], "connection" = [Argument: a{sv} { "id" = [Variant(QString): "NYME1"], "timestamp" = [Variant(qulonglong): 1254849617], "uuid" = [Variant(QString): "9df67442-0c5d-4d8b-9a9d-88acec708fd6"], "type" = [Variant(QString): "802-11-wireless"] }], "802-1x" = [Argument: a{sv} { "phase1-peapver" = [Variant(QString): "0"], "ca-cert" = [Variant(QByteArray): {48, -126, 4, -111, 48, -126, 3, -6, -96, 3, 2, 1, 2, 2, 9, 0, -48, 44, 77, -118, -23, -49, 27, -88, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 4, 5, 0, 48, -127, -31, 49, 11, 48, 9, 6, 3, 85, 4, 6, 19, 2, 72, 85, 49, 26, 48, 24, 6, 3, 85, 4, 8, 19, 17, 71, 121, 111, 114, 45, 77, 111, 115, 111, 110, 45, 83, 111, 112, 114, 111, 110, 49, 15, 48, 13, 6, 3, 85, 4, 7, 19, 6, 83, 111, 112, 114, 111, 110, 49, 39, 48, 37, 6, 3, 85, 4, 10, 19, 30, 84, 104, 101, 32, 85, 110, 105, 118, 101, 114, 115, 105, 116, 121, 32, 111, 102, 32, 87, 101, 115, 116, 32, 72, 117, 110, 103, 97, 114, 121, 49, 48, 48, 46, 6, 3, 85, 4, 11, 19, 39, 73, 110, 102, 111, 114, 109, 97, 116, 105, 111, 110, 32, 83, 121, 115, 116, 101, 109, 115, 32, 83, 101, 114, 118, 105, 99, 101, 115, 32, 68, 101, 112, 97, 114, 116, 109, 101, 110, 116, 49, 44, 48, 42, 6, 3, 85, 4, 3, 19, 35, 85, 87, 72, 32, 67, 101, 114, 116, 105, 102, 105, 99, 97, 116, 101, 32, 65, 115, 115, 101, 114, 116, 105, 111, 110, 32, 50, 48, 48, 54, 45, 50, 48, 49, 48, 49, 28, 48, 26, 6, 9, 42, -122, 72, -122, -9, 13, 1, 9, 1, 22, 13, 97, 100, 109, 105, 110, 64, 110, 121, 109, 101, 46, 104, 117, 48, 30, 23, 13, 48, 54, 48, 51, 49, 51, 48, 57, 52, 48, 52, 52, 90, 23, 13, 49, 48, 48, 55, 48, 49, 48, 57, 52, 48, 52, 52, 90, 48, -127, -31, 49, 11, 48, 9, 6, 3, 85, 4, 6, 19, 2, 72, 85, 49, 26, 48, 24, 6, 3, 85, 4, 8, 19, 17, 71, 121, 111, 114, 45, 77, 111, 115, 111, 110, 45, 83, 111, 112, 114, 111, 110, 49, 15, 48, 13, 6, 3, 85, 4, 7, 19, 6, 83, 111, 112, 114, 111, 110, 49, 39, 48, 37, 6, 3, 85, 4, 10, 19, 30, 84, 104, 101, 32, 85, 110, 105, 118, 101, 114, 115, 105, 116, 121, 32, 111, 102, 32, 87, 101, 115, 116, 32, 72, 117, 110, 103, 97, 114, 121, 49, 48, 48, 46, 6, 3, 85, 4, 11, 19, 39, 73, 110, 102, 111, 114, 109, 97, 116, 105, 111, 110, 32, 83, 121, 115, 116, 101, 109, 115, 32, 83, 101, 114, 118, 105, 99, 101, 115, 32, 68, 101, 112, 97, 114, 116, 109, 101, 110, 116, 49, 44, 48, 42, 6, 3, 85, 4, 3, 19, 35, 85, 87, 72, 32, 67, 101, 114, 116, 105, 102, 105, 99, 97, 116, 101, 32, 65, 115, 115, 101, 114, 116, 105, 111, 110, 32, 50, 48, 48, 54, 45, 50, 48, 49, 48, 49, 28, 48, 26, 6, 9, 42, -122, 72, -122, -9, 13, 1, 9, 1, 22, 13, 97, 100, 109, 105, 110, 64, 110, 121, 109, 101, 46, 104, 117, 48, -127, -97, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 1, 5, 0, 3, -127, -115, 0, 48, -127, -119, 2, -127, -127, 0, -30, 102, -55, -74, 126, -50, 37, 113, 24, -24, -52, 13, -89, 89, 115, 16, 91, 37, -127, 49, 99, 108, -58, -107, -3, 73, -117, 7, 84, 42, 124, -54, 66, -48, 77, -47, 7, 37, -124, 123, -103, -76, 121, -93, -109, -113, -4, -82, 105, 77, -62, 22, 45, -88, 78, -57, -72, -18, 58, 108, -97, -92, 71, 113, -67, 49, 87, 5, -69, 66, -18, 126, -85, 5, 68, 110, -116, -56, 31, 59, -81, 50, 65, 39, -40, 30, -34, -6, 27, 0, -35, 12, 69, 33, -63, 90, -27, 38, 92, 21, 120, -84, 39, 46, -30, 26, 54, -89, 17, 84, 13, -15, -39, -4, 14, 58, 63, 58, 110, 16, 15, -6, 35, -2, -60, -1, -22, -119, 2, 3, 1, 0, 1, -93, -126, 1, 77, 48, -126, 1, 73, 48, 29, 6, 3, 85, 29, 14, 4, 22, 4, 20, -43, 66, -123, -94, 84, -81, -89, -20, 47, 116, -112, -14, 27, 66, -122, 30, -65, -128, -59, 66, 48, -126, 1, 24, 6, 3, 85, 29, 35, 4, -126, 1, 15, 48, -126, 1, 11, -128, 20, -43, 66, -123, -94, 84, -81, -89, -20, 47, 116, -112, -14, 27, 66, -122, 30, -65, -128, -59, 66, -95, -127, -25, -92, -127, -28, 48, -127, -31, 49, 11, 48, 9, 6, 3, 85, 4, 6, 19, 2, 72, 85, 49, 26, 48, 24, 6, 3, 85, 4, 8, 19, 17, 71, 121, 111, 114, 45, 77, 111, 115, 111, 110, 45, 83, 111, 112, 114, 111, 110, 49, 15, 48, 13, 6, 3, 85, 4, 7, 19, 6, 83, 111, 112, 114, 111, 110, 49, 39, 48, 37, 6, 3, 85, 4, 10, 19, 30, 84, 104, 101, 32, 85, 110, 105, 118, 101, 114, 115, 105, 116, 121, 32, 111, 102, 32, 87, 101, 115, 116, 32, 72, 117, 110, 103, 97, 114, 121, 49, 48, 48, 46, 6, 3, 85, 4, 11, 19, 39, 73, 110, 102, 111, 114, 109, 97, 116, 105, 111, 110, 32, 83, 121, 115, 116, 101, 109, 115, 32, 83, 101, 114, 118, 105, 99, 101, 115, 32, 68, 101, 112, 97, 114, 116, 109, 101, 110, 116, 49, 44, 48, 42, 6, 3, 85, 4, 3, 19, 35, 85, 87, 72, 32, 67, 101, 114, 116, 105, 102, 105, 99, 97, 116, 101, 32, 65, 115, 115, 101, 114, 116, 105, 111, 110, 32, 50, 48, 48, 54, 45, 50, 48, 49, 48, 49, 28, 48, 26, 6, 9, 42, -122, 72, -122, -9, 13, 1, 9, 1, 22, 13, 97, 100, 109, 105, 110, 64, 110, 121, 109, 101, 46, 104, 117, -126, 9, 0, -48, 44, 77, -118, -23, -49, 27, -88, 48, 12, 6, 3, 85, 29, 19, 4, 5, 48, 3, 1, 1, -1, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 4, 5, 0, 3, -127, -127, 0, -48, 117, 100, -107, -101, -55, 62, -42, 84, 27, 120, -84, -114, -85, 106, 13, -3, -99, -99, 10, 125, -126, 23, -109, -4, 123, 104, -61, -94, 82, -9, 27, -32, -45, -98, -73, 80, 102, 13, 18, 88, 39, -101, -57, -76, 82, 74, 80, -109, -71, 117, -3, -79, -58, 56, 49, -48, -34, 117, 65, 66, -31, 53, 17, -103, 89, 91, 42, 47, 88, -11, 98, 53, -19, -111, -88, 41, 23, 63, -108, 90, -11, -83, 25, -108, 77, -51, -18, -95, 88, -69, 122, 92, -68, -88, -103, 36, -71, 52, -90, -5, -82, 94, 25, 2, -15, 59, -40, 77, 72, -33, 127, 29, -117, 18, 8, -111, 73, -62, -53, -44, -71, 87, 71, -127, 116, 13, -102}], "eap" = [Variant(QStringList): {"peap"}], "phase2-auth" = [Variant(QString): "mschapv2"], "identity" = [Variant(QString): "nice"] }] }] Note the missing "ca-path" entry and the array of different numbers describing the same certificate file! Oct 6 19:20:08 milleniumfalcon NetworkManager: <info> Config: added 'ca_cert' value 'blob://-org-freedesktop-NetworkManagerSettings-0-ca_cert' wpa_supplicant is also successfull: CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) EAP-MSCHAPV2: Authentication succeeded EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully WPA: Key negotiation completed with 00:1d:70:27:6d:a2 [PTK=CCMP GTK=TKIP]
Connecting to eduroam works here, so it is either a problem specific to your Uni or you did not restart both knetworkmanager and Networkmanager after installing the certificates. Also make sure you run c_rehash in the certs folder before doing so. You must not supply a cert-chain to NM or knm. See https://bugzilla.gnome.org/show_bug.cgi?id=594466
OK, I took a different approach. I copied the root certificate (PEM format, self signed, created by me, the radius server's certificate is directly signed by it, so, there's no chain) to /etc/ssl/certs, I ran c_rehash then restarted both NetworkManager and knetworkmanager, and this way it worked! Indeed, when using system certificates, c_rehash hast to be run after copying the certificate to /etc/ssl/certs. That's what I've forgotten here: https://bugzilla.novell.com/show_bug.cgi?id=546716 But now I'm talking about the case when I directly specify the path to the certificate file. This still does not work in knetworkmanager, but works in nm-applet. It's still not working after restarting both NetworkManager an knetworkmanager.
Created attachment 37590 [details] My root CA cert
This is a much more serious problem than I thought before. Imagine the eduroam infrastructure (http://www.eduroam.org/) where your PEAP/TTLS packages goes through a couple of extraneous radius servers, and if you cannot specify exactly the on CA cert you trust (which should be your own self-signed cert), then any of these servers can terminate the SSL tunnel of PEAP/TTLS and neither your client nor your home radius server will notice it! If you use a cleartext authentication inside your SSL tunnel (e.g. TTLS/PAP) then you password is stolen immediately, but regardless of the authentication method, your real identity will be revealed anyway. If your home radius server's CA cert is a widely known trusted CA cert, then the case is even worse, because any other radius server between you and your home server may have a certificate signed by the same CA cert, so your supplicant won't be able to differentiate unless NetwrokManager/knetworkmanager starts to support the subject_match & altsubject_match options of wpa_supplicant in an intelligent way, like Windows.
I confirm that. I've tried to connect to same network type (WPA-Enterprise PEAP/MSCHAPv2) and kde after clicking ok shows the dialog window again. It seems that it wouldn't even try to connect. I'm using certificate in *.der file.
I have the same bug in my French university with Kubuntu 9.10. Please do something with this bug it's very annoying.
I think you have to find out a bit more information about what causes your issues, i.e. from wpa_supplicant logs NM logs and http://userbase.kde.org/NetworkManagement#It.27s_All_KDE.27s_Fault.21. It definitely worked with openSUSE 11.1 + KDE 4.3 and with 11.2 as well. I connect to eduroam with WPA2 EAP + certificate every day. I use the deutsche-telekom-root-ca-2.crt at a German Uni.
I have the same problem usem *.pem file (again university network ;) )
Created attachment 38945 [details] Log with nm_applet and dynamic wep, working Log with nm_applet and dynamic wep, working
Created attachment 38946 [details] Log with knetwork-manager, not working the key_mgmt value shows WPA-EAP but in the settings it's configured with Dynamic WEP (802.1x), the network is secured with Dynamic WEP
*** This bug has been confirmed by popular vote. ***
(In reply to comment #7) > I think you have to find out a bit more information about what causes your > issues, i.e. from wpa_supplicant logs NM logs and > http://userbase.kde.org/NetworkManagement#It.27s_All_KDE.27s_Fault.21. Please read the original bug description. It contains virtually everything you need. (AFAIK. Sorry, if not.) > It definitely worked with openSUSE 11.1 + KDE 4.3 and with 11.2 as well. It does not work for me with openSUSE 11.2. > I connect to eduroam with WPA2 EAP + certificate every day. Where is your certificate? In /etc/ssl/certs? And how do you refer to it? Did you check "Use System CA Certs", or have you definet the exact file name? The first method works, the latter one does not. That is this report about. However, even fixing this problem is insufficient. Please read this: https://bugzilla.gnome.org/show_bug.cgi?id=341323#c4
Both work, i.e. I had them in /etc/ssl/certs because NetworkManager cannot handle cert-chains. Yet I discovered that having just one certificate in knetworkmanager, i.e. selecting the file from my home folder works as well, so I removed the certs from /etc and eduroam works ever since. And I use TTLS + PAP.
I can't connect to eduroam via knetworkmanager with neither PAP nor MCHAPv2 while MCHAPv2 works good with nm-applet. I tried both using /etc/ssl/certs (system) and defining the location manually for the certificate. Here's a part of my wpa_supplicant.log: Trying to associate with 00:13:19:fc:56:b3 (SSID='eduroam' freq=2462 MHz) Associated with 00:13:19:fc:56:b3 CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected OpenSSL: tls_connection_ca_cert - Failed to parse ca_cert_blob error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag OpenSSL: pending error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error TLS: Failed to set TLS connection parameters EAP-TTLS: Failed to initialize SSL. CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Authentication with 00:00:00:00:00:00 timed out. This is what nm-applet does: Trying to associate with 00:13:19:fc:56:b3 (SSID='eduroam' freq=2462 MHz) Associated with 00:13:19:fc:56:b3 CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) EAP-TTLS: Phase 2 MSCHAPV2 authentication succeeded CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully WPA: Key negotiation completed with 00:13:19:fc:56:b3 [PTK=CCMP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:13:19:fc:56:b3 completed (auth) [id=0 id_str=] After that I killed nm-applet and started knetworkmanager wich was then able to connect: Trying to associate with 00:13:19:fc:56:b3 (SSID='eduroam' freq=2462 MHz) Associated with 00:13:19:fc:56:b3 WPA: Key negotiation completed with 00:13:19:fc:56:b3 [PTK=CCMP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:13:19:fc:56:b3 completed (reauth) [id=0 id_str=] The authentication was already done (10 seconds between disconnect and reconnect). The problem is in the interaction with openSSL.
I checked the dbus output of NetworkManagerUserSettings while nm-applet/knetworkmanager were running. (looks similar to the ones from Tamás Németh, first post) I also have a difference in the ca-cert entry. But mine differes a lot more. I checked the content of the byte arrays with okteta: knetworkmanager's entry containes the certificate file while nm-applet's entry containes the path to the certificate. If whished I put both outputs here.
I solved my problem... In my last post I told you, that I checked the content of ca-cert in the NetworkManagerUserSettings... All I did was to create a file which contains the path to the certificate with a leading file:// and a \0 (<= a zero byte) at the end and used that as certificate in knetworkmanager... And now I'm able to connect to the local eduroam via knetworkmanager using TTLS/MSCHAPv2 and the deutsche-telekom-root-ca-2.pem.
I'm really tired of this bug, it's been what, 2 years or more since this is broken? It's hard to convince people from my university to use KDE when I have to tell them "now if want wireless connection than you have to kill knetworkmanager and start nm-applet"... because now you can't even quit knetworkmanager... Really, myself and a friend would like to give this a spin, where should we start? Do you need testing? Development? What?
Great! The first thing would be to get a development environment set up. I'm currently travelling and away from my own KNM test setup so by the time you have trunk building I should be back. If you have time, start looking at the classes in libs/internals/settings/802-11-wireless-security, backends/NetworkManager/settings, and libs/ui/security.
We will work on this issues after 9th February, on our holidays. We will give news.
Me and my friend Ivo Anjo found the bug. He will be posting here soon giving you all more detail about how we found it and how we plan to fix it. Anyways, just to give you an overview of what's happening, knetworkmanager is simply reading and sending the certificate as is to networkmanager, which is wrong because wpa-supplicant only accepts X509 RAW (at least gnome's nm-applet source code says so). So if you want/need a quick&dirty fix just decode the base64 data (don't forget to remove the header and footer!) inside your X509 PEM certificate to a new file and use it as the certificate in knetworkmanager. This worked out at ours university wireless network (eduroam) but there may be more things broken so it would be good to see more results of doing this trick.
Hello. As João said, we have looked into the issue. Our university's eduroam certificate is provided in PEM format ( http://wifi.ist.utl.pt/configuracoes/cacert.pem ). After a successful connection using nm-applet, we looked at what was in the "ca-cert" byte array as returned by $ qdbus --system --literal org.freedesktop.NetworkManagerUserSettings /org/freedesktop/NetworkManagerSettings/0 org.freedesktop.NetworkManagerSettings.Connection.GetSettings and we found that nm-applet had sent the certificate, but in the DER format (see http://en.wikipedia.org/wiki/X.509#Certificate_filename_extensions ). Running the same command with knetworkmanager yields the original PEM certificate, and the connection fails. We also saw that wpa_supplicant was complaining on its log of not being able to use the certificate. As João said, we then tried to base64-decode our certificate, and fed it to knetworkmanager, and all was fine. Our next step was investigating the gnome network manager sources, where we found, on line 530 of libnm-util/nm-setting-8021x.c that "wpa_supplicant can only use raw x509 CA certs"; that code accepts certificates in three different formats: PEM, DER, and PKCS#12, and converts them if needed so wpa_supplicant can use then. So, to recap: wpa_supplicant wants certificates in a certain format, gnome network manager converts if needed, knetworkmanager currently just reads whatever was pointed to, resulting in troubles with all other formats what wpa_supplicant doesn't like. That was our analysis of the problem. As for the solution, we are working on a patch for knetworkmanager, using QCA to read the different certificate formats, and converting them to the format wpa_supplicant likes. In the meantime, as João pointed out, if you have a PEM certificate, base64-decoding it and feeding it to knetworkmanager should also work.
Thanks guys, this is übercool! You are kings!
I am using latest trunk still not able to connect nm-kde4 keeps asking me for the secrets as above I managed to connect with wicd and nm-applet Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) starting connection 'eduroam' Mar 16 18:50:22 blue NetworkManager: <info> (wlan0): device state change: 3 -> 4 (reason 0) Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 16 18:50:22 blue NetworkManager: <info> (wlan0): device state change: 4 -> 5 (reason 0) Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0/wireless): access point 'eduroam' has security, but secrets are required. Mar 16 18:50:22 blue NetworkManager: <info> (wlan0): device state change: 5 -> 6 (reason 0) Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 16 18:50:22 blue NetworkManager: <WARN> real_connection_secrets_updated(): Ignoring updated secrets for setting 'ipv4'. Mar 16 18:50:22 blue NetworkManager: <WARN> real_connection_secrets_updated(): Ignoring updated secrets for setting '802-11-wireless'. Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 16 18:50:22 blue NetworkManager: <info> (wlan0): device state change: 6 -> 4 (reason 0) Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 16 18:50:22 blue NetworkManager: <info> (wlan0): device state change: 4 -> 5 (reason 0) Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0/wireless): connection 'eduroam' has security, and secrets exist. No new secrets needed. Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'ssid' value 'eduroam' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'scan_ssid' value '1' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-EAP' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'password' value '<omitted>' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'eap' value 'TTLS' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'fragment_size' value '1300' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'phase2' value 'auth=PAP' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'identity' value 'gsteng02' Mar 16 18:50:22 blue NetworkManager: <info> Config: added 'ca_cert' value 'blob://-org-freedesktop-NetworkManagerSettings-0-ca_cert' Mar 16 18:50:22 blue NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 16 18:50:22 blue NetworkManager: <info> Config: set interface ap_scan to 1 Mar 16 18:50:22 blue NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning Mar 16 18:50:24 blue NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating Mar 16 18:50:24 blue NetworkManager: <info> (wlan0): supplicant connection state: associating -> associated Mar 16 18:50:48 blue NetworkManager: <info> Activation (wlan0/wireless): association took too long. Mar 16 18:50:48 blue NetworkManager: <info> (wlan0): device state change: 5 -> 6 (reason 0) Mar 16 18:50:48 blue NetworkManager: <info> Activation (wlan0/wireless): asking for new secrets Mar 16 18:50:48 blue NetworkManager: <info> (wlan0): supplicant connection state: associated -> disconnected Mar 16 18:51:03 blue NetworkManager: <info> wlan0: link timed out.
Ivo and Joao. can you post a script that does the conversion please, if you have it handy? regards, Alin
(In reply to comment #24) > Ivo and Joao. can you post a script that does the conversion please, if you > have it handy? > > regards, > > Alin You can use some something like this: cat cacert.pem | grep -v "CERTIFICATE" | base64 -d > cacert.dem where cacert.pem is the input certificate, and cacert.dem is the output. As for an update on our patch to fix this: sorry we've been delayed a bit on this, because currently I do not have a wireless network card (nor usb stick) on my laptop, so I've been unable to test our patch, but I hope to be able to work on it soon.
HI Ivo, Thanks I will give it a try tomorrow. Maybe you should push the patch in kdereview and others may have a chance to test. Ask Will maybe he has another idea. regards, Alin
This problem still persists in 0.9.svn1057339
I think Bug 235541 is a duplicate of this bug.
I can confirm that the workaround posted in comment #25 by Ivo works. Thanks! Let me know if you want more information.
I proved the solution of comment 25 with the wifi of my University (is part of eduroam) and the network didn't work still.
The workaround posted in comment #25 by Ivo works for me too.
If you would post the patch others could try it and the maintainer might even pick it up and integrate it.
Actually, I suppose that using the conversion posted in comment #25 (cat cacert.pem | grep -v "CERTIFICATE" | base64 -d > cacert.dem) worked me, but I'm not sure. I can connect without certificate but after several minutes connected wpa_supplicant (launched by NM) reports "Michael MIC failure detected" (in daemon.log) and the TKIP countermeasures close the connection. With the certificate, it still happens but it seems later :( With just wpa_supplicant (without NM), the problem does not appear, perhaps because it stays on the same router, while NM launches periodic_update() that makes wpa_supplicant connect to another router. Can a wrong certificate be the cause of Michael MIC failure?
(In reply to comment #32 and #33) I'll see if I can get the code into a minimally decent shape and post it here, but part of the problem is that I don't really know a lot about certificates, so I can only pretty much test my case and hope it works for others, but can't really offer any support. The question posed in comment #33 by Guillaume is such an example: I don't really know :/
Thanks for the hint! When using the .der format, KNetworkManager can connect! However, cat cacert.pem | grep -v "CERTIFICATE" | base64 -d > cacert.dem did not work for me because I had more than one certificate in the pem file. Turned out that I needed to convert the last one. Just saying this because your fix will need to be able to handle multiple certificates in pem files. It would be great to have a working KNetworkManager with pem file support as soon as possible. Thanks for spotting the problem, at least I can now use our WLAN without any problem!
Can't connect in Kubuntu Lucid 10.04.1 with KDE 4.5.1 and its default network applet but it works fine using nm-applet in Ubuntu Lucid 10.04.
Any news on this? I tried all workarounds described here, nothing worked, no connection to eduroam. In this seldom case I really envy people having Windows: They just type user name and password, the rest is done automagically. :-|
(In reply to comment #37) > Any news on this? I tried all workarounds described here, nothing worked, no > connection to eduroam. > > In this seldom case I really envy people having Windows: They just type user > name and password, the rest is done automagically. :-| Can you attach your non-working CA cert here?
Silly, it didn't work on the first day, on the second day I could connect via the workaround from comment #2 (I had done the c_rehash the day before), on the third day I lost my connection and couldn't reestablish the 4th day, on the 5th day it worked again - all at the same place, same network, same signal strength. I'll have to watch the behaviour during the next days.
*** Bug 235541 has been marked as a duplicate of this bug. ***
The workaround of comment 25 worked for me.
I worked around this problem by converting the certificate from the pem-format to the der-format. You can do this using the following commands (just replace CERT with the name of your certificate file, excluding the extension - I used AddTrust_External_Root). $ mkdir -p ~/ca-cert $ openssl x509 -inform PEM -in /etc/ssl/certs/CERT.pem -outform DER -out ~/ca-cert/CERT.der Then use the newly created cert-file, ~/ca-cert/CERT.der, as the CA Certificate in knetworkmanager. (You might have to reboot as well.) I am able to connect to eduroam without any problem at my university.
Unfortunately I am also facing this problem. When I disable network-manager and use wpa_supplicant directly I can associate and use my wireless interface. So I am not really sure if wpa_supplicant can only handle DER encoded CA certificates as stated previously. Converting my PEM certificate into DER format does not solve the problem for me. Could it be that my PEM encoded certificate is broken somehow - but then, wpa_supplicant would also not be able to use it directly? If I convert the cacert.pem to cacert.der using "openssl x509 -inform PEM -in cacert.pem -outform DER -out cacert.der" it generates a der certificate. If I try to convert the cacert with "base64 -d" I am getting an error: "base64: invalid input". Using "base64 -d -i" seems to work. Has anyone an idea to help me out - or do you know if there are eny effords made in fixing this bug in upstream?
The solution by Andreas Gustavsson worked for me. OpenSuse 11.4, KDE 4.6.0.
I am also affected by this bug on KDE 4.6.0, OpenSuse 11.4. Unfortunately, I did not manage to get any of the workarounds to work yet. I cannot connect to Eduroam (TTLS,PAP) under KDE, but on the same machine it works just fine under an old Gnome-Installation. I can connect to other wireless networks just fine. It is quite sad that this old bug is still around, especially since quite a few of my colleagues were driven away from KDE because of it.
I also experience this problem with an eduroam AP. It was driving me nuts. However, after a while I selected "Use system Certs" and then it worked immediately. So specifying a crt file manually is what does not seem to work...
(In reply to comment #46) > I also experience this problem with an eduroam AP. It was driving me nuts. > However, after a while I selected "Use system Certs" and then it worked > immediately. So specifying a crt file manually is what does not seem to work... Unfortunately, there are universities which have their own certs (or signed by another authority which is not within system certs) and it does not work then.
Actually in my case, the certificate offered for download is included in the system certificates, but it still does not work. I tried converting it as outlined above, placed the new file along the old one as root and entered c_rehash, but it still does not work for me. It does work under Gnome though.
(In reply to comment #48) > Actually in my case, the certificate offered for download is included in the > system certificates, but it still does not work. > > I tried converting it as outlined above, placed the new file along the old one > as root and entered c_rehash, but it still does not work for me. > > It does work under Gnome though. Have you also checked daemon.log in /varl/log? When it fails in knetworkmanager, I get the following (beside other output) OpenSSL: tls_connection_ca_cert - Failed to parse ca_cert_blob error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag OpenSSL: pending error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error TLS: Failed to set TLS connection parameters EAP-PEAP: Failed to initialize SSL. EAP: Failed to initialize EAP method: vendor 0 method 25 (PEAP) Do you have the same messages? And does it work with wpa_supplicant and wpa_gui? (Probably, as it works in Gnome for you)
Created attachment 58629 [details] Excerpt from /var/log/Networkmanager I cannot find file called daemon.log, but here is an excerpt from /var/log/NetworkManager (attached). I don't have access to the Gnome installation any more (This had been a previous Ubuntu/Kubuntu install, where I observed it working whenever I logged into Gnome, but not with KDE. Now I have switched to openSUSE11.4 as delivered, without a Gnome installation.) The reason I mentioned that it works under Gnome is that it shows that my hardware, our Eduroam-network and my login credentials can work together.
In addition to my information in <a href="https://bugs.kde.org/show_bug.cgi?id=209673#c42">Comment #42</a>, my eduroam connection is set up like this (since eduroam is supposed to be an international "standard", I hope it works for most people): ssid="eduroam" scan_ssid=1 key_mgmt=WPA-EAP eap=PEAP anonymous_identity="my_identity@school.se" identity="my_identity@school.se" password="********" phase1="peapver=0" phase2="auth=MSCHAPV2" Sorry for making this *eduroam-specific*, but there seem to be a lot of people struggling to make it work.
I have the same issue with KDE 4.6.0 on opensuse 11.4, although the same thing occurs with the plasmoid. nm-applet from gnome works fine, and has done for a good while. We have two PEAP networks (one of which is eduroam) and neither connects. The workaround of converting the cert to a .der file doesn't work here.
I can confirm that I never managed to connect to eduroam using knetworkmanager, and I can confirm that it is really annoying. Also it offers a very negative image of KDE, as end up struggling with this issue during conferences, in front of very surprised windoze users who can easily connect..
(In reply to comment #53) > I can confirm that I never managed to connect to eduroam using knetworkmanager, > and I can confirm that it is really annoying. > > Also it offers a very negative image of KDE, as end up struggling with this > issue during conferences, in front of very surprised windoze users who can > easily connect.. I agree completely. The best solution I can offer, and which I use, is just install networkmanager-gnome and run nm-applet under KDE. It works fine, and is normally much more polished than knm.
(In reply to comment #54) > (In reply to comment #53) > > I can confirm that I never managed to connect to eduroam using knetworkmanager, > > and I can confirm that it is really annoying. > > > > Also it offers a very negative image of KDE, as end up struggling with this > > issue during conferences, in front of very surprised windoze users who can > > easily connect.. > > I agree completely. The best solution I can offer, and which I use, is just > install networkmanager-gnome and run nm-applet under KDE. It works fine, and is > normally much more polished than knm. Thats exactly the same what I do and almost every KDE user I know (some use wicd). It would be interesting to know how many KDE users are using Gnomes nm-applet....
Created attachment 59260 [details] patch to fix certificate support Could you please test the attached patch? I tested it with the reporter's certificate, qdbus output looks the same as he described it with nm-applet.
it is all about the type of the certificate... most eduroam are pem, knm and pnm want a der certificate... all you need to do is to convert the pem to der... openssl x509 -outform der -in <your=pem> -out <your-der> probably best is to add a wish for pnm/knm to suport pem certificates.. by simple performing the ocnversion internally.
Created attachment 59262 [details] First stab at a certificate conversion function using QCA (In reply to comment #56) > Created an attachment (id=59260) [details] > patch to fix certificate support > > Could you please test the attached patch? I tested it with the reporter's > certificate, qdbus output looks the same as he described it with nm-applet. Hi. Your patch takes an interesting approach to the issue, but I think it might not work for everyone, since there are people pointing out that my hack from comment #25 does not work for them, and your patch does the same, just using Qt. As I've said before, I think the best approach would be to use QCA to do the conversion, but I'm really unsure on how to deal with PKCS#12 and files with multiple certificates. I'm attaching a small test program which includes a function called prepareCert, which was my first stab at this, hoping it can help in some way. Thanks for working on this!
Created attachment 59263 [details] simplified the code If you look at /usr/include/NetworkManager/nm-setting-8021x.h, it has a very big comment section from line 92 on. How I understand it, we don't need to do any decoding for PKCS#12, the only problem is with openSSL. But I think we can safely assume that universities and such do not use not-standards-compliant certificates. I just tested nm-applet with multiple certificates (PEM, I don't have a multi-DER-file at hand), it then puts file:///path_to_cert into the ca-cert setting (probably letting wpa_supplicant figure it out). Personally, I think this is inconsistent, as we are trying to save the cert and make the user able to move/delete the file, but let's focus on getting the basic support to work first. About the people not being able to get it to work, without further information there is nothing I can do. If there is no report that the patch is not working I'm going to commit it, possibly buggy cert support is better than none at all. When more info is available I'll try to get it to work always.
I think that we should delegate the work to Qt as much as possible. That said, I also think it is better to rely on the QCA. Regarding the way to give the certificate to wpa_supplicant, I think that it's currently being done right. As far as I remember, KNM is providing the file as a byte array and not as a path. This is correct because the file may be loaded through a KIO slave. If we want to make a private copy of the user's certificate, that has to be explicit in configuration window. As it is now, the GUI shows the path to the certificate so I think the user will expect that a private copy is not being made. I agree with you, improvements are welcome, therefore I support your commit since I don't think it will broke anything that is currently working. That said, I reiterate that this should be implemented with QCA.
>Regarding the way to give the certificate to wpa_supplicant, I think that it's >currently being done right. As far as I remember, KNM is providing the file as >a byte array and not as a path. This is correct because the file may be loaded >through a KIO slave. >If we want to make a private copy of the user's certificate, that has to be >explicit in configuration window. As it is now, the GUI shows the path to the >certificate so I think the user will expect that a private copy is not being >made. If I understand you correctly, you think that KNM stores only the path and reads the original file when the connection is loaded. That is not the case, the certificate is always stored in our connection file in $HOME/.kde/share/apps/networkmanagement/connections, which is read via KConfig (don't know how this handles it internally, may very well be with kio slaves). This is what I meant earlier. On the other hand, if we explicitly want not to make a copy, then we don't need to provide a ca-cert Byte-Array at all, we can provide cert-path only and NetworkManager will do the rest (from what I understand so far, this should be well tested however). I personally prefer the way it is done now, if the user accidentally removes/renames his certificate file (maybe while reorganizing his file system) two years after he created the connection, he won't be cut off from his WiFi without any clue as to what's going on as he has long forgotten about it.
(In reply to comment #61) > well tested however). I personally prefer the way it is done now, if the user > accidentally removes/renames his certificate file (maybe while reorganizing his > file system) two years after he created the connection, he won't be cut off > from his WiFi without any clue as to what's going on as he has long forgotten > about it. What happens if the user replaces the still existing cert with a new one that has the same filename? Does knm notice that? Because currently the GUI shows the path to a file and thus mediates to the user that it uses that file – not some internal copy. So if that cert does not work anymore the user thinks that replacing the file is enough. If the GUI shows a path, knm should use that path and complain if the file is not found anymore. If it copies the cert it should not show a path but mediate via the GUI that it imports the cert. Anything else would be an inconsistency between the GUI and knm's functions.
Actually, I just looked over the code, I was not completely right. setCapath is called everytime the connection is loaded and calls setCacert internally with the certificate which was just read. If the file is gone Cacert is set to an empty QByteArray. In this case it makes no sense however to store the certificate in the connection file at all, I propose to add an isEmpty check to setCapath. If the file exists, the certificate will be overwritten with the contents of the file, otherwise the stored one is used.
You would still have to compare the saved one to the one from the file in case it changed. (Or remove the "path" GUI element)
The saved one gets overwritten with the one from the file in any case if the file exists. We will only use the saved one if the file is missing.
If the GUI shows the path to the certificate, I think that using a private copy of it is wrong. In that case, the user should be notified when the file is not present anymore. This is at least the behavior that I would expect. If we want to change that to the use of a private copy, the user must face a "load/unload certificate" option and not the filling of a path. Anyway, this is getting off-topic...
Created attachment 59286 [details] Redesign I've redesigned the widget, however I'm not sure if that's intuitive enough. What do you say?
Created attachment 59287 [details] redesign when cert is loaded
Fine by me. Just one detail: when a certificate is loaded, force the user to unload it before it loads another. The way you have it now, how can the user just unload (i.e., choose no certificate)?
Why would the user want to choose no certificate? A certificate is required for the connection to work, so he can either check "use system certificates" or load his own, I don't see any case where an explicit unloading of the certificate is required.
You don't see the case, I don't see the case either, but someone else may see it. Also, imagine someone loads a certificate and in the future copies it to the system certificate folder and checks "Use system CA certs". If there is not a way to unload a certificate, we have to at least make sure the user is aware that the previously loaded certificate is being ignored.
I just looked into getting multiple certificates to work, apparently a .der file can only store one certificate, and as we are passing pem certificates as der to NM, we can't just concatenate multiple certificates. If we still want to use a private copy, we would have to store if we have multiple certificates, then create a temporary file with the certificates and point NM to that file, which would be deleted at exit. On the other hand, we could abandon this altogether, and simply pass ca-path to NM, without having to worry about any formats or anything.
(In reply to comment #72) > On the other hand, we could abandon this altogether, and simply pass ca-path to > NM, without having to worry about any formats or anything. I think storing the certificate internally is much awesomer. Currently when setting up access to eduroam on my university, you get the certificate, and have to save it into a folder and remind the user to not ever never ever mess with it. (Of course you can always save inside .kde or .local or something, but most users will leave it on their desktops and then complain that they have to leave it on their desktops). If knm saved the certificate internally, you could download it, load it, and then throw it away and the system would manage the rest.
My thoughts exactly. My current plan looks like this: create a directory $HOME/.kde/share/apps/networkmanagement/certificates, generate a uuid for each certificate and copy it into that directory with that uuid as filename. The uuid is then stored as ca-path in the connection file, the full path is reconstituted at connection loading and passed to NM. This way we still don't have to worry about formats and stuff. BTW, just to be sure: could you please comment out line 116 in libs/internals/settings/802-1x.h and see if NM really picks up the certificate if only the path is provided?
Created attachment 59341 [details] final (?) patch Please test the attached patch and report back. Certificates are stored in $HOME/.kde/share/apps/networkmanagement/certificates for user connections and /usr/share/kde4/apps/networkmanagement/certificates for system connection. Certificates are removed when they are no longer needed, e.g. the connection gets deleted or "use system CAs" gets checked.
Thanks. I haven't been able to test it yet, but I'll try to do it and test with eduroam on my university soon.
Thank you! I will also test it ASAP.
Created attachment 59456 [details] should definitively work now I just stumbled upn a documentation for NM settings, apparently ca-path is the path to a directory containing additional certificates, not one specific certificate. If we want to have that, we must set ca-cert to 'file://path_to_cert'. I've updated the patch.
(In reply to comment #78) > Created an attachment (id=59456) [details] > should definitively work now > > I just stumbled upn a documentation for NM settings, apparently ca-path is the > path to a directory containing additional certificates, not one specific > certificate. If we want to have that, we must set ca-cert to > 'file://path_to_cert'. I've updated the patch. Sorry for the delay, I had to upgrade to 4.6 first (was still running 4.5.5 on my laptop). Anyways, it works perfectly for me. Testing with $ qdbus --system --literal org.freedesktop.NetworkManagerUserSettings /org/freedesktop/NetworkManagerSettings/0 org.freedesktop.NetworkManagerSettings.Connection.GetSettings ca-cert is set to ~/.kde4/share/apps/networkmanagement/certificates/{31d31ae6-1ace-48e8-9ec7-7535baa23d45}, which is where the certificate got copied. I think that the UI when no certificate is loaded (the dark green circle) isn't very clear -- maybe you could add "(No certificate in use)" or something after that? Also, after loading the certificate, it is saved, the connection works (even after rebooting), but if I go to the edit connection dialog, the CA certificate is not shown as loaded (the dark green circle is shown). And thanks for finally fixing this :) I can finally dump nm-applet!
Created attachment 59540 [details] fix certificate not being displayed correctly on connection edit Thanks for testing. I'm going to run this by the other devs before committing, in the meantime I have attached a fixed version which shows the correct status of the certificates on connection edits.
(In reply to comment #80) > Created an attachment (id=59540) [details] > fix certificate not being displayed correctly on connection edit > > Thanks for testing. I'm going to run this by the other devs before committing, > in the meantime I have attached a fixed version which shows the correct status > of the certificates on connection edits. Just tested it, I can confirm that this new patch fixes the certificate status.
*** Bug 209728 has been marked as a duplicate of this bug. ***
Git commit c49327938a27373a77529ef49811f6547943672a by Ilia Kats. Committed on 24/04/2011 at 00:17. Pushed by iliakats into branch 'master'. Improve handling of 802.1x certificates Certificates are now imported to $HOME/.kde/share/networkmanagement/certificates for user scope connections and /usr/share/kde4/apps/networkmanagement/certificates for system scope connections. This allows the user to move the original file out of the way without worrying about connections. Certificates are passed to NM using the path scheme to enable support for files containing multiple certificates. BUG: 209673 REVIEW: 101275 M +1 -0 CMakeLists.txt M +2 -0 backends/NetworkManager/nmdbussettingsconnectionprovider.cpp M +14 -0 libs/internals/connection.cpp M +6 -5 libs/internals/connection.h M +1 -1 libs/internals/connectionpersistence.cpp M +10 -0 libs/internals/setting.cpp M +5 -0 libs/internals/setting.h M +103 -1 libs/internals/settings/802-1x.cpp M +191 -8 libs/internals/settings/802-1x.h M +12 -12 libs/internals/settings/802-1xpersistence.cpp M +1 -0 libs/ui/security/eapmethodleap.cpp M +71 -27 libs/ui/security/eapmethodpeapbase.ui M +136 -20 libs/ui/security/eapmethodtlsbase.ui M +54 -12 libs/ui/security/eapmethodttlsbase.ui M +44 -13 libs/ui/security/peapwidget.cpp M +6 -2 libs/ui/security/peapwidget.h M +132 -55 libs/ui/security/tlswidget.cpp M +6 -1 libs/ui/security/tlswidget.h M +46 -10 libs/ui/security/ttlswidget.cpp M +5 -1 libs/ui/security/ttlswidget.h M +25 -14 settings/config/manageconnectionwidget.cpp M +4 -3 settings/config/manageconnectionwidget.h http://commits.kde.org/networkmanagement/c49327938a27373a77529ef49811f6547943672a
Git commit 23385210c79df483cfeb47a31631677cf33cd18c by Ilia Kats. Committed on 24/04/2011 at 00:17. Pushed by iliakats into branch 'nm09'. Improve handling of 802.1x certificates Certificates are now imported to $HOME/.kde/share/networkmanagement/certificates for user scope connections and /usr/share/kde4/apps/networkmanagement/certificates for system scope connections. This allows the user to move the original file out of the way without worrying about connections. Certificates are passed to NM using the path scheme to enable support for files containing multiple certificates. BUG: 209673 REVIEW: 101275 (cherry-picked from commit c49327938a27373a77529ef49811f6547943672a) had to some manual adaptations, should be fine (at least it compiles). Just revert this commit if it doesn't work. M +1 -0 CMakeLists.txt M +3 -0 backends/NetworkManager/nmdbussettingsconnectionprovider.cpp M +14 -0 libs/internals/connection.cpp M +5 -4 libs/internals/connection.h M +1 -1 libs/internals/connectionpersistence.cpp M +10 -0 libs/internals/setting.cpp M +5 -0 libs/internals/setting.h M +103 -1 libs/internals/settings/802-1x.cpp M +191 -8 libs/internals/settings/802-1x.h M +12 -12 libs/internals/settings/802-1xpersistence.cpp M +1 -0 libs/ui/security/eapmethodleap.cpp M +71 -27 libs/ui/security/eapmethodpeapbase.ui M +136 -20 libs/ui/security/eapmethodtlsbase.ui M +54 -12 libs/ui/security/eapmethodttlsbase.ui M +44 -13 libs/ui/security/peapwidget.cpp M +6 -2 libs/ui/security/peapwidget.h M +132 -55 libs/ui/security/tlswidget.cpp M +6 -1 libs/ui/security/tlswidget.h M +46 -10 libs/ui/security/ttlswidget.cpp M +5 -1 libs/ui/security/ttlswidget.h M +1 -2 settings/config/manageconnectionwidget.cpp M +2 -2 settings/config/manageconnectionwidget.h http://commits.kde.org/networkmanagement/23385210c79df483cfeb47a31631677cf33cd18c
Is this patch in KDE SEC 4.6.3?
(In reply to comment #85) > Is this patch in KDE SEC 4.6.3? networkmanagement is not (as of 4.6.x) part of KDE SC, it is released separately.
Can anybody build package with this fix for kubuntu 11.04?
For those trying this. Here it does not work if you use an existing profile, i.e. pnmm will still send the path of the file you had set for that profile to wpa_aupplicant even if you remove that file! If you set-up a new profile it will correctly set the path to ~/.kde4/...
*** Bug 252668 has been marked as a duplicate of this bug. ***
I have build a Kubuntu 11.04 package of a git snapshot (as of 20-07-2011). It is available at https://launchpad.net/~maarten-bezemer/+archive/ppa For me this solves the described problem.
Martin, your ppa does not exist anymore. Has this been integrated in the current knetworkmanager? Because it still does not work for me.. (using kubuntu 11.04, plasma-widget-networkmanagement 0.9~svngit20110408-0ubuntu2) Thanks
Oops... I changed my username (had it the wrong way round with my Real name) The PPA is at https://launchpad.net/~veger/+archive/ppa
I updated to openSUSE 12.1, i.e. there were working configs before and only plasmoid-networkmanagement and NetworkManager got updated. After that the connection to eduroam WPA EAP + certificate fails again. The progress bar in the systray icon does not even get past the first stage. reason 3 seems to be: /* Device is now unmanaged */ NM_DEVICE_STATE_REASON_NOW_UNMANAGED = 3, plasmoid-networkmanagement-0.9.1git20111027-1.1.2.i586 NetworkManager-vpnc-kde4-0.9.1git20111027-1.1.2.i586 NetworkManager-openvpn-kde4-0.9.1git20111027-1.1.2.i586 NetworkManager-pptp-0.9.0-3.1.2.i586 NetworkManager-kde4-libs-0.9.1git20111027-1.1.2.i586 NetworkManager-pptp-kde4-0.9.1git20111027-1.1.2.i586 NetworkManager-vpnc-0.9.0-2.1.2.i586 NetworkManager-0.9.1.90-4.1.3.i586 NetworkManager-openvpn-0.9.0-2.1.2.i586 Did anyone already try WPA EAP with certificates and Nm 0.9? from wpa_supplicant: CTRL-EVENT-CONNECTED - Connection to 00:0f:66:d3:14:5a completed (reauth) [id=0 id_str=] CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Trying to authenticate with 00:25:84:87:35:7d (SSID='eduroam' freq=5320 MHz) Trying to associate with 00:25:84:87:35:7d (SSID='eduroam' freq=5320 MHz) Associated with 00:25:84:87:35:7d CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Trying to authenticate with 00:25:84:87:35:7d (SSID='eduroam' freq=5320 MHz) Trying to associate with 00:25:84:87:35:7d (SSID='eduroam' freq=5320 MHz) Associated with 00:25:84:87:35:7d CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 NetworkManager Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Activation (wlan0/wireless): connection 'eduroam2' has security, and secrets exist. No new secrets needed. Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Activation (wlan0/wireless): connection 'eduroam2' has security, and secrets exist. No new secrets needed. Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'ssid' value 'eduroam' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'ssid' value 'eduroam' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'scan_ssid' value '1' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'scan_ssid' value '1' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'key_mgmt' value 'WPA-EAP' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'key_mgmt' value 'WPA-EAP' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'password' value '<omitted>' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'password' value '<omitted>' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'eap' value 'TTLS' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'eap' value 'TTLS' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'fragment_size' value '1300' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'fragment_size' value '1300' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'phase2' value 'auth=MSCHAPV2' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'phase2' value 'auth=MSCHAPV2' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'ca_path' value '/etc/ssl/certs' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'ca_path' value '/etc/ssl/certs' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'ca_path2' value '/etc/ssl/certs' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'ca_path2' value '/etc/ssl/certs' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'identity' value 'x@y.z' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'identity' value 'x@y.z' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'anonymous_identity' value 'anonymous@y.z' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'anonymous_identity' value 'anonymous@y.z' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: added 'bgscan' value 'simple:30:-45:300' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: added 'bgscan' value 'simple:30:-45:300' Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> Config: set interface ap_scan to 1 Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> Config: set interface ap_scan to 1 Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: <info> (wlan0): supplicant interface state: inactive -> scanning Nov 8 16:30:48 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> (wlan0): supplicant interface state: inactive -> scanning Nov 8 16:30:50 linux-vdb1 NetworkManager[4124]: <info> (wlan0): supplicant interface state: scanning -> authenticating Nov 8 16:30:50 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> (wlan0): supplicant interface state: scanning -> authenticating Nov 8 16:30:51 linux-vdb1 NetworkManager[4124]: <info> (wlan0): disconnecting for new activation request. Nov 8 16:30:51 linux-vdb1 NetworkManager[4124]: <info> (wlan0): device state change: config -> disconnected (reason 'none') [50 30 0] Nov 8 16:30:51 linux-vdb1 NetworkManager[4124]: <info> (wlan0): deactivating device (reason 'none') [0] Nov 8 16:30:51 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> (wlan0): disconnecting for new activation request. Nov 8 16:30:51 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> (wlan0): device state change: config -> disconnected (reason 'none') [50 30 0] Nov 8 16:30:51 linux-vdb1 NetworkManager[4124]: NetworkManager[4124]: <info> (wlan0): deactivating device (reason 'none') [0]
I have been using eduroam regularly for the past few weeks, it works perfectly for me with a current nm09 build. Your wpa_supplicant is disconnecting with a code of 3, which, according to src/common/ieee802_11_defs.h from wpa_supplicant source code is WLAN_REASON_DEAUTH_LEAVING. IEEE 802.11 2007 standard says for reason 3: "Deauthenticated because sending STA is leaving (or has left) IBSS or ESS". Taking into account that the BSSID is 00:00:00:00:00:00 when wpa_supplicant is disconnecting, I'd say this looks like a problem with your access point (I could be wrong though, I didn't really have time to read the whole standard. It definitely doesn't seem to be Plasma NM's fault, however).
(In reply to comment #94) > I have been using eduroam regularly for the past few weeks, it works perfectly > for me with a current nm09 build. Ok, thanks for that feedback. Could you please tell me what NM version you use? Did the nm09 build import the profiles for you or did you create a new one after switching to nm09?
Eduroam was only introduced at my university about three months ago, so I created a new connection from scratch in nm09, which I was using at that time already. The version I'm using now is a build of nm09 HEAD from beginning of October, I think (I'm not at my machine right now, so I can't tell the exact date. Didn't really have time to build new snapshots recently), which is even a bit older than what you're using.
Sry for the double post, but in case you mean the NM daemon: 0.9.0 (an update to 0.9.1.95 came in a few days ago, I didn't have the chance to test eduroam with this version yet)
I use eduroam daily and it works... I use kde trunk Alin
Kubuntu 11.10 (Oneiric Ocelot) includes the fixed version and is working great with eduroam
I can confirm that I finally can connect to Eduroam with KDE 4.7.3 (Kubuntu Oneiric). Thanks!