Bug 695666 - plasma-nm : support nm-0.9
Summary: plasma-nm : support nm-0.9
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-plasma-networkmanagement
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
: 704627 (view as bug list)
Depends On:
Blocks: 699267
TreeView+ depends on / blocked
Reported: 2011-04-12 11:12 UTC by Martin Kho
Modified: 2011-06-30 18:58 UTC (History)
7 users (show)

Fixed In Version: kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-30 18:58:44 UTC
Type: ---

Attachments (Terms of Use)

Description Martin Kho 2011-04-12 11:12:58 UTC
Description of problem:
The network is functioning correct, but the systray icon is red with a white cross in it and saying the above message. Enabling the interface - after clicking the icon - doesn't change the situation.

Version-Release number of selected component (if applicable):
* kde-plasma-networkmanagement-0.9-0.40.20110323.fc16.x86_64
* kdenetwork-4.6.2-1.fc16.x86_64
* NetworkManager-0.8.997-5.git20110328.fc16.x86_64

How reproducible:
Always, also tried with an new user.

Steps to Reproduce:
1. Just log in, the networks starts automatically
Actual results:
'disabled' network

Expected results:
'enabled' network

Additional info:

Comment 1 Kevin Kofler 2011-04-12 14:22:05 UTC
Rawhide's NetworkManager doesn't have the compat patches applied that are needed for the current kde-plasma-networkmanagement to work. You have to use an F15 build of NetworkManager until kde-plasma-networkmanagement is ported to the NetworkManager 0.9 API.

Comment 2 Martin Kho 2011-04-12 14:44:13 UTC
Hi Kevin,

Okay, thanks for your explanation. Should have asked it on the kde list first :-)
Please close this report.

Martin Kho

Comment 3 Rex Dieter 2011-04-12 14:53:15 UTC
Naw, may as well keep this open to track plasma-nm support for nm-0.9

Comment 4 Martin Kho 2011-04-20 20:23:16 UTC

Today NetworkManager was updated to version 0.8.998-2.git20110406.fc15.x86_64. Now everything seems fine again. This report can be closed I suppose?


Martin Kho

Comment 5 Kevin Kofler 2011-04-20 20:27:58 UTC

We need to support the real NetworkManager 0.9 API in the long run, not the compatibility API which was developed specifically for Fedora 15, will never be supported by upstream NetworkManager and will go away in Fedora 16.

Comment 6 Ernesto Manríquez 2011-05-08 18:52:30 UTC
KDE 4.6.3 doesn't build NM Solid backend anymore with Network Manager 0.9. I updated my system to KDE 4.6.3 using Rex's kde-testing repo, under Fedora 15, and I have no network. Can you reenable this backend to allow the compatibility code in Fedora 15 to kick in?

I'm currently running with GNOME's nm-applet (and the amazing thing: with no applet, NetworkManager kept connecting well).

Comment 7 Kevin Kofler 2011-05-08 20:13:40 UTC
> KDE 4.6.3 doesn't build NM Solid backend anymore with Network Manager 0.9. I
> updated my system to KDE 4.6.3 using Rex's kde-testing repo, under Fedora 15,
> and I have no network. Can you reenable this backend to allow the compatibility
> code in Fedora 15 to kick in?

Argh, I didn't expect such a change in a release branch (but it makes sense, because it really won't work at all without our compatibility patches to both NM 0.9 itself and Solid). I'm fixing this. (I'm going to revert the offending one-line CMakeLists.txt change in the nm-09-compat patch.)

Comment 8 Kevin Kofler 2011-05-08 20:37:56 UTC
I'm now building kdebase-workspace-4.6.3-4.fc15 which has the Solid NM backend reenabled (still based on the compatibility code, so this bug should still stay open). I hope Rex will put it up into kde-testing ASAP.

Comment 9 Ernesto Manríquez 2011-05-08 22:56:51 UTC
Works :). Thanks, Kevin.

Comment 10 Martin Kho 2011-05-10 20:34:05 UTC
Hi Kevin,

The updated kdebase-workspace-4.6.3-4.fc16 doesn't work with NetworkManager-0.8.999-1.fc16.x86_64. I get a red button with a white cross in it (No network interfaces)

Information Sources contains the entry NetworkManager 0.7, so the Solid NM backend is enabled.

Networking is working.

Maybe I misses something? If you need more info, please let me know.


Martin Kho

Comment 11 Kevin Kofler 2011-05-10 20:36:55 UTC
You have to use a NetworkManager-*.fc15 build for now, the NetworkManager-*.fc16 builds don't include the compatibility hack.

Comment 12 Kevin Kofler 2011-05-13 21:18:32 UTC
*** Bug 704627 has been marked as a duplicate of this bug. ***

Comment 13 Ernesto Manríquez 2011-05-18 22:45:55 UTC
From what I see in PlanetKDE, Lamarque Souza is working on a proper fix for this, at a neck breaking speed. On May 16th his work was committed to the nm09 branch at projects.kde.org, and today a severe bug disabling account editing was fixed. This new solution involves a brand new Solid backend for NetworkManager 0.9, and, at least with my copy of Fedora 15, is working.

