I'm trying to connect to a secure wired network. In the "802.1x Security" tab, I check the "Use 802.1x authentication" box, fill out all of the information - Identity, certificates, private key, and so on - and click "Ok". Network manager does not connect to the network. I open the connection settings again - but all of the information is gone, and "Use 802.1x authentication" is unchecked.
Which Plasma NM version do you use? You can see the version string in "Manage Connections" -> "Other". Please also send the NetworkManager's log.
Created attachment 78558 [details] NetworkManager log There's nothing new in the log when I edit the connection, so this is just the log since I restarted NM.
And here's the version string: Version 0.9.0.8 (nm09 20130310)
Send the ~/.xsession-errors file too.
Here's the .xsession-errors log from a few attempts: kcmshell(3700)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized kcmshell(3700)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-11-wireless-security" not initialized kcmshell(3700)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) plasma-desktop(2755)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application plasma-desktop(2755)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application kded(2706)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized kded(2706)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized kcmshell(3700)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized kded(2706)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized QFSFileEngine::open: No file name specified QFSFileEngine::open: No file name specified kded(2706)/Network Management (NetworkManager backend) ConnectionDbus::fromDbusMap: Setting "802-1x" not initialized QFSFileEngine::open: No file name specified
I actually managed to connect successfully. I think the problem is, if I leave any of the fields blank, then none of the information gets saved. An easy repro (for me, at least) is to just check "Use 802.1x ..." and click "Ok", then open that connection again. (I'm still not sure why it didn't work for me the first time - I'm pretty sure I filled everything in - but I guess it's possible that I missed something.) A related bug: if I do fill out all of the information, save it, edit the connection again, then clear one of the fields, it won't get saved. That is, next time I open it, the deleted data will still be there.
I played around some more, and now it's failing again, even when I enter the correct information. When I click "Ok", I see this in the log: process 3700: arguments to dbus_message_iter_append_basic() were incorrect, assertion "*bool_p == 0 || *bool_p == 1" failed in file ../../dbus/dbus-message.c line 2613. This is normally a bug in some application using the D-Bus library. QFSFileEngine::open: No file name specified
(In reply to comment #7) > I played around some more, and now it's failing again, even when I enter the > correct information. When I click "Ok", I see this in the log: > > process 3700: arguments to dbus_message_iter_append_basic() were incorrect, > assertion "*bool_p == 0 || *bool_p == 1" failed in file > ../../dbus/dbus-message.c line 2613. > This is normally a bug in some application using the D-Bus library. > QFSFileEngine::open: No file name specified Well, this is a message from the dbus library, I need something from the Plasma NM (or NetworkManager) call that triggered that error message. What does appear before the " process 3700" line and what process is 3700?
Created attachment 78644 [details] .xsession-errors Here's the complete log. Looks like process 3700 was "kcmshell".
I've restarted KDE, and tried everything again. Here's what I got: - Opened the existing wired connection and added the 802.1x settings successfully. - Disabled 802.1x. - Re-enabled 802.1x; everything still worked. - Deleted the wired connection. At this point, the whole "Wired" tab got disabled, and I got switched to "Wireless" (a different bug?). My ethernet device was not plugged in, so I had to plug it into get the "Wired" tab back. - Created a new wired connection, entered the 802.1x settings - and they got lost when I saved it. I'll attach the logs.
Created attachment 78645 [details] .xsession-errors after successfully enabling 802.1x
Created attachment 78646 [details] .xsession-errors after two successful attempts, then a failed one.
(In reply to comment #10) > I've restarted KDE, and tried everything again. Here's what I got: > > - Opened the existing wired connection and added the 802.1x settings > successfully. > - Disabled 802.1x. > - Re-enabled 802.1x; everything still worked. > - Deleted the wired connection. At this point, the whole "Wired" tab got > disabled, and I got switched to "Wireless" (a different bug?). My ethernet > device was not plugged in, so I had to plug it into get the "Wired" tab back. That's new to me and I cannot reproduce the the problem with Wired tab getting disabled. > - Created a new wired connection, entered the 802.1x settings - and they got > lost when I saved it. I can reproduce this with TLS authentication. Plasma NM always correctly (I guess) saves the configuration with LEAP authentication. I guess one of the values in TLS tab are required by NetworkManager and is missing or in a format that NetworkManager does not allow. The question know is figuring out which value is that.
You can try launching NetworkManager on command line and enable full logging: NetworkManager --log-level=DEBUG 2>&1 log.txt reproduce the problem, then send me log.txt.
Created attachment 78944 [details] NetworkManager debug log Here's a log file after running: sudo NetworkManager --no-daemon --log-level=DEBUG >log.txt 2>&1 This looks like a bug: (NetworkManager:28647): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed NetworkManager[28647]: <debug> [1366064445.766806] [nm-settings-connection.c:1523] nm_settings_connection_read_and_fill_timestamp(): failed to read connection timestamp for '69fed207-08a9-4add-8fb3-897011a6cdce': (3) Key file does not have key '69fed207-08a9-4add-8fb3-897011a6cdce'
Looks like a corrupted file. Is the connection with uuid 69fed207-08a9-4add-8fb3-897011a6cdce the one you created? Which encryption type are you using?
I'm not sure how to check the connection uuid - but those errors appear when I add the connection, and the same uuid appears in the dhclient call: NetworkManager[28647]: <debug> [1366064445.774912] [nm-dhcp-dhclient.c:560] dhclient_start(): running: /sbin/dhclient -d -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /run/sendsigs.omit.d/network-manager.dhclient-eth1.pid -lf /var/lib/NetworkManager/dhclient-69fed207-08a9-4add-8fb3-897011a6cdce-eth1.lease -cf /var/lib/NetworkManager/dhclient-eth1.conf eth1 (It's also the only wired connection I have.) I'm using TLS encryption.
I can confirm the problem. I tried with both an 802.11x authenticated wired network and a wireless network, using TLS authentication. When completing the network configuration and saving it, the configuration is forgotten and the "connection editor" window does not show the message "connection <name> has been added". I can use these connection by setting the connection without security and subsequently manually editing the file in /etc/NetworkManager/system-connections to add the settings about 802.11x. I'm using Arch Linux with plasma-nm version 0.9.3.1
Looks like I have the same problem, except that I'm trying to change an existing connection settings. I change certificate data and press OK, then open the connection settings again and see that old settings are all there. The log says: Dec 17 20:22:11 riseberg NetworkManager[3103]: get_secret_flags: assertion 'is_secret_prop (setting, secret_name, error)' failed Dec 17 20:22:48 riseberg NetworkManager[3103]: Error setting certificate (invalid data): (1) ca-cert Dec 17 20:22:48 riseberg NetworkManager[3103]: Error setting certificate (invalid data): (1) client-cert Dec 17 20:22:48 riseberg NetworkManager[3103]: Error setting private key (invalid data): (1) private-key I managed to actually change the settings by starting gnome network manager applet and doing the change there. The worst thing is that there's no clue that something is wrong, so I spent a lot of time figuring out that my settings could not be saved.
Created attachment 84315 [details] Bugfix plasma-nm does not properly terminates with a NULL byte the QByteArrays relative to the certificates and private keys when using 802.1x security. In the function verify_cert (libnm-util/nm-setting-8021x.c), libnm-util checks for array->data[array->len - 1] == '\0', causing the reported misbehavior. Adding a trailing '\0' to the involved QByteArrays does solve the problem for me.
Filed bug 329342, as the problem pertains to the plasma-nm product. This bug should be marked a duplicate of #329342, but I can't do that.
I think bug 329342 is different from this one. By the way, this bug is against Plasma NM 0.9.0.x and bug 329342 is against Plasma NM 0.9.2.x and 0.9.8.x. They are different implementations. This bug still stand since Plasma NM 0.9.0.x appends the null byte already. I can still reproduce this bug but NetworkManager does not print error messages about wrong setting even in debug mode. The only thing it prints is this: (NetworkManager:29675): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed NetworkManager[29675]: <debug> [1388321607.386847] [nm-settings-connection.c:1524] nm_settings_connection_read_and_fill_timestamp(): failed to read connection timestamp for '0b88c9e6-2049-40a9-97b2-a59a0e411dfb': (3) Key file does not have key '0b88c9e6-2049-40a9-97b2-a59a0e411dfb' But that is not really helpfull. The second message is just a warning. I have not figure out where and why it prints the first message. Still debugging ...
Git commit b4dfa38892770c59e42fb8bb68d50e1b01d4fabb by Lamarque V. Souza. Committed on 29/12/2013 at 14:39. Pushed by lvsouza into branch 'nm09'. Mark 802.1x settings as initialized when writting the settings. FIXED-IN: 0.10.0.11 M +1 -0 libs/ui/security/securitywired8021x.cpp http://commits.kde.org/networkmanagement/b4dfa38892770c59e42fb8bb68d50e1b01d4fabb
On 29/12/2013 14:34, Lamarque V. Souza wrote: > I think bug 329342 is different from this one. By the way, this bug is against > Plasma NM 0.9.0.x and bug 329342 is against Plasma NM 0.9.2.x and 0.9.8.x. They > are different implementations. Ouch, sorry for the mess! When I found this bug I wrongly assumed that it was referring to the "new" implementation (plasma-nm 0.9.2.x and newer) instead of the "old" one.
I'm seeing the exact same problem when using TLS authentication in a *wireless* network: Apr 30 13:48:39 dima-xps NetworkManager[770]: Error setting certificate (invalid data): (1) ca-cert Apr 30 13:48:39 dima-xps NetworkManager[770]: Error setting certificate (invalid data): (1) client-cert Apr 30 13:48:39 dima-xps NetworkManager[770]: Error setting private key (invalid data): (1) private-key Should I file a new bug for this? Also, even if something fails, could you please display a useful error message instead of silently ignoring the failure?
I cannot reproduce this problem using wireless, neither with "Dynamic WEP" nor "WPA/WPA2 Enterprise", which are the only two security types that accepts TLS as authentication method. Can you give me more details on how to reproduce this problem?