Strange behavior with wpa_supplicant -u

[Dan Williams]

On Wed, 2009-11-11 at 18:14 -0500, Mike Edenfield wrote:
> Hi,
> 
> I am having a connectivity issue with my wireless adapter that only 
> occurs when using wpa_supplicant's DBus interface, and only on one 
> specific AP.  My laptop has an internal Intel 3945ABG wireless adapter, 
> which I'm using via the Linux in-kernel iwlwifi driver.  When I try to 
> connect DLink AirPlus G 6000, using uses WPA-PSK with TKIP, that's in my 
> office, weird things happen.

What kernel version?  This could be due to periodic scanning which is
triggered by NM to keep an up-to-date list of APs available for various
reasons (fast roaming, UI display, etc).  Drivers *should* be able to
handle this, if they don't, then the driver needs to be fixed.

Apparently you're running drivers that aren't :(

Kernel versions lower than 2.6.29 had various problems that caused them
to fail in this case for software scans, and I've seen the iwlwifi
hardware scans also fail here for some reason.  Recent kernels (2.6.30
and later) work well here, and 2.6.32 has a "background scan"
infrastructure that improves scan performance as well.

> If I configure and run wpa_supplicant manually or via wicd, the adapter 
> hooks right up with the AP and stays there.  But if I try to use 
> NetworkManager, which controls wpa_supplicant through DBus, the adapter 
> spontaneously disassociates from the AP after about 15 seconds.  I get 
> the following errors:
> 
> wlan0: disassociated (Reason: 14)

Reason 14: MIC failure

> wlan0: deauthenticated (Reason: 6)

Reason 6: Class 2 frame received from nonauthenticated STA

Which is understandable because you're no longer associated.

> which appears to indicate that the encryption between the AP and the 
> adapter has failed.  This is usually followed by NetworkManager 
> prompting me again for the PSK, even though it hasn't changed.

NM (somewhat incorrectly) assumes that the PSK is incorrect if it cannot
reconnect to the AP using that PSK within a reasonable number of tries.
This is usually suckage between NM, the supplicant, and the driver.
Sometimes just trying again makes it work, other times the driver is
borked enough that it needs to be reloaded.

> The only difference I can detect between the working and non-working 
> setups is how wpa_supplicant is launched.
> 
> Working incovation: wpa_supplicant -Dwext -i wlan0 -c 
> /etc/wpa_supplicant/wpa_supplicant.conf -B
> 
> Failing invocation: wpa_supplicant -u
> 
> My biggest problem at the moment is I can't figure out how to tell what 
> wpa_supplicant is doing when it's running via nm.  Is there any type of 

NetworkManager is simply sending a network block down to the supplicant
(which you can see from wherever your distro directs the 'daemon' syslog
facility, usually /var/log/messages, /var/log/daemon.log,
or /var/log/NetworkManager.log), enabling it, and letting the supplicant
go.  You can see the supplicant's status in those logs too.

> command-line dbus utility or trace mechanism that I can use to see 
> what's going on?  Or better yet, has anyone else seen this behavior and 
> can tell me where to look to fix it?
> 
> (And, to ward off the "obvious" solution -- not using NetworkManager 
> isn't currently an option, for many frustrating reasons beyond my control.)

I'm curious what those reason are, so I can fix them :)

Dan