wicd 1.7.0-6 + dhcpcd/dhclient = fail

Bug #661674 reported by SMD
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
wicd
New
Undecided
Unassigned
Debian
New
Unknown

Bug Description

Hello,
Not so long ago I've upgraded my arch on eeepc901. Before that everything worked properly.
But now I've got troubles with connecting to my open wifi network:
wicd can't get IP via dhcpcd or dhclient.
But if I try to connect to the network manually I'm succeded.
I've searched for the problem, and found some threads for 2008-2010. But none of them had the solution, only the description of problem.

System info:
2.6.35-ARCH #1
Python 2.7 and 3.1.2 installed
wicd 1.7.0-6
testing repo added
wlan0 Ralink STA ESSID:"" Nickname:"RT2860STA"
          Mode:Auto Frequency=2.462 GHz Access Point: 00:1C:F0:DA:6E:DB
          Bit Rate=1 Mb/s
          RTS thr:off Fragment thr:off
          Link Quality=100/100 Signal level:-42 dBm Noise level:-97 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Got following, while tried to connect via wicd:

dhcdcd enabled:

2010/10/16 15:23:31 :: setting use global dns to 0
2010/10/16 15:23:31 :: setting global dns
2010/10/16 15:23:31 :: global dns servers are
2010/10/16 15:23:31 :: domain is
2010/10/16 15:23:31 :: search domain is
2010/10/16 15:23:31 :: setting wireless interface wlan0
2010/10/16 15:23:31 :: setting wired interface eth0
2010/10/16 15:23:31 :: setting wpa driver wext
2010/10/16 15:23:31 :: setting automatically reconnect when connection drops 0
2010/10/16 15:23:31 :: setting backend to external
2010/10/16 15:23:31 :: Setting dhcp client to 2
2010/10/16 15:23:33 :: Connecting to wireless network HOME
2010/10/16 15:23:33 :: Putting interface down
2010/10/16 15:23:33 :: Releasing DHCP leases...
2010/10/16 15:23:33 :: Setting false IP...
2010/10/16 15:23:33 :: Stopping wpa_supplicant
2010/10/16 15:23:34 :: Flushing the routing table...
2010/10/16 15:23:34 :: Putting interface up...
2010/10/16 15:23:36 :: Running DHCP with hostname atomsk
2010/10/16 15:23:36 :: dhcpcd[4208]: version 5.2.7 starting
2010/10/16 15:23:36 ::
2010/10/16 15:23:36 :: dhcpcd[4208]: wlan0: broadcasting for a lease
2010/10/16 15:23:36 ::
2010/10/16 15:24:06 :: dhcpcd[4208]: timed out
2010/10/16 15:24:06 ::
2010/10/16 15:24:06 :: DHCP connection failed
2010/10/16 15:24:06 :: exiting connection thread
2010/10/16 15:24:09 :: Sending connection attempt result dhcp_failed

dhclient enabled:

2010/10/16 15:26:17 :: setting use global dns to 0
2010/10/16 15:26:17 :: setting global dns
2010/10/16 15:26:17 :: global dns servers are
2010/10/16 15:26:17 :: domain is
2010/10/16 15:26:17 :: search domain is
2010/10/16 15:26:17 :: setting wireless interface wlan0
2010/10/16 15:26:17 :: setting wired interface eth0
2010/10/16 15:26:17 :: setting wpa driver wext
2010/10/16 15:26:17 :: setting automatically reconnect when connection drops 0
2010/10/16 15:26:17 :: setting backend to external
2010/10/16 15:26:17 :: Setting dhcp client to 1
2010/10/16 15:26:19 :: Connecting to wireless network HOME
2010/10/16 15:26:19 :: attempting to set hostname with dhclient
2010/10/16 15:26:19 :: using dhcpcd or another supported client may work better
2010/10/16 15:26:19 :: Putting interface down
2010/10/16 15:26:19 :: Releasing DHCP leases...
2010/10/16 15:26:19 :: attempting to set hostname with dhclient
2010/10/16 15:26:19 :: using dhcpcd or another supported client may work better
2010/10/16 15:26:19 :: Setting false IP...
2010/10/16 15:26:19 :: Stopping wpa_supplicant
2010/10/16 15:26:19 :: Flushing the routing table...
2010/10/16 15:26:19 :: Putting interface up...
2010/10/16 15:26:21 :: Running DHCP with hostname atomsk
2010/10/16 15:26:21 :: attempting to set hostname with dhclient
2010/10/16 15:26:21 :: using dhcpcd or another supported client may work better
2010/10/16 15:26:21 :: Internet Systems Consortium DHCP Client 4.2.0
2010/10/16 15:26:21 :: Copyright 2004-2010 Internet Systems Consortium.
2010/10/16 15:26:21 :: All rights reserved.
2010/10/16 15:26:21 :: For info, please visit https://www.isc.org/software/dhcp/
2010/10/16 15:26:21 ::
2010/10/16 15:26:21 :: can't create /var/db/dhclient.leases: No such file or directory
2010/10/16 15:26:23 :: Listening on LPF/wlan0/00:15:af:ef:ab:0b
2010/10/16 15:26:23 :: Sending on LPF/wlan0/00:15:af:ef:ab:0b
2010/10/16 15:26:23 :: Sending on Socket/fallback
2010/10/16 15:26:23 :: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
2010/10/16 15:26:26 :: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
2010/10/16 15:26:33 :: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
2010/10/16 15:26:44 :: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
2010/10/16 15:26:59 :: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17
2010/10/16 15:27:16 :: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
2010/10/16 15:27:24 :: No DHCPOFFERS received.
2010/10/16 15:27:24 :: No working leases in persistent database - sleeping.
2010/10/16 15:27:24 :: DHCP connection failed
2010/10/16 15:27:24 :: exiting connection thread
2010/10/16 15:27:25 :: Sending connection attempt result dhcp_failed
2010/10/16 15:27:25 :: attempting to set hostname with dhclient
2010/10/16 15:27:25 :: using dhcpcd or another supported client may work better

