# Another WICD prob - disconnects after connecting

## tenspd137

Hi all,

I don't know what changed, but I cam home tonight and tried connecting to my WiFi network at home with wicd with no luck.  It connects and then immediatley disconnects.  Yet ehrn I run the commands from the log, well, I am writing here on the forum now.  Anyway, it appears there are multiple occurences of this all with different solutions.  The ones that talk about deleting net.* doesn't apply - the are not in my rc-startup.  Neither is dhcpcd.  I have only ever used wicd on this laptop. rc_hotplug="!net.eth* !net.wlan*" is present in my rc.conf.  dmesg says:

```

[   17.645576] iwlwifi 0000:0d:00.0: L1 Enabled; Disabling L0S

[   17.652443] iwlwifi 0000:0d:00.0: Radio type=0x2-0x2-0x1

[   17.837928] iwlwifi 0000:0d:00.0: L1 Enabled; Disabling L0S

[   17.844795] iwlwifi 0000:0d:00.0: Radio type=0x2-0x2-0x1

[   18.049375] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

[   22.758356] fglrx_pci 0000:01:00.0: irq 51 for MSI/MSI-X

[   22.758864] <6>[fglrx] Firegl kernel thread PID: 3521

[   22.758909] <6>[fglrx] Firegl kernel thread PID: 3522

[   22.758953] <6>[fglrx] Firegl kernel thread PID: 3523

[   22.759074] <6>[fglrx] IRQ 51 Enabled

[   22.808316] <6>[fglrx] Reserved FB block: Shared offset:0, size:1000000 

[   22.808319] <6>[fglrx] Reserved FB block: Unshared offset:f8fc000, size:404000 

[   22.808320] <6>[fglrx] Reserved FB block: Unshared offset:7fff4000, size:c000 

[   23.121284] r8169 0000:07:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2)

[   23.136218] r8169 0000:07:00.0 eth0: link down

[   23.136254] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   71.633584] iwlwifi 0000:0d:00.0: L1 Enabled; Disabling L0S

[   71.640453] iwlwifi 0000:0d:00.0: Radio type=0x2-0x2-0x1

[   71.899474] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

[   71.978405] r8169 0000:07:00.0 eth0: link down

[   71.978451] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   72.024771] iwlwifi 0000:0d:00.0: L1 Enabled; Disabling L0S

[   72.031627] iwlwifi 0000:0d:00.0: Radio type=0x2-0x2-0x1

[   72.257678] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

[   74.837311] wlan0: authenticate with 00:24:a5:af:f6:7f

[   74.856262] wlan0: send auth to 00:24:a5:af:f6:7f (try 1/3)

[   74.858648] wlan0: authenticated

[   74.859705] wlan0: associate with 00:24:a5:af:f6:7f (try 1/3)

[   74.863468] wlan0: RX AssocResp from 00:24:a5:af:f6:7f (capab=0x411 status=0 aid=4)

[   74.865909] wlan0: associated

[   74.865959] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[   77.125333] wlan0: deauthenticating from 00:24:a5:af:f6:7f by local choice (reason=3)

```

and wicd.log

2013/02/23 22:47:58 :: Running DHCP with hostname reggie

2013/02/23 22:47:58 :: /sbin/dhcpcd -h reggie --noipv4ll wlan0 

2013/02/23 22:47:58 :: dhcpcd[6341]: version 5.6.7 starting

2013/02/23 22:47:58 :: 

2013/02/23 22:47:58 :: dhcpcd[6341]: wlan0: sending IPv6 Router Solicitation

2013/02/23 22:47:58 :: 

2013/02/23 22:47:58 :: dhcpcd[6341]: wlan0: sendmsg: Cannot assign requested address

2013/02/23 22:47:58 :: 

2013/02/23 22:47:58 :: dhcpcd[6341]: wlan0: broadcasting for a lease

2013/02/23 22:47:58 :: 

2013/02/23 22:47:59 :: dhcpcd[6341]: wlan0: Router Advertisement from fe80::1497:d6ff:fe13:d4d8

2013/02/23 22:47:59 :: 

2013/02/23 22:47:59 :: dhcpcd[6341]: forked to background, child pid 6379

2013/02/23 22:47:59 :: 

2013/02/23 22:47:59 :: 

2013/02/23 22:47:59 :: DHCP connection successful

2013/02/23 22:47:59 :: not verifying

