Wicd can't connect, stalls on "Disconnecting active connections"

Bug #438402 reported by dlanod on 2009-09-28
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
wicd
Undecided
Unassigned
Nominated for 1.7 by Phillip Merensky

Bug Description

In the last week Wicd has ceased being able to connect to my wireless (802.11g) network. It had worked previously for over a year. It used to automatically connect on log in but now it doesn't. When I open the Wicd applet my chosen network is present and has the "Automatically connect to this network" checkbox selected for it.

When I select "Connect" for this network, it starts the process, gets to the "Disconnecting active connections..." step and remains there indefinitely, though the applet does not hang. I can quit the applet, re-open it and try again and the same occurs.

I've attempted switching off DHCP on to static IP addresses and changing the channel my network was on (as I noticed one of my inconsiderate neighbours decided to start their's up on the same channel in my attempts to get this working) with no luck.

I've attached the log file.

Version: 1.6.2.2
Distro: Ubuntu 8.04

dlanod (donald-shepherd) wrote :
georgenewton (george-newton) wrote :

I have the same problem on a Dell Inspiron 6000 running Ubuntu 9.10.

wicd doesn't connect automatically on startup, despite "automatically connect" being checked.
wicd stalls at "disconnecting active connections" when I click connect.

georgenewton (george-newton) wrote :

correction: ubuntu 9.04. I'm not posting from the future.

Dan O'Reilly (oreilldf) wrote :

@dlanod, can you open wicd-client from a terminal window and post any error you get when you click connect? I don't see any errors in wicd.log.

@georgenewton, can you please do the same, and also enable debug mode in the preferences window before clicking connect, and attach /var/log/wicd/wicd.log here afterward? You can disable debug mode afterward as well.

Changed in wicd:
status: New → Incomplete
Kortatu (kortatu-gmail) wrote :

The same happens to my DELL Latitude D530 recently. I've launched wicd-client from a terminal window and no error is logged there. I've enabled debug mode in preferences, and It seems that te applications stalls in an infinete loop. I've attached my log file

dlanod (donald-shepherd) wrote :

Terminal output:

dlanod@thunderstorm:/media/ACER/Users/dlanod/Documents/Downloads/Season 2$ wicd-client
Has notifications support True
Loading...
Connecting to daemon...
Connected.
Done loading.
/usr/share/wicd/wicd/gui.py:151: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed
  self.wTree = gtk.glade.XML(gladefile)
refreshing...
refreshing...
ESSID : 21337
ESSID : bushturkey
ESSID : 21337
ESSID : bushturkey

I'm also attaching the wicd.log in debug mode. I'm getting similar messages to Kortatu.

oofnik (oofnik) wrote :

I've encountered the same problem using two different D-link routers after upgrading to 1.6.2.2 on Ubuntu 8.04. Wireless card is Intel 3945. Router 1 model is recent, DIR-655+, the other is older, DI-524. Wicd won't connect and freezes up while saying "Disconnecting active connections". I've had to revert to version 1.5.9. Strangely, 1.6.2.2 has no problems connecting to APs on my campus (unknown model) or a Linksys WRT54GL. Very few logs are available but I can go through and add anything that might be relevant?

Dan O'Reilly (oreilldf) wrote :

Are all of you trying to connect to networks with essids made up entirely of numbers? It looks like that's the case for dlanod and Kortatu, at least.

oofnik (oofnik) wrote :

Good observation Dan. My SSID is also all numbers. I will change it tomorrow and test with the latest build. Stay tuned.

Kortatu (kortatu-gmail) wrote :

I've changed my ESSID to alphanumeric characters and now is working. It seems that the problem is related to numerical ESSID.
oofnik, have you tested it?

Dan O'Reilly (oreilldf) wrote :

Try pulling down the latest development version from bzr and see if the problem is still there. I fixed a few issues related to numerial essids.

oofnik (oofnik) wrote :

Working properly now, ESSID has been changed to all letters. I had to clear /etc/wicd/wireless-settings.conf as well.

I will change the ESSID back to numbers when I have a chance. I'm not the only user on the network but next chance I get I will test the latest code.

oofnik (oofnik) wrote :

After running "bzr branch lp:wicd" it seems that I am now able to connect to all ESSIDs. I set up an older router for testing so as not to interfere with my network.

dlanod (donald-shepherd) wrote :