(Tested with git clone -b nm09 git://anongit.kde.org/networkmanagement , as of today)

It does have limitations, but this new work is behaving better here than the old solution (the compatibility code). Will you package that NetworkManager KDE client? When? I know Bugzilla is not a forum, but Lamarque's work seem to be a real fix for this bug.

Comment 14 Kevin Kofler 2011-05-18 23:00:10 UTC
Well, we should get this into Rawhide first of all (also because Rawhide doesn't have the compat API at all, so kde-plasma-networkmanagement is currently entirely broken in Rawhide). Then we can see how well it works before pushing it to F15. The compat hack actually works relatively well (I tested WPA-PSK and WPA-EAP, they just work), we have to be careful not to cause regressions by rushing a replacement.

Another big issue for pushing this to F15 is that we need settings migration sorted out. IMHO, it is not acceptable to push an update which forces you to reenter all your network connections, and the suggested workaround of (manually) changing the connections to system connections before upgrading does not work on F15 because the compat hack does not support system connections. And to properly migrate existing user connections, we'll need the secrets agent implemented. Currently, only systemwide secrets are supported. The proper way to convert user connections is to make them system connections with permissions only for the current user (a new feature in NM 0.9, which replaces the previous user connections system) and with per-user secrets (for which NM 0.9 requires that secrets agent, whereas in NM 0.8 and in the compat hack in F15, the entire connection including the secrets was stored per user by the applet). Just moving the secrets to systemwide (and thus unencrypted or trivially encrypted) storage without asking would be extremely rude (for security reasons), deleting or ignoring them would be just as rude (for usability reasons), so the secrets agent is a requirement for implementing migration. Then the migration itself has to be implemented, too.

Making some unofficial packages available is actually possible quite soon (we just need to get the stuff into Rawhide and then we can rebuild it for F15 easily), but to push this as an official update, a lot more work is needed.

Comment 15 Ernesto Manríquez 2011-05-19 00:25:48 UTC
1. That's what happens when you, a capable engineer, test only well secured connections. I had some serious trouble trying to connect, using the compatibility code, to a WEP connection (I tried with Fedora pre-beta, I have to retest if I want to file a proper bug report about that, WPA-PSK, what I use, works, but WEP doesn't). There are here some ISPs that sell sealed WiFi routers with WEP and only WEP. We can discuss all day about how crappy WEP is, but that's what people use, at least here in Chile.

2. I like your plan. You have all my trust, Kevin.

Comment 16 Martin Kho 2011-05-21 15:17:32 UTC

kde-plasma-networkmanagement-0.9-0.48.20110519.fc16.x86_64 as a first nm-0.9 compatible version is - for me - already in very good shape! With this version it's the first time ever that i can see the current active connection, in my case "Auto eth0", under Manage (Network) Connections :-). But I'm only using a simple wired connection, so I don't know how it behaves with wireless set ups.

Till now you've done a great job, thanks a lot.

Martin Kho

Comment 17 Shawn 2011-05-22 17:25:16 UTC
I am just some testing the packages below and I am able to switch between unencrypted and WPA2 connections seamlessly. I don't have any WAP connections I can test with.


Comment 18 Stan Trzmiel 2011-06-04 12:18:58 UTC

Basic networking works fine, I can access system connections too

Connecting to x509+user/pass protected openvpn fails. There are some entries in /var/log/messages regarding failed connection:

Jun  4 13:48:50 xeno kernel: : [ 5209.632728] NetworkManager[1086]: <info> Starting VPN service 'openvpn'...
Jun  4 13:48:50 xeno kernel: : [ 5209.637062] NetworkManager[1086]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 22560
Jun  4 13:48:51 xeno kernel: : [ 5210.259599] NetworkManager[1086]: <info> VPN service 'openvpn' appeared; activating connections
Jun  4 13:48:51 xeno kernel: : [ 5210.466440] NetworkManager[1086]: <info> VPN plugin state changed: 3
Jun  4 13:48:51 xeno kernel: : [ 5210.466482] NetworkManager[1086]: <info> VPN connection 'BlueSoft HQ' (Connect) reply received.
Jun  4 13:48:51 xeno kernel: : [ 5210.466493] NetworkManager[1086]: <warn> VPN connection 'BlueSoft HQ' failed to connect: 'property 'user-name' invalid or not supported'.
Jun  4 13:48:51 xeno kernel: : [ 5210.466923] NetworkManager[1086]: <warn> error disconnecting VPN: Could not process the request because no VPN connection was active.
Jun  4 13:48:51 xeno kernel: : [ 5210.467744] NetworkManager[1086]: <info> Policy set 'Xenos' (wlan1) as default for IPv4 routing and DNS.
Jun  4 13:48:56 xeno kernel: : [ 5216.075113] NetworkManager[1086]: <info> VPN service 'openvpn' disappeared

Comment 19 Stan Trzmiel 2011-06-04 17:35:24 UTC
Above issue reported upstream, bug id: 274930

Comment 20 collura 2011-06-24 11:23:33 UTC
hmm, they seem to have closed the upstream 
but also commented 
that it had a forgetfulness problem.

i seem to have 
  kde-plasma-networkmanagement-1:0.9-0.47.20110323.fc15.1 (x86_64)
from f15-kde-updates-testing so not quite there yet
(still cant get the wifi to connect, awaiting 0.9-0.48 :') )

Comment 21 Stan Trzmiel 2011-06-24 12:26:27 UTC
kde-plasma-networkmanagement-0.9-0.53.20110616git in kde-redhat-unstable.
Works good enough, tho sometimes it happen that NM eats all the CPU it can.  kill -9 then starting service once again usually does the trick.

Comment 22 Rex Dieter 2011-06-24 12:35:08 UTC
"NM-eating CPU" issue, we think, should be fixed by,

Comment 23 Fedora Update System 2011-06-24 12:52:42 UTC
kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15 has been submitted as an update for Fedora 15.

Comment 24 Fedora Update System 2011-06-24 17:58:25 UTC
Package kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 25 Fedora Update System 2011-06-30 18:58:26 UTC
kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.