Bug 771130

Summary: NetworkManager randomly disconnects wireless lan
Product: [Fedora] Fedora Reporter: ell1e <kittens>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 16CC: danw, dcbw, jbastian, jklimes, juanfr, loganjerry, thomas, tore, zaitcev
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-19 21:20:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description ell1e 2012-01-01 18:58:25 UTC
Description of problem:
A wireless connection in an environment that used to be fine for use (also with distance, walls between access point etc) gets now randomly and aggressively disconnected by NetworkManager since a recent system update.

Needless to say, this bug can hugely delay work and is very disruptive.

Version-Release number of selected component (if applicable):
0.9.2-1.fc16

How reproducible:
Always

Steps to Reproduce:
1. Put a wireless network on autoconnect
2. Watch the following steps happen:
    a. NetworkManager attempts to connect to the network
    b. NetworkManager succeeds and notifies "Connection Established  You are now connected to the wireless network 'ssid'."
    c. A seemingly arbitrary amount of time passes, often only a fracture of a second, but sometimes it holds for a minute or longer, allowing a very short time of internet browsing or whatever
    d. NetworkManager notifies "Connection failed   Activation of network connection failed" out of nothing and the connection is gone
    e. repeat from a

Actual results:
The above cycle happens sometimes when c. is very short in a fast cycle of a few seconds constantly, then sometimes coming to a temporary stop and allowing the connection for a minute or so. Also it seems when waiting a longer time (15-20 minutes), it seems to stabilize and stop to disconnect even for hours and just work fine.

Expected results:
NetworkManager doesn't disconnect.

Additional info:
uname -a: Linux jth 3.1.6-1.fc16.i686.PAE #1 SMP Wed Dec 21 23:01:09 UTC 2011 i686 i686 i386 GNU/Linux

Comment 1 ell1e 2012-01-05 15:24:44 UTC
If noone appears to be looking into this soon, I'll have to move to another distribution. While a lot of other small problems Fedora at times had or still has for me, this one is so extremely annoying that I cannot really work with it.

Comment 2 ell1e 2012-01-05 15:27:45 UTC
dmesg output:

[ 1119.096515] wlan0: authenticate with c0:25:06:54:f6:a5 (try 1)
[ 1119.098135] wlan0: authenticated
[ 1119.100899] wlan0: associate with c0:25:06:54:f6:a5 (try 1)
[ 1119.104495] wlan0: RX ReassocResp from c0:25:06:54:f6:a5 (capab=0x431 status=0 aid=1)
[ 1119.104507] wlan0: associated
[ 1119.104517] wlan0: No basic rates in AssocResp. Using min supported rate instead.
[ 1119.109371] cfg80211: Calling CRDA for country: DE
[ 1119.215118] cfg80211: Regulatory domain changed to country: DE
[ 1119.215129] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1119.215140] cfg80211:     (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1119.215149] cfg80211:     (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1119.215157] cfg80211:     (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1119.215166] cfg80211:     (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
[ 1133.801469] wlan0: deauthenticating from c0:25:06:54:f6:a5 by local choice (reason=3)
[ 1133.821505] cfg80211: Calling CRDA to update world regulatory domain
[ 1133.943238] cfg80211: World regulatory domain updated:
[ 1133.943249] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1133.943260] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1133.943269] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1133.943277] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1133.943286] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1133.943295] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1133.943350] cfg80211: Calling CRDA for country: BE
[ 1133.968529] cfg80211: Regulatory domain changed to country: BE
[ 1133.968540] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1133.968551] cfg80211:     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1133.968560] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1133.968568] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1133.968576] cfg80211:     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[ 1138.205979] wlan0: authenticate with c0:25:06:54:f6:a5 (try 1)
[ 1138.207610] wlan0: authenticated
[ 1138.208393] wlan0: associate with c0:25:06:54:f6:a5 (try 1)
[ 1138.214263] wlan0: RX ReassocResp from c0:25:06:54:f6:a5 (capab=0x431 status=0 aid=1)
[ 1138.214276] wlan0: associated
[ 1138.214287] wlan0: No basic rates in AssocResp. Using min supported rate instead.
[ 1138.219087] cfg80211: Calling CRDA for country: DE
[ 1138.441977] cfg80211: Regulatory domain changed to country: DE
[ 1138.441989] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1138.442000] cfg80211:     (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1138.442054] cfg80211:     (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1138.442063] cfg80211:     (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1138.442071] cfg80211:     (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)