2013/02/23 22:47:59 :: Connecting thread exiting.

2013/02/23 22:47:59 :: ifconfig wlan0

2013/02/23 22:47:59 :: IP Address is: None

2013/02/23 22:47:59 :: Sending connection attempt result success

2013/02/23 22:47:59 :: ifconfig eth0

2013/02/23 22:47:59 :: Forced disconnect on

2013/02/23 22:47:59 :: iwconfig wlan0

2013/02/23 22:47:59 :: /sbin/dhcpcd -k wlan0

2013/02/23 22:47:59 :: ifconfig wlan0 0.0.0.0 

2013/02/23 22:47:59 :: /bin/route del dev wlan0

2013/02/23 22:47:59 :: ifconfig wlan0 down

2013/02/23 22:47:59 :: ifconfig wlan0 up

2013/02/23 22:48:00 :: wpa_cli -i wlan0 terminate

[/code]

[code]

I could use some help debugging this if anyone can suggest the steps to take.  It seems like nothing I have tried is working.

Thanks.

**EDIT**

I am a little more convinced it is in WICD itself - I installed NetworkManager, and it seems to work ok.  Not that I want to use networkmanager permanently - I really prefer WICD.  So, still, any help would be appreciated.

**EDIT 2**

After messing around with settings and what not in wicd, I noticed that the driver was not nl80211.  When I changed it to that, it seems to work.  the only curiosity is if I disconnect and reconnect, then it won't work.  I have to change the driver, let it fail, then go back to nl80211.  Then it works.  *Sigh* I don't know, but I guess it isn't a huge deal since I don't normally disconnect and reconnect the network card.

**EDIT 3**

Tried running it again - same problem - wicd doesn't connect, or disconnects than connects regardless if chosen WPA driver.  Back to networkmanager for now, but if anyone knows how to debug this or has solved this problem, I'd appreciate your help.  Seems like the problem is Wicd for whatever reason, but overall I prefer it to network manager.  I think I'll also post a bug, see if that gets me anywhere.

----------

## wcg

 *Quote:*   

> wlan0: deauthenticating from 00:24:a5:af:f6:7f by local choice (reason=3)

 

Last time I saw this (in a thread here), it was someone running wicd with

wpa_supplicant underneath. That was a kernel message from one of the

wireless networking kernel files (cfg80211 or mac80211). It meant that

the layer underneath wicd (still userspace, though) saw something it

considered incorrect and sent a disconnect message from the wlan interface

to the access point. ("reason=3" simply means "disconnected in response

to a command from userspace to disconnect", which is what "local choice"

translates to.) The WPA2 PSK is correct, else authenticating and associating

would not have succeeded.

I think wicd is the wrong place to look for the problem. Whatever the error

is, it is noticed and responded to at a lower level that wicd interfaces with,

not by wicd itself.

Power saving? If you search for "local choice" here, you might find that thread

(sometime in last few months).

----------

## tenspd137

Well, wpa-supplicant is installed, but I have never run it directly.  I have always just used wicd - never set anything else to run with rc-update.  I'll take a look through the conversations like you suggest and see if I can find anything more.  I already filed a bug with wicd in hopes that they can point me in the right direction, but it might not get answered for a while.  I plan to keep digging when I have time though - I don't like network manager all that much, but it is a quick fix for now.

Thanks - I'll post back if I do or don't find anything useful.

----------

## wcg

Right, wicd starts up wpa_supplicant itself. Options for wpa_supplicant would be

in /etc/wpa_supplicant/wpa_supplicant.conf, which you probably already had

setup correctly if it worked before. There might be something in

wicd's config file where it sets driver selection, etc, for wpa_supplicant

(some equivalent to /etc/conf.d/wpa_supplicant that is used instead

of that file when you do not add wpa_supplicant to the default runlevel

with rc-update, which is correct for using wicd).

I seem to remember one user reporting that his wireless device

driver was using too aggressive of power-saving settings, and the wireless

interface would power down when wpa_supplicant was waiting for a response.

If the response did not arrive in time, wpa_supplicant would issue a command

to disconnect.

Another user fixed his problems by building the cfg80211 and ma80211

modules, his wireless network device driver, and any related options into

the kernel instead of as modules. (The link to the access point stopped

crashing at random times.)

Even if the problem is not their doing, the wicd developers are probably

getting similar reports from other users with your hardware and/or

kernel version, so they may have an answer.

----------

