network-manager regularly loses connection

[Mario Vukelic]

Binary package hint: network-manager

My laptop's WLAN uses the ipw3945 module, lspci reports it as "10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)"

In both Edgy and Feisty, network-manager regularly loses the connection to my Linksys WRT54GC access point, which is very close by and is usually reported with a signal strength of 87% by nm-applet. Dropping the connection happens several times per day. It does not seem to depend on whether I do anything or just let the laptop sit there idling. I figure that the case might be a background scan by network-manager.

The symptoms:
* nm-applet's icon suddenly changes from "connected" to scanning. CTRL-EVENT-DISCONNECTED is written to /var/log/daemon.log
* Sometimes the connection is picked up again without intervention, at other times it just scans for a minute or two, then gives up and displays "no connection"
* Sometimes once "no connection" is displayed, my access point is missing from nm-applet's access point list
* Even if the access point is still in the list, it usually does not help to reselect it. network-manager will scan, but give up in the end without a new connection
* Sometimes when the connection is dropped, a dialog will pop up, requesting the WPA key again (which it already should know). Supplying it does not help with regaining a connection

At this point I either have to:
* Pull the power from the access point, wait a few seconds, and then plug in again. After that, I can reselect my access point from nm-applet's list (if it is still there) and it will reconnect
* Alternatively I can kill NetworkManager, NetworkManagerDispatcher, and nm-applet. Then start NetworkManager and nm-applet again. This will also reconnect, and it will also make my access point show up in the list in case it was gone before

I am not sure if this is a duplicate of Bug #92629

I will attach /var/log/daemon.log. Let me know if I shall try anything to debug

[Mario Vukelic (kreuzsakra)]

Atttaching /var/log/daemon.log

Examples:

At time stamp Mar 17 10:12:34, it loses the connection completely. After that I try to connect to another access point by manually picking it from the nm-applet list

At time stamp Mar 17 13:16:25 , it loses the connection but immediately rescans and finds it again

[Mario Vukelic (kreuzsakra)]

Just FYI, I have this very rarely now, maybe once very few days, if at all. Maybe it was fixed by one of the updates. Nothing changed at my setup otherwise.

[smidl (vasek-smidl)]

I also see this problem.

The NetworkManager daemon tries to reconnect but somehow it fails.
In order to recover, I must manually restart the daemon. Sometimes it takes two manual stop/start cycles to get my connection back. After that it runs fine.

Daemon log attached.
Note the last line: CTRL-EVENT-TERMINATING - signal 15 received

[Alexander Sack (asac)]

please try if unsetting essid with iwconfig manually before attempting to connect using network-manager helps.

Thanks,

 - Alexander

[smidl (vasek-smidl)]

Hi Alexander,
thanks for suggestion. I hope I understand it correctly...
When the connection was lost, I manually changed essid and tried to
reconnect to the correct network using network-manager. It was
successfull. So far, no other loss of connection.
Does it help?
Vasek

On 8/14/07, Alexander Sack <email address hidden> wrote:
> please try if unsetting essid with iwconfig manually before attempting
> to connect using network-manager helps.
>
> Thanks,
>
> - Alexander
>
> ** Changed in: network-manager (Ubuntu)
> Status: New => Incomplete
>
> --
> network-manager regularly loses connection
> https://bugs.launchpad.net/bugs/93062
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Mario Vukelic (kreuzsakra)]

I did a quick try too, when it lost connection (which, BTW, still happens every 2nd day or so, in Gutsy), but I didn't have enough time yet to be sure how much it helped. I ran "sudo iwconfig eth2 essid off" after losing connection, then tried to reconnected by picking my WLAN from the nm-applet list.

At first I was happy since it seemed to reconnect immediately, but it re-lost connection just as quickly. I ran the cmd line again, but now reconnecting did not work. I tried a few more times, and it happened again that it reconnected but lost connection again immediately.

I will try some more when I have time.

[smidl (vasek-smidl)]

Same behaviour here. It worked fine for the first time, but when I
lost connection again it did not work anymore...

In fact, I have about 1MB syslog file with most entries from
NetworManager. Is it worth submitting somewhere? Or is there any
specific message I should look for? There are quite a few lines
containing keywords: Error, DISCONNECTED, timeout, etc.

On 8/15/07, Mario Vukelic <email address hidden> wrote:
> I did a quick try too, when it lost connection (which, BTW, still
> happens every 2nd day or so, in Gutsy), but I didn't have enough time
> yet to be sure how much it helped. I ran "sudo iwconfig eth2 essid off"
> after losing connection, then tried to reconnected by picking my WLAN
> from the nm-applet list.
>
> At first I was happy since it seemed to reconnect immediately, but it
> re-lost connection just as quickly. I ran the cmd line again, but now
> reconnecting did not work. I tried a few more times, and it happened
> again that it reconnected but lost connection again immediately.
>
> I will try some more when I have time.
>
> --
> network-manager regularly loses connection
> https://bugs.launchpad.net/bugs/93062
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Mario Vukelic (kreuzsakra)]

