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):
Always, also tried with an new user.
Steps to Reproduce:
1. Just log in, the networks starts automatically
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.
Okay, thanks for your explanation. Should have asked it on the kde list first :-)
Please close this report.
Naw, may as well keep this open to track plasma-nm support for nm-0.9
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?
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.
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).
> 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.)
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.
Works :). Thanks, 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.
You have to use a NetworkManager-*.fc15 build for now, the NetworkManager-*.fc16 builds don't include the compatibility hack.
*** Bug 704627 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.
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: <info> Starting VPN service 'openvpn'...
Jun 4 13:48:50 xeno kernel: : [ 5209.637062] NetworkManager: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 22560
Jun 4 13:48:51 xeno kernel: : [ 5210.259599] NetworkManager: <info> VPN service 'openvpn' appeared; activating connections
Jun 4 13:48:51 xeno kernel: : [ 5210.466440] NetworkManager: <info> VPN plugin state changed: 3
Jun 4 13:48:51 xeno kernel: : [ 5210.466482] NetworkManager: <info> VPN connection 'BlueSoft HQ' (Connect) reply received.
Jun 4 13:48:51 xeno kernel: : [ 5210.466493] NetworkManager: <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: <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: <info> Policy set 'Xenos' (wlan1) as default for IPv4 routing and DNS.
Jun 4 13:48:56 xeno kernel: : [ 5216.075113] NetworkManager: <info> VPN service 'openvpn' disappeared
Above issue reported upstream, bug id: 274930
hmm, they seem to have closed the upstream
but also commented
that it had a forgetfulness problem.
i seem to have
from f15-kde-updates-testing so not quite there yet
(still cant get the wifi to connect, awaiting 0.9-0.48 :') )
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.
"NM-eating CPU" issue, we think, should be fixed by,
kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15 has been submitted as an update for Fedora 15.
* 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).
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.