network manager frequently disconnects from secure networks in intrepid

[deactivated account]

Since switching to Intrepid I have been unable to keep the connection to a network.
This happens on both my desktop and my laptop. On the laptop, it occurs with both wired and wireless networking (the desktop only has wired).

The networks are secured. 802.1x, EAP-PEAP, MSCHAPV2.

The amount of time the network will stay connected varies, however it ranges from a minute or two, to 3 or 4 hours. Once I have been disconnected I have to disable and then re-enable networking with the network-manager applet in gnome.

Although I am saying that I am getting disconnected, because all applications lose their ability to access the network and incoming connections are informed that there is no route to host, the network-manager applet's icon does not change.

I will attach the wpa_supplicant.log file, since there is a repeating error in there that I think could be relevant. If I should provide other logfiles, please let me know.

[mathew Howell (mhowell3002)]

This bug also affects me as my University uses the same authentication method. I have had to revert back to Hardy as it remains stable on Hardy.

[deactivated account (iethah2du2so1eih-deactivatedaccount)]

It seems that little attention has been paid to this bug... I really don't want to see the same problem in Jaunty... it is bad enough in Intrepid, having to reconnect so often.
Can we expect it to be fixed by April?

[Steffan Harries (steffan-harries)]

This bug is also true with NetworkManager(0.70) though is much less frequently occuring. It has happened twice in the last month with me. Hopefully this bug will be fixed in either app before Jaunty!

[Rocko (rockorequin)]

What does lspci say about your wireless card? eg are you using an Intel 4965 ABN card and trying to connect to an 11n network?

Hardy didn't support 11n mode on these cards, but the iwlagn driver in Intrepid/Jaunty does, and it seems it has some problems with 11n networks.

If you are using iwlagn, you can try disabling 11n with:

sudo modprobe -r iwlagn && sudo modprobe iwlagn 11n_disable=1

To make it permanent, add 'options iwlagn 11n_disable=1' to /etc/modprobe.d/options.

[mathew Howell (mhowell3002)]

The connection I am trying is a wired connection which uses 802.1x authentication.
the adapter in lspci is;
Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)

It also seems to do the same in Jaunty after trying Alpha4.

[Rocko (rockorequin)]

Maybe the latest linux-backports-modules-2.6.28-11-generic in Jaunty might help. They have an updated wireless compatibility stack - now my iwlagn can connect to my work's 11n WPA network in 11n mode. Having said that, it also now frequently disconnects and reconnects just like in this bug.

[deactivated account (iethah2du2so1eih-deactivatedaccount)]

Haven't tested wireless in Jaunty RC yet, however the problem still exists for wired connections.
This really is a show-stopper in my opinion. Having one unusable release was bad enough, but two in succession is even worse!

Maybe somebody who knows more about these things than I do could see what changed between hardy and intrepid?

[Ernst (ernst-blaauw)]

I have a iwl3945 network card. At home, I have a WPA wireless network. M laptop runs Jaunty with backports installed and seems to connect stable.

However, at my university I have a WPA2/TTLS/PAP security. Here, the connection drops after about 10 minutes (can be shorter, can be much longer). However, the NetworkManager icon shows there is a connection.

Using wpa_supplicant (and disabling NM), I can make a stable connection. Therefore, I think this is not related to the package wpa_supplicant, but to NM: it is NM that can't establish a stable connection.

Please tell me if you need more info!

[deactivated account (iethah2du2so1eih-deactivatedaccount)]

Running wpa_supplicant with the -dd option results in the attached segfault (stack smashing detected).
However running it like this caused the problem almost immediately, which is different to usual, and more permanent.
This kind of problem was happening before, but not as often as the problem I usually have. Maybe this will speed things along a bit.

[deactivated account (iethah2du2so1eih-deactivatedaccount)]

I think that the last comment I made is part of a different bug, since using a single -d option rather than -dd does not die straight away.
I am currently keeping an eye on what does happen.

[Konstantin Thierbach (konstantin-phil)]

I am also affected by these bug in Intrepid with the kernel 2.6.28-11. Having an Intel 3945abg controller:
Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

This bug only affects me at the university network were they have several access points. I attached the daemon.log which shows that my computer seems to roam between the access points in very short time periods.

I had the same problem with ubuntu 8.04 (same laptop) were I didn't use the network manager, only using the wpa-supplicant.
So maybe the bug is in the network driver or wpa-supplicant.

The daemon.log also shows relations to the following bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760

[Ernst (ernst-blaauw)]

I can confirm the problematic network (at my university) has multiple access points, in contrary to the (not problematic) network at home.

[Rocko (rockorequin)]

I installed the vanilla 2.6.30-rc5 and now 2.6.30-rc6 kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc6/) in Jaunty and I no longer have the disconnection problems I was experiencing before with the 2.6.28 backports.

[mathew Howell (mhowell3002)]

I've just tried the 2.6.30-rc6 kernel on jaunty, and I still randomly lose the network connection, when using nm-applet or manually set in /etc/network/interfaces.

[emilio (emiliomaggio)]

I have got a similar problem.... same symptoms. Network manager icon is OK but there is no connection and I cannot ping any IP.

however my wpa_supplicat.log file shows a different error:

CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Associated with 00:17:3f:92:22:9b
CTRL-EVENT-SCAN-RESULTS
WPA: Key negotiation completed with 00:17:3f:92:22:9b [PTK=CCMP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:17:3f:92:22:9b completed (reauth) [id=0 id_str=]
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS

Is this the same bug or should I submit a new one?

[Jeremy Nickurak (nickurak)]

I've been having similar issues under jaunty and karmic. It's hard to tell if this is the same issue or an independant one.

I'm on a bcm4322 wireless chip with broadcom's wl driver. I frequently lose wireless connectivity, and nm-applet doesn't indicate it. As far as I can tell, this is always on a network with many access points, one or two of which are clearly the closest ones.

The system itself seems to be aware that it's lost its connection, as the logs indicate. It seems like the network roams from one AP to another, and gets disconnected, reconnects and authenticates, but doesn't run dhcp. Then, if I manually try to reconnect (by re-selecting the network in nm-applet, which already indicates it's connected) it fails to connect. The only reliable way I've found to correct is whenever the issue comes up, running:

sudo killall wpa_supplicant dhclient; sudo /etc/init.d/NetworkManager stop; sudo rmmod wl; sudo modprobe wl; sudo /etc/init.d/NetworkManager start.

I'm attaching a daemon.log with NetworkManager and wpa_supplicant messages.

[Jeremy Nickurak (nickurak)]

One indication that it's a network-manager problem is that (like many users) I'm trying wicd instead of network-manager. I've been up and running for almost 24 hours with no such disconnection problems.

[Jeremy Nickurak (nickurak)]

This is a year old, still affects karmic, and hasn't even had its importance decided.

Is there any updates on work to improve network-manager's reliability? The community at large just seems to recommend installing wicd instead... which isn't a great solution. (integrates poorly, doesn't provide the same dbus interface that other applications are dependent on, etc...)

[Andreas (andreas-kotowicz)]

the problem completely vanished for me on two different laptops once I installed http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-maverick/. I did some heavy stress test, downloading a couple GB of iso images and I get no more disconnects! previously I got disconnects after 200MB or so. Maybe this will work for other people too.

[Maarten Bezemer (veger)]

This bug report is being closed due to the last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.