I have tried some more. This morning I was again greeted with the window asking for the WLAN password. I cancelled it, then ran the iwconfig command again and tried to connect. As last time, it actually did, but lost connection again after 1 sec. This is definitely new behavior for me, and I think only occurs after executing the command.

Then I tried to connect again (without doing anything else), but it failed. I repeated that once or twice with the same result. Then I ran the iwconfig command again (dunno if it makes sense to run it more than once), and again a connection would come and go. Another try, and the connection worked.

[Mario Vukelic (kreuzsakra)]

I am now pretty sure that the frequency of losing connection is unpredictable. I don't write "random" on purpose, because it may be that I am losing connection due to outside influences. I recently booted into Windows, and lost connection all the time, much more frequently than I usually do in Gutsy. The difference was that Windows immediately reconnected, and had I not been forced to use a Cisco VPN connection, I might not even have noticed. The VPN had to be renegotiated every time, though.

The only reliable method to immediately reconnect in Ubuntu is to "sudo killall NetworkManager NetworkManagerDispatcher nm-applet", then unplug the WLAN access point, replug, then "sudo NetworkManager && nm-applet&". This unfortunately leaves 2 nm-applets in the session, but --sm-disable might prevent this if I understand it correctly. Didn't have a chance to try yet tough, didn't drop off yet.

[Alexander Sack (asac)]

can you test latest gutsy please (maybe use the daily livecd).

Thanks,

 - Alexander

[Mario Vukelic (kreuzsakra)]

Just to let you know a preliminary result with the latest Gutsy updates. Overall, my gut feeling is that is was more stable than ever. However, I had to reboot twice, and I cannot yet say whether it would ever have stayed stable for more than two days. I also had one lost connection, and so the jury is still out. Here come the details:

I had installed the update on the day when you asked to test latest Gutsy, and I rebooted:

Thu, Sep 20 2007 22:56:14 +0200
[UPGRADE] network-manager 0.6.5-0ubuntu11 -> 0.6.5-0ubuntu12
[UPGRADE] network-manager-gnome 0.6.5-0ubuntu8 -> 0.6.5-0ubuntu9

The connection was stable for two days. This was pretty long for me, but not something I have never seen before. Then I had to reboot. Upon login, NM reconnected. That was nice, since that has (nearly? I forgot) never worked before, when rebooting I always had to unplug the access point while the PC was down.

Unfortunately, a day later I lost connection again, was asked for the WPA key, yada yada. After doing as needed, the connection stayed stable. I think it was then that another update came, so I installed and rebooted:

Mon, Sep 24 2007 22:40:40 +0200
[UPGRADE] network-manager 0.6.5-0ubuntu13 -> 0.6.5-0ubuntu14

Since then it was stable for 2 days, until I had to reboot yesterday. Yesterday evening an update to wpa-supplicant came in, which I installed. Not rebooted yet:

Tue, Sep 25 2007 19:48:55 +0200
[UPGRADE] wpasupplicant 0.6.0-3 -> 0.6.0+0.5.8-0ubuntu1

[Mario Vukelic (kreuzsakra)]

I had time for a reboot. Result: same as usual. After logging in, the WPA key windows came up very soon. After trying everything again as before, I had to settle for killing all NM-related stuff, restarting the access point, and starting NM. Then the login worked, as expected.

I'll let you know how long it stays connected.

[Matthew Caron (matt-mattcaron)]

I see this same issue with an Atheros chipset card.

Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

[Mario Vukelic (kreuzsakra)]

Last night I lost connection again while the computer was idle. In the morning I was greeted by the WPA key dialog. Thus, it had stayed connected for roughly two days -- this is not significantly better that it was lately. I canceled the key dialog, upon which the nm-applet icon changed to "no connection", as usual.

I tried a few things with the usual result, but which I haven't described so far:

* I tried to reconnect by picking my access point from the list, but it was not in there.
* I restarted the access point, upon which it showed up in nm-applet's list again, after waiting for a minute or so. When selecting it, nm-applet tried to connect, but of course got stuck. It always does so with the bottom "LED" (or whatever the icon is supposed to signify) being green, the upper one staying gray.

After a few minutes of this I killed the NM stuff, restarted access point and the NM stuff -- instant connect, as usual.

[Mario Vukelic (kreuzsakra)]

I had another reboot today, and it reconnected. Pretty unpredictable, this.

[Mario Vukelic (kreuzsakra)]

I just lost and automatically regained connection. /var/log/daemon.log of the event is attached.

[Mario Vukelic (kreuzsakra)]

Connection was lost at around 1:36, and a key dialog was displayed. From the log it seems as if connection was at first briefly regained without the "need" for a new key, but then NM hanged its opinion. Log is attached.