Comment 3 ell1e 2012-01-09 17:10:11 UTC
This also happens with 2m to the access point with 100% signal when it never happened before. The connection works perfectly fine a few seconds with web pages loading and everything until NetworkManager cuts it off in the middle. I guess it couldn't be more obvious this isn't a signal/connection strength problem. Is there a chance someone will look into this?

Comment 4 Jirka Klimes 2012-01-12 12:20:35 UTC
This looks like a kernel driver problem. There are/were some reports in the bugzilla about similar problems.

However, we need more information to find out what's going on.

1. What WiFi card and driver do you use?
 $ lspci -vvnn | grep -A 15 Network 
 $ nmcli -f general dev list iface wlan0
2. kernel version
  $ rpm -q kernel
3. attach /var/log/messages file

For further debugging, this is useful http://live.gnome.org/NetworkManager/Debugging#wifi, mainly wpa_supplicant logs.

Comment 5 ell1e 2012-01-13 18:20:19 UTC
# lspci -vvnn | grep -A 15 Network
01:00.0 Network controller [0280]: Ralink corp. RT2860 [1814:0781]
	Subsystem: Ralink corp. Device [1814:2790]
	Physical Slot: eeepc-wifi
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 19
	Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
	Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-

# nmcli -f general dev list iface wlan0
GENERAL.DEVICE:                         wlan0
GENERAL.TYPE:                           802-11-wireless
GENERAL.DRIVER:                         rt2800pci
GENERAL.HWADDR:                         <is that the Mac address here? probably better if I remove it then I guess>
GENERAL.STATE:                          connected

# rpm -q kernel
kernel-3.1.5-6.fc16.i686
kernel-3.1.6-1.fc16.i686
kernel-3.1.7-1.fc16.i686