And then I type:

iwconfig wlan0 essid HOME
dhcpcd wlan0

and got connected.

Tags: dhcp wicd
Revision history for this message
Maris Nartiss (maris-nartiss) wrote :

My guess - it's a duplicate issue of #1098978

To see if it's so, just perform these steps:
while wicd is in state "obtaining IP address", run 'ps fax | grep dhcp' (without quotes) from terminal. You might need to run it few times till you obtain actual dhcp call that might look like this: "7736 ? S 0:00 \_ /sbin/dhcpcd -h darkstar --noipv4ll eth0"
Now try to run the command from terminal (/sbin/dhcpcd -h darkstar --noipv4ll eth0). If it fails, try to remove -h myhostname part and run again. If it succeeds, it's a bug #1098978.

Revision history for this message
Karl (kc0bfv) wrote :

Hello from 2019. I'm having similar issues, and have for a long time, when connecting to unsecured wifi like at coffee shops and hotels. I see several other bugs in the DB that reflect this same issue, so I'm redirecting them here to increase attention - although wicd looks like it's in trouble, regarding, attention, in general.

My issue - specifically: when I use wicd to connect to non-wep non-wpa unsecured wifi, wicd fails by eventually timing out during the "obtaining ip address" phase (it's using dhcp). If I watch the output of iwconfig while wicd is "obtaining ip address", it reports "Access-point: Not Associated".

I found another post on the Internet recommending running "iw dev ${device} connect" while wicd is trying to obtain an ip address. This has resolved my issue in almost every case, causing iwconfig to report an association, and wicd to complete the obtain ip address phase.

So - how does wicd associate with an ap? It's in wnettools.py - function Associate. First it uses function SetEssid. That executes "iwconfig ${device} essid -- ". Plenty of Internet posts recommend this syntax for associating with an AP - running this from a command line should associate.

However -
On my specific system (Linux macbook pro 2011 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux), it does not. I get "Access-point: Not Associated". I actually try things like taking the "ip link" down, "ifconfig down", "ap off" then "ap auto"... No dice - iwconfig is basically refusing to associate with the unsecured AP.

IF YOU ARE HAVING THIS BUG TOO - I'D LOVE IT IF YOU'D TRY THIS TEST TOO!

iwconfig is considered deprecated by lots, now, so maybe this is a result of that.

My solution - modify the SetEssid function to use "iw dev" instead of ifconfig. Making that mod, then deleting the .pyc and .pyo files, and restarting the daemon - I can now connect to the AP.

Revision history for this message
Karl (kc0bfv) wrote :
Revision history for this message
Karl (kc0bfv) wrote :

This patch does not use something like the "--" command line option used by the previous ifconfig. I don't think iw supports that notation. Thus - it may be possible for a user to supply an essid that is malicious, passing unusual parameters to iw. Just not sure.

Revision history for this message
Karl (kc0bfv) wrote :

Also - patch will create a dependence on "iw" package in Debian and Ubuntu, and whatever provides "iw" in the rest.

Changed in debian:
status: Unknown → New
Revision history for this message
Sebastian (xj25vm) wrote :

Hello from 2020. I've been having the same problem for years. I've just tried suggestions from #2 above. If I run from the command line while wicd interface shows "Obtaining IP address" :

iw dev wlan0 connect "ESSID"

then it does connect to the open network. However, I made the required change in wnettools.py, deleted wnettools.pyc and wnettools.pyo files, restarted wicd demon - but I'm afraid it still doesn't connect to open wifi networks. All a bit strange - or maybe there is a timing issue with the connection steps?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.