nm-applet randomly(?) becomes non-responsive

Bug #153769 reported by Aaron on 2007-10-18
8
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: network-manager

running an up to date Gutsy (as of oct 17,2007)

for a wireless driver, I'm using ndiswrapper and networkmanager 0.6.5

NetworkManager and nm-applet work fine most of the time, but once in a while (about once a day over the last week) nm-applet will do this thing where it becomes totally non-responsive. I only notice it when I'm moving around at work and want to switch access points. The first symptom I usually notice is that the network list fails to update to show networks I know I should be seeing. Even after waiting up to 10 minutes for it to get around to it. Once I've seen that I know I'm in trouble but at that point the applet fails to respond to anything I do. Right clicking and left clicking still show their menus, but the options in them fail to elicit a response. I can disable wireless and wired networks and the checks clear but the icon doesnt go to the alert icon it normally would. I can select a different network but it doesn't even try to update them.

Now, I can sometimes recover from this by killing and restarting the nm-applet and NetworkManager applets, but not always. Sometimes it appears to recover and keeps trying to connect to a known networks, but just keeps asking for the key instead of connecting. Other times, it just acts as non-responsive as it did before.

I can always connect using iwconfig and dhclient when NetworkManager is acting up, which makes me pretty sure thats the problem is isolated to NetworkManager.

I'll have a syslog attachment up shortly.

Aaron (magicrobotmonkey) wrote :

heres my syslog from today. The time it started failing was around 2 pm. Then theres some stuff later from around 6 that was me trying to start it and get it to connect when I got home from work. The earlier stuff was after a clean boot without suspending, I suspended it on the way home, then tried the later stuff.

I did have one thought though, is it possible for laptop mode to mess with it? I have it enabled and when it stopped working was close to a time i plugged it in after having it unplugged for a while, though it wasn't the first time I unplugged it today.

Aaron (magicrobotmonkey) wrote :

one other clarification: I do use openvpn, but not through network-managers interface

Aaron (magicrobotmonkey) wrote :

heres the output of sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log

Aaron (magicrobotmonkey) wrote :

ok, hate to span, but as a developer myself i appreciate the value of details in a bug report.

So, I just rebooted to get everything clean. On boot i think I got the behaviour i just saw in another bug where it tries to connect to my ap, but just times out, then when i select it, it connects quickly. So that wasn't good, but i could deal with it.

Then I stopped NetworkManager using the S25NetworkManager script, and started it again with sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log, expecting it to work. But it didnt. Instead it did the thing where it tries to connect, but then just keeps asking for a key, even though it already knows it. Attached is the output into nm.log

Alexander Sack (asac) wrote :
Changed in network-manager:
importance: Undecided → Medium
status: New → Incomplete
Aaron (magicrobotmonkey) wrote :

Ok, I installed them and started network manager. At first it didnt look good, it just kept trying to connect to my WEP'ed network without even asking me, so i connected to a neighbors unsecure AP and that connect right away so swicthed back to mine and it connected quickly. So it seems good so far. I wont be back in the office to test my heavy usage there till monday though.

dot_j (dot-j) wrote :

I had exactly the same problem that Aaron outlined, so he pointed me to the test packages.

I tried connecting to both:
An open network that had no signal strength and
A closed network that had good signal strength.

Before the test packages, after trying both, I was unable to reconnect to my network after (expectedly) not being able to connect to those and had to restart.

After installing the test packages, I was able to reconnect just fine.

For the record, I'm running and up-to-date Gutsy install on a MacBook Pro using the ath_pci driver.

Ryan (rc+launchpad) wrote :

I have also experienced the same problems. I just installed the packages Alexander pointed to, so hopefully that will fix things.

Ryan (rc+launchpad) wrote :

After a few days testing with many suspends/resumes and moving around to different AP's, this particular issue seems to be fixed with Alexander's packages.

Aaron (magicrobotmonkey) wrote :

Yea after using those packages for a week or so now, I have to say they are rock solid. I don't know what you did, Alexander, but its good to see network-manager working like it *should*

GregR1 (bluepowder7) wrote :

which exact package am i supposed to install?
the network-manager-dev_065 or the normal network-manager_065? what about the lib..... files? i tried the normal, and the installer wouldn't budge since apparently i have a newer version already.

Ryan (rc+launchpad) wrote :

You only need the packages without the -dev.

Just as a side note, I was also affected by another bug (I forget which number) in either nm or wpasupplicant (I believe it's the latter but I could be wrong) which caused enormous delays waiting to scan and then connect to APs. I have since "downgraded" to the Feisty packages for libnm-glib0, libnm-util0, network-manager, network-manager-gnome, wpasupplicant (not sure all needed downgrading...) and everything works again. Something broke in Gutsy and it _really_ annoyed me until I installed the Feisty packages. No more problems. I'm not going to "upgrade" nm or wpasupplicant again unless there's a compelling reason or I can be assured that it will work the same as or better than the Feisty packages.

Ryan,

Thanks for the clarification. How did you manage to get them
installed, though? Last time I tried it, the installer didn't install
since it detected that I already have the same (or a more recent)
version installed. I'm not sure if it's safe to first uninstall the
network manager and then reinstall the .deb package (which I can
download ahead of time and store on my desktop). Would all the
dependencies be contained in that .deb file?

Also, how did you downgrade? What are the steps for that and where
would I get the various packages for it? I'm a bit of a novice when
it comes to linux.

Thanks!
Greg

On Nov 27, 2007 1:05 AM, Ryan <email address hidden> wrote:
> You only need the packages without the -dev.
>
> Just as a side note, I was also affected by another bug (I forget which
> number) in either nm or wpasupplicant (I believe it's the latter but I
> could be wrong) which caused enormous delays waiting to scan and then
> connect to APs. I have since "downgraded" to the Feisty packages for
> libnm-glib0, libnm-util0, network-manager, network-manager-gnome,
> wpasupplicant (not sure all needed downgrading...) and everything works
> again. Something broke in Gutsy and it _really_ annoyed me until I
> installed the Feisty packages. No more problems. I'm not going to
> "upgrade" nm or wpasupplicant again unless there's a compelling reason
> or I can be assured that it will work the same as or better than the
> Feisty packages.
>
>
> --
> nm-applet randomly(?) becomes non-responsive
> https://bugs.launchpad.net/bugs/153769
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Greg R.

Brian Murray (brian-murray) wrote :

Based on the various responses to the effectiveness of the PPA package I am setting the status of the bug report to Fix Committed.

Changed in network-manager:
status: Incomplete → Fix Committed
Aaron (magicrobotmonkey) wrote :

cool, so does that mean we can look for them as updates soon?

Alexander Sack (asac) wrote :

should be fixed by now.

Changed in network-manager:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers