[ath9k-devel] ath9k not connecting to one particular network..

[Dan Williams <dcbw@redhat.com>]

On Tue, 2013-03-26 at 11:58 +0200, Jouni Malinen wrote:
> On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote:
> > Nothing sane worked, so I did a brute-force "let's just make
> > wpa_supplicant a shell-script that adds the debug fields and then runs
> > the real wpa_supplicant binary with the extra flags".
> 
> Ah, yes. I remember having done that at some point long time ago when
> giving up with NM.. ;-)

That debugging page should really be updated now that most people are on
0.9.  In any case, when developing, to get around systemd + NM
respawning the supplicant when it dies, I typically do:

mv /usr/sbin/wpa_supplicant /
killall -TERM wpa_supplicant
/wpa_supplicant -dddtuK

and then NM will see the supplicant start again, and reconnect, and you
get all the debug logs.  You can also poke the supplicant via D-Bus to
increase the logging level, but I'm not sure if the D-Bus interface
allows exposing the keys.

> > The bugzilla at
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=927191
> > 
> > now has a wpa_supplicant trace with keys and timestamps for the
> > non-working NetworkManager case too.
> > 
> > I see no sane difference. There are several dbus-related setup
> > differences, but then in the actual handshake, afaik they do the same
> > thing, except the non-working one never gets the reply after sending
> > EAPOL-Key 2/4. I dunno. I have no idea what that thing is actually
> > doing.
> 
> I could not find any real difference in the security negotiation of
> EAPOL-Key messages 1-2. The point that Robert made in the bugzilla case
> is interesting, though. I did not notice this at first, but there is
> indeed a clear difference in the driver interface (nl80211 vs. WEXT)
> that is being used here. This should not have really caused the issue
> since both cases used cfg80211 and same set of parameters for
> association. Anyway, that is the only clear difference..

NM has passed "nl80211,wext" as the supplicant driver for a year or so
now, because we all know nl80211 is the way to go.  Besides that, the
network config sent to the supplicant does not change at all between
nl80211 and wext; you can see the options in /var/log/messages:

<info> Config: added 'ssid' value 'rio grande'
<info> Config: added 'scan_ssid' value '1'
<info> Config: added 'key_mgmt' value 'WPA-PSK'
<info> Config: added 'psk' value '<omitted>'
<info> Config: added 'proto' value 'WPA RSN'
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.

NM doesn't dump the key, but that feature seems useful and could be
added with some huge warnings.

> If you still happen to be at the location with this AP, it could be
> useful to confirm that this kernel interface difference is indeed the
> reason by running the manual configuration case with -Dnl80211 added to
> the wpa_supplicant command line to force nl80211 interface to be used.

This would be a great test; obviously if nl80211 fails to work but wext
does work, we need to fix that in the supplicant or kernel.

Dan

> In addition, you could try to collect the frames exchanged by the
> success and failure cases using a monitor interface:
> 
> iw wlan0 interface add mon0 type monitor
> ifconfig mon0 up
> dumpcap -i mon0 -w /tmp/capture.pkt
> 
> And then run the success/failure case.
>