Interestingly, WICD still shows the ESSID of my network as 21337 regardless of what I change it to, whether I change channel number as well, and whether I made the change while the system was turned off. As a result it's still exhibiting the same problem. Is there a cache somewhere that I should be clearing?

Robby Workman (rworkman) wrote :

dlanod: you'll need to stop the daemon and edit /etc/wicd/wireless-settings.conf - basically change that "21137" to whatever the new essid is, or alternatively you can just clear the entire file and let wicd start over.

Jonathan (jonathanschultz) wrote :

FWIW I still get this problem with version 1.7.0 under Debian on an Openmoko Freerunner.

The specific details are that I am using a university wireless network that has many access points with the same essid (all letters, no numbers) and WPA2 authentication. When I connect to the 'usual' AP (ie the one closest to my office) it works fine. But when I try to connect to any other AP, wicd-client stalls with 'Disconnecting active connections' while wicd.log shows 'Running pre-disconnect script'. There is no reason for a pre-disconnect script to be run as it was not previously connected to any network. The network I am trying to connect to does have a pre-disconnect script - however it returns immediately if it is run when no network is connected.

This behaviour is completely reproducible, it makes no difference whether wicd was previously connected to another network, or just started. Rebooting the device makes no difference either.

I guess the next step is to look at the source for the wicd daemon, but I'm hoping a description of these symptoms may be enough for someone who knows the code to figure it out.

Jonathan (jonathanschultz) wrote :

OK I was forced by a network outage to figure this out, which I have to at least partially.

It turns out that the file usr/share/pyshared/wicd/networking.py has a bug in it which causes python to lose the plot. Instead of passing the mac and essid as separate arguments to expand_script_macros it was passing a list (sorry if I'm using the wrong terminology, my knowledge of python is basic). Seriously though, HTFDIEW?

Carlos (cromualdo) wrote :

I'm having the very same problem with any 1.7 version from repositories, 1.7.0+ds2-1 specifically, which was installed after performing a dist-upgrade on Sidux. I have been through different kernels already (2.6.32 and 2.6.33) and the problem is persistent.

Reverting to previous version (1.6.2.2-1) fixes all these issues and presents normal behaviour.

Not to make this a very long post and repeat what others have said already, I'll add the following:

- If wired connection is present, valid ip will be given to eth0 right after boot and network connection is established, but if a disconnection happens (either by removing cable or attempt to connect to wireless) then no ip will be given again to eth0, unless wicd daemon is restarted.

-The wlan0 interface simply refuses to get an ip address under any circumstance.

I attach the relevant log portion of wicd in debug mode, although no important error information seemed to be present. Except maybe for this long time out period with no action/reaction from the daemon on the way to a non successful connection, which is accompanied on the gui with the "Disconnecting active connections" message, already presented before by Jonathan. Clicking on "Disconnect All" breaks the message and we're back to square one.

Raniz (raniz) wrote :

I've had the same issue here and Jonathan's patch fixes it.

When and if it stalls depends on what scripts you have set, it'll stall when executing any of the scripts due to an exception being thrown but if no script(s) are set the code that causes the stall won't be executed.

Jon Shapcott (eden-xibalba) wrote :

I've had the same problems, but more so, and the patch doesn't fix it for me.

The other problems are a "Bad marshal data" error when importing the python gobject package. I worked around this by removing the python -O flag from /usr/sbin/wicd, /usr/bin/wicd-gtk and /usr/bin/wicd-curses scripts. Once I'd done this, then wicd fails to connect automatically to ticked entries, and stalls as described when asked to connect. They tray icon also fails to indicate connection status.

Fortunately, wicd-curses works fine. I've resorted to automatically opening it in an xterm (actually urxvtc, but that's by the by) when logging into my netbook.

All this started happening when I upgraded to Ubuntu 10.04, which included upgrading wicd to version 1.7.0. I use xmonad as my window manager, xfce as my session manager, and nodm as my display manager.

After all that, it is still more reliable and less annoying than network-manager, but I'd be really grateful if anyone could shed any light on what might be causing all this.

Same problem for me with wicd 1.7.0 on Gentoo. However as a workaround connecting with wicd-curses works. Jonathans path(Comment #17 ) fixes the problem for me.

And I also have scripts set for the wired connection.

Changed in wicd:
status: Incomplete → Fix Committed
David Paleino (dpaleino) on 2012-02-05
Changed in wicd:
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