# cat /var/log/messages | tail -n 60
Jan 13 19:07:50 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) complete.
Jan 13 19:07:50 jth NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started...
Jan 13 19:07:50 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started...
Jan 13 19:07:50 jth avahi-daemon[946]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.178.23.
Jan 13 19:07:50 jth avahi-daemon[946]: New relevant interface wlan0.IPv4 for mDNS.
Jan 13 19:07:50 jth avahi-daemon[946]: Registering new address record for 192.168.178.23 on wlan0.IPv4.
Jan 13 19:07:50 jth dhclient[7536]: RCV: Reply message on wlan0 from fe80::c225:6ff:fe54:f6a3.
Jan 13 19:07:50 jth NetworkManager[945]: RCV: Reply message on wlan0 from fe80::c225:6ff:fe54:f6a3.
Jan 13 19:07:50 jth NetworkManager[945]: PRC: Done.
Jan 13 19:07:52 jth NetworkManager[945]: <info> (wlan0): device state change: ip-config -> activated (reason 'none') [70 100 0]
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> (wlan0): device state change: ip-config -> activated (reason 'none') [70 100 0]
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv4 routing and DNS.
Jan 13 19:07:52 jth NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv4 routing and DNS.
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <warn> Failed to add route Netlink Error (errno = Invalid argument)
Jan 13 19:07:52 jth NetworkManager[945]: <warn> Failed to add route Netlink Error (errno = Invalid argument)
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <error> [1326478072.136522] [nm-system.c:1061] nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default route: -1
Jan 13 19:07:52 jth NetworkManager[945]: <error> [1326478072.136522] [nm-system.c:1061] nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default route: -1
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv6 routing and DNS.
Jan 13 19:07:52 jth NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv6 routing and DNS.
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) successful, device activated.
Jan 13 19:07:52 jth NetworkManager[945]: <info> Activation (wlan0) successful, device activated.
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
Jan 13 19:07:52 jth NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> (wlan0): DHCPv6 client pid 7536 exited with status 0
Jan 13 19:07:52 jth NetworkManager[945]: <info> (wlan0): DHCPv6 client pid 7536 exited with status 0
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info> (wlan0): DHCPv6 state changed end -> renew6
Jan 13 19:07:52 jth NetworkManager[945]: <info> (wlan0): DHCPv6 state changed end -> renew6
Jan 13 19:07:52 jth NetworkManager[945]: NetworkManager[945]: <info>   nameserver 'fd00::c225:6ff:fe54:f6a3'
Jan 13 19:07:52 jth NetworkManager[945]: <info>   nameserver 'fd00::c225:6ff:fe54:f6a3'
Jan 13 19:07:52 jth avahi-daemon[946]: Withdrawing address record for fd00::222:43ff:fe24:e18b on wlan0.
Jan 13 19:07:52 jth avahi-daemon[946]: Registering new address record for fe80::222:43ff:fe24:e18b on wlan0.*.
Jan 13 19:07:53 jth NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv4 routing and DNS.
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv4 routing and DNS.
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) scheduled...
Jan 13 19:07:53 jth NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) scheduled...
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) started...
Jan 13 19:07:53 jth NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) started...
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info>   nameserver 'fd00::c225:6ff:fe54:f6a3'
Jan 13 19:07:53 jth NetworkManager[945]: <info>   nameserver 'fd00::c225:6ff:fe54:f6a3'
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
Jan 13 19:07:53 jth NetworkManager[945]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jan 13 19:07:53 jth NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) complete.
Jan 13 19:07:53 jth NetworkManager[945]: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) complete.
Jan 13 19:07:53 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started...
Jan 13 19:07:53 jth NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started...
Jan 13 19:07:53 jth ntpd[7166]: Listen normally on 22 wlan0 192.168.178.23 UDP 123
Jan 13 19:07:53 jth ntpd[7166]: Listen normally on 23 wlan0 fe80::222:43ff:fe24:e18b UDP 123
Jan 13 19:07:53 jth ntpd[7166]: peers refreshed
Jan 13 19:07:54 jth NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv4 routing and DNS.
Jan 13 19:07:54 jth NetworkManager[945]: NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv4 routing and DNS.
Jan 13 19:07:54 jth NetworkManager[945]: NetworkManager[945]: <warn> Failed to add route Netlink Error (errno = Invalid argument)
Jan 13 19:07:54 jth NetworkManager[945]: <warn> Failed to add route Netlink Error (errno = Invalid argument)
Jan 13 19:07:54 jth NetworkManager[945]: <error> [1326478074.196541] [nm-system.c:1061] nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default route: -1
Jan 13 19:07:54 jth NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv6 routing and DNS.
Jan 13 19:07:54 jth NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
Jan 13 19:07:54 jth NetworkManager[945]: NetworkManager[945]: <error> [1326478074.196541] [nm-system.c:1061] nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default route: -1
Jan 13 19:07:54 jth NetworkManager[945]: NetworkManager[945]: <info> Policy set 'Auto Mantis religiosa' (wlan0) as default for IPv6 routing and DNS.
Jan 13 19:07:54 jth NetworkManager[945]: NetworkManager[945]: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.

I am not skilled in interpreting such logs, but to me it seems to look like NetworkManager trashes itself over IPv6.

Indeed now after setting the "IPv6 settings" to ignore while the problem was occuring badly, it seems to have vanished. Will report if issue starts to reappear with IPv6 disabled, but so far it's gone.

Since it hasn't been that long ago when I enabled it (it seemed to work fine in that particular moment when I did so), it might also have been at that point that the bug started occuring and it's probably not even a regression.

Comment 6 Jerry James 2012-01-26 18:15:57 UTC
This started happening to me recently on a *wired* connection, although I'm just getting around to tracking it down today.  It is occurring on a Rawhide virtual machine (I have both x86_64 and i686 variants, but they have identical virtual hardware, and I see the problem on both).  The Ethernet card uses the virtio driver.  The virtual network card is connected to a bridge on the host, which is running Fedora 16.

Like Jonas, I see the network appear to function normally in between fits of reconfiguring IPv6.

I suggest changing the bug description to "NetworkManager randomly disconnects IPv6", or something of the sort.

I wish I had made a note of the first time I saw this happen.  I see that NetworkManager was updated on Jan 20, but I don't recall if that is when it started happening or not.  In any case, it has only been a few days.

Comment 7 Jerry James 2012-02-22 19:59:33 UTC
Starting with yesterday's Rawhide update to NetworkManager-0.9.3-0.2.git20120215.fc17.x86_64 / i686, this is now happening every 2-3 seconds, constantly.  There are never any longer pauses during which networking is usable, like there used to be.  Can I provide any more information to help track this down?

Comment 8 Tore Anderson 2012-02-29 16:31:04 UTC
I believe bug #797524 and this one (Jonas' issue, to be precise) might be the same bug.

Tore

Comment 9 Jeff Bastian 2012-03-01 17:17:44 UTC
I'm seeing this on my T60 after upgrading to F17 Alpha last night.  Setting IPv6 to ignore for my wireless connection fixed the problem for me.

IPv6 works fine, though, for the wired connection.  (I have an IPv6 tunnel on another system running radvd.)

I have the following installed:
kernel-3.3.0-0.rc4.git1.4.fc17.x86_64
NetworkManager-0.9.3-0.2.git20120215.fc17.x86_64

And the T60 has:
03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4227] (rev 02)
	Subsystem: Intel Corporation Device [8086:1010]
	Physical Slot: 3
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 47
	Region 0: Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: iwl3945

Comment 10 Jeff Bastian 2012-03-02 13:33:01 UTC
Curiously, IPv6 still works even though I set the wireless to Ignore IPv6.

$ ip a l wlan0 | grep inet6
    inet6 2001:470:1f0f:46d:21b:77ff:fea4:25b/64 scope global dynamic 
    inet6 fe80::21b:77ff:fea4:25b/64 scope link
 
$ ping6 -c 1 ipv6.google.com
PING ipv6.google.com(2607:f8b0:4000:801::1012) 56 data bytes
64 bytes from 2607:f8b0:4000:801::1012: icmp_seq=1 ttl=53 time=135 ms

--- ipv6.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 135.410/135.410/135.410/0.000 ms

Comment 11 Pete Zaitcev 2012-03-23 02:13:46 UTC
I have Jerry's problem:
 - normal Ethernet
 - NM randomly cycles, throws pop-ups and resets the eth0
 "Activation of network connection failed"
 - F16, not rawhide

This happened after a run of "yum update" and reboot, but NM itself
was not updated [sic]. It's some other package.

NetworkManager-0.9.2-1.fc16.x86_64 (not updated)
nscd-2.14.90-24.fc16.6.x86_64 (also not updated)
iproute-2.6.39-4.fc16.x86_64 (not updated)
kernel-3.3.0-4.fc16.x86_64 (updated, but... hmm)

I could live without wireless, but living without IPv6 is extremely
inconvenient.

Comment 12 Juan Francisco Fernández 2012-04-01 14:01:19 UTC
Same here on two different computers. I only geting the error on WLAN, with ethernet I have no probs.

My card:

02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
	Subsystem: Intel Corporation WiFi Link 5100 AGN
	Physical Slot: 1
	Flags: bus master, fast devsel, latency 0, IRQ 47
	Memory at d8700000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Comment 13 Juan Francisco Fernández 2012-04-01 14:11:53 UTC
Ah forgot to say that the IPv6 workaound fixed the problem!

Comment 14 Dan Winship 2012-04-19 21:20:58 UTC
NM is handling IPv6 routes in a way that the kernel doesn't like, leading to problems later on. Fixed soon.

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