Bug 708626

Created attachment 501470 [details]
backtrace that was dumped into /var/log/messages

Ignore the "Invalid WEP key" message for ifcfg-wlan0, because the working downgraded version says that too.

Created attachment 501471 [details]
ifcfg file that "kills" NM

Confirmed bug on F15 i686 stable repositories + RPMFusion stable, confirmed fix is downgrade. Dear $deity, the Fedora NM situation is a mess (doubly so for KDE users...)

In my case it was croaking on a PPTP VPN definition in /etc/NetworkManager/system-connections (stuck in endless service restart cycle). VPN definition file  and /var/log/messages backtrace output attached, sensitive info replaced with the text REDACTED-BUT-VALID.

Created attachment 501502 [details]
/var/log/messages backtrace info - mihailim

Created attachment 501503 [details]
/etc/NetworkManager/system-connections VPN definition - mihailim

Possible duplicate of bug 708445 ?
In my case it wasn't choking on VPN connections but on the wired and wireless networks in /etc/sysconfig/network-scripts

Yup, thanks, Jean-François, my testcase is clearly #708445 , please ignore my comments on this bug. Obsoleting attachments.

Confirmed on my laptop.  Upgrade broke NM, downgrade works fine.

Confirmed.
Download solves the problem.

This hurt me too on an HP530 laptop completely destroying wifi connectivity at
my cafe until I could get back home to a wired network and issue an "ifup eth0"
command. The error "code=exited, status=1/FAILURE" reported by "service
NetworkManager restart" wasn't very helpful.

The real error seemed to be hiding in messages:
dbus-daemon: [system] Failed to activate service
'org.freedesktop.NetworkManager': timed out 
With this
ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-Auto_Linksys-guest ...
<warn> caught signal 11. Generating backtrace...

ESSID="Linksys-guest"
MODE=Managed
TYPE=Wireless
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
NAME="Auto Linksys-guest"
UUID=4d02ebf8-f969-4167-b427-b797ac7174ef
ONBOOT=yes
USERS=user

This was the first ifcfg file in an unsorted dir "ls -f" and typical.

yum downgrade should work, but I got dependency errors.

I solved it thus:
~ # rpm -e --nodeps NetworkManager-glib-0.8.999-3.git20110526.fc15.i686
~ # rpm -e --nodeps NetworkManager-gnome-0.8.999-3.git20110526.fc15.i686
~ # rpm -e --nodeps NetworkManager-0.8.999-3.git20110526.fc15.i686

~ # yum install NetworkManager-glib-0.8.999-2.git20110509.fc15.i686
NetworkManager-gnome-0.8.999-2.git20110509.fc15.i686
NetworkManager-0.8.999-2.git20110509.fc15.i686

~ # yum check

yum and rpm still have naming inconsistences making it tedious to copy and
paste package names between query results and commands.

When can we finally get a yum download and yum remove --nodeps command?

yum downgrade restores a working version. To avoid dependency problems:
  yum downgrade NetworkManager{,-gnome,-glib}

> Dear $deity, the Fedora NM situation is a mess (doubly so for KDE users...)

Well, the update which caused this regression fixes the issues we had with kde-plasma-networkmanagement (VPN was broken), which is why it ended up in stable so quickly. (It got a karma of +3 before even reaching testing (but the 3rd +1 came while the push was already underway, so it landed in testing anyway) and was already at +6 when it landed in stable.)

Unfortunately, since it chokes on VPN connection definitions, it doesn't fix these issues at all...

I know Bugzilla's not hte place to vent, and I know this has been rehashed about seventeen hundred times already - but I wasn't referring to this particular instance of a bug with the above (I'm perfectly capable of working around bugs), I was referring to the entire NetworkManager situation is Fedora. I truly believe that it would have been better to delay by another two weeks instead of inflicting such a mess in a fundamental system component on the users :(

Ah well. </rant>

> Unfortunately, since it chokes on VPN connection definitions, it doesn't fix
> these issues at all...

It chokes on systemwide VPN connection definitions (and some systemwide ifcfg definitions, too, which is what this bug is about). The current kde-plasma-networkmanagement in F15 doesn't support system connections at all. So this does not affect kde-plasma-networkmanagement. At least 3 people tested this with kde-plasma-networkmanagement and found it to fix their VPN, and 3 more people tested the NM update with no regressions (but apparently either did not have system connections at all or their system connections did not trigger the patch).

Oops, I mean:
… or their system connections did not trigger the BUG).

> It chokes on systemwide VPN connection definitions (and some systemwide ifcfg
definitions, too, which is what this bug is about).

Ahh... That aspect didn't occur to me. Thanks, will test moving the definitions to a user profile and return with the results.

Making them per-user inside NetworkManager won't help; for kde-plasma-networkmanagement to see the connections, they have to be set up within kde-plasma-networkmanagement in its internal storage.

Normally, all NetworkManager 0.9 clients should be storing all connections in systemwide storage (even per user ones), but kde-plasma-networkmanagement still uses a compatibility interface which allows passing connections internal to kde-plasma-networkmanagement to NetworkManager.

Also seeing this on two separate F15 laptops. Both have Enterprise WPA networks in their NM config if that's relevant.

*** This bug has been marked as a duplicate of bug 708445 ***