[Mario Vukelic (kreuzsakra)]

I was continually connected for a record 8 days. Very cool, thanks to everyone involved.

Just now, suddenly I lost connection, and then NM used 100% CPU of one core.. It never did this before, and so I am not sure if this is a different issue and whether I shall file a separate report.

Looking at the log, I don't think so, though. The log from the last few days is attached. There is a curious part in there, right when it lost connection. I don't think it should disconnect from an existing connection because it found a better version of that very same connection, which it then fails to reestablish:

Oct 10 19:14:09 chronic NetworkManager: <info> eth2: link timed out.
Oct 10 19:14:09 chronic NetworkManager: <info> SWITCH: found better connection 'eth2/kleinehoelle' than current connection 'eth2/kleinehoelle'. same_ssid=1, have_link=0
Oct 10 19:14:09 chronic NetworkManager: <info> Will activate connection 'eth2/kleinehoelle'.
Oct 10 19:14:09 chronic NetworkManager: <info> Device eth2 activation scheduled...
Oct 10 19:14:09 chronic NetworkManager: <info> Deactivating device eth2.
Oct 10 19:14:10 chronic dhclient: There is already a pid file /var/run/dhclient.eth2.pid with pid 7345
Oct 10 19:14:10 chronic dhclient: killed old client process, removed PID file
Oct 10 19:14:10 chronic dhclient: DHCPRELEASE on eth2 to 192.168.1.1 port 67
Oct 10 19:14:10 chronic avahi-daemon[6328]: Withdrawing address record for 192.168.1.101 on eth2.
Oct 10 19:14:10 chronic avahi-daemon[6328]: Leaving mDNS multicast group on interface eth2.IPv4 with address 192.168.1.101.
Oct 10 19:14:10 chronic avahi-daemon[6328]: Interface eth2.IPv4 no longer relevant for mDNS.
Oct 10 19:14:10 chronic NetworkManager: <info> SUP: sending command 'DISABLE_NETWORK 0'
Oct 10 19:14:22 chronic NetworkManager: <info> SUP: response was 'TIMEOUT[CLI]'

Then the log is busy with NM doing stuff, probably trying to reestablish, which ends with a severe error:

Oct 10 19:14:47 chronic NetworkManager: ******************* START **********************************
Oct 10 19:14:47 chronic NetworkManager: (no debugging symbols found)
Oct 10 19:14:47 chronic NetworkManager: Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Oct 10 19:14:47 chronic NetworkManager: (no debugging symbols found)
Oct 10 19:14:48 chronic last message repeated 12 times
Oct 10 19:14:48 chronic NetworkManager: [Thread debugging using libthread_db enabled]
Oct 10 19:14:48 chronic NetworkManager: [New Thread -1212520784 (LWP 7332)]
Oct 10 19:14:48 chronic NetworkManager: [New Thread -1229309040 (LWP 7344)]
Oct 10 19:14:48 chronic NetworkManager: [New Thread -1220916336 (LWP 7337)]
Oct 10 19:14:48 chronic NetworkManager: [New Thread -1212523632 (LWP 7334)]
Oct 10 19:14:48 chronic NetworkManager: (no debugging symbols found)
Oct 10 19:14:48 chronic last message repeated 4 times
Oct 10 19:14:48 chronic NetworkManager: 0xffffe410 in __kernel_vsyscall ()
Oct 10 19:14:48 chronic NetworkManager: ******************* END **********************************

Apport did not come up, and I rebooted . After logging in again, NM did not reestablish and showed the WPA key dialog. Then I had to perform the u...

[Alexander Sack (asac)]

Mario Vukelic , the issue you now see is something else. Look bug 145683.

Please test the network-manager 0.6.5-0ubuntu16~ppa1 from http://ppa.launchpad.net/asac/ubuntu/pool/main/n/network-manager/ and drop your findings to the bug named above.

This one (ipw3945 association behaviour) was fixed a while back.

Thanks,
 - Alexander

[Mario Vukelic (kreuzsakra)]

Will do, thanks.

[Mario Vukelic (kreuzsakra)]

I'm running network-manager 0.6.5-0ubuntu16~ppa1 now and lost connection with the usual symptoms, but no crash:

Oct 14 16:54:48 chronic NetworkManager: <info> SWITCH: found better connection 'eth2/kleinehoelle' than current connection 'eth2/kleinehoelle'. same_ssid=1, have_link=0

Relevant daemon.log attached.

[mspanc (mspanc)]

Hi, I have very similar problem with bcm43xx wifi. My network-manager randomly drops connection and can't connect again. When I choose my AP manually from the list, only bottom point is green, and after long time it asks me about password. Sometimes rmmod bcm43xx and loading module again helps, but the best solution is to reboot my laptop. I have fully updated ubuntu 7.10. I attach syslog.