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

["Joel Wirāmu Pauling" <joel@aenertia.net>]

Likely due to some odd dhcp options or behaviours comming  whatever odd
ball vendor implemented dhcp server that runs the wireless network dhcp
leases. Often in hotels or corporates they use an offloaded radius and
crypto upstream of the AP itself. These tend to be dark voodoo, Cisco and
Aruba/Alcatel-lucent are two such examples of these where I have seen this
sort of issue and others and NM failing to get recognise the dhcp offer.

Wireshark the interface and watch the dhcp negotiation sequence on a couple
of different networks and devices if you really want to pinpoint it.

Disclaimer I work for ALU.

Glad to hear you got it working.

-Joel
http://gplus.to/aenertia
On 26 Mar 2013 00:30, "Jouni Malinen" <jouni@qca.qualcomm.com> wrote:

> On Mon, Mar 25, 2013 at 04:06:49AM -0700, Linus Torvalds wrote:
> > Ok, full wpasupplicant log added to the RH NetworkManager bugzilla,
> > let's hope that somebody sees the problem there. I see that there's a
> > gnome bugzilla for NM too, but it appears that at least Dan Williams
> > is on both the RH and the gnome bugzilla, so I hope the RH bugzilla
> > entry is sufficient.
>
> >   https://bugzilla.redhat.com/show_bug.cgi?id=927191
> >
> > and while you didn't see the early part of the thread, it just boils
> > down to "NM doesn't work, setting things up manually with
> > wpa_supplicant does":.
>
> This looks very basic case taken into account the AP configuration (just
> WPA2-Personal/CCMP) and passphrase that should not allow much of a
> chance for typos or encoding issues (non-ASCII..). However, I cannot
> find anything obvious from the debug log. For some reason, the AP just
> rejects EAPOL-Key message 2/4 from the station. In most cases, this is
> because of a typo in the PSK/passphrase, but it sounds quite unlikely
> here unless NM somehow configured this differently (which would also be
> surprising if it applies only for this specific network).
>
> Since it looks like the particular passphrase is of not much need for
> protection, it could be useful if you could collect wpa_supplicant debug
> logs with -K added to the command line (-ddKt for the manual test and
> something similar with NM, I'd assume). This -K adds passwords and keys
> into the log so it is not something that is enabled by default, but it
> sounds like this is fine here and it will include the details that would
> be needed to check what exactly are the differences in the 4-way
> handshake between NM and manual wpa_supplicant configuration cases.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130326/f0224f7b/attachment.htm