or does wpa_supplicant get it right? :-)

[Bryan Kadzban]

Holger Schurig wrote:
> When I roam between Cisco 1200 APs, it looks different. I request APs
> (222), get two responses (223, 224) and select one AP (225).
> 
> But now the difference: the old Cisco 1200 de-authenticates me (227).
> This was not the case above.

A deauthenticate packet is just the AP asking you to disassociate.  It's
probably there because the old AP got an IAPP message from the new one
that you had tried to associate, so it deauthenticated you.  Or, it's
because your card sent a Disassociate frame (I'm not entirely sure which
has to happen first; it may be that either one can happen first.)

> Can it be the case this this signal was, via the driver and the
> wireless events, relayed into wpa_supplicant and reset the EAPOL/WPA
> state machine in some way?

It should have been relayed to wpa_supplicant -- or at least, the new
association should have been.  If it doesn't know that it associated to
a new AP, it won't clear its EAPOL-Key replay counters, and it'll ignore
subsequent EAPOL-Key frames (4-way handshake frames) from that AP.  The
fix for this when using Windows and an NDIS driver is to run the
ndis_events.exe program, unless you're using wpa_supplicant 0.5.0, in
which case ndis_events is integrated into wpa_supplicant.  I don't
believe Linux has the same problem, but it may depend on the driver
you're using.

Some comments on your previous message:

Holger Schurig wrote:
> And now the slow one for the 4012:
> 
> Apr 22 02:52:03.826198: State: COMPLETED -> 4WAY_HANDSHAKE

This happens when it sees message 1 of the 4-way handshake.  (It should
have received another association-info event before this, though.  I
suspect that may be causing the problem, but I don't know for sure.)

> Apr 22 02:52:05.113043: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE

And this is when it receives message 1 a second time, according to the
full log you posted.  It has already sent message 2, but the AP either
never got it, ignored it, or rejected it -- in any case, the handshake
did not complete.  Usually this happens in PSK mode if the PSK is wrong,
but the first AP worked fine (as did this one, the second time through),
so that's not the problem.

> Apr 22 02:52:07.152616: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE

Here it received message 1 a third time (the second message 2 must have
also been rejected or failed to get there).

> Apr 22 02:52:09.563069: State: 4WAY_HANDSHAKE -> ASSOCIATED

And here, the third message 2 gets rejected, and it reassociates.
(Notice how it gets the ASSOCINFO event this time around.)

> Apr 22 02:52:09.580852: State: ASSOCIATED -> 4WAY_HANDSHAKE
> Apr 22 02:52:09.716334: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
> Apr 22 02:52:09.748514: State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE
> Apr 22 02:52:11.263727: State: GROUP_HANDSHAKE -> GROUP_HANDSHAKE
> Apr 22 02:52:11.282870: State: GROUP_HANDSHAKE -> COMPLETED

This is a full, working 4-way handshake.

I am starting to suspect the driver and the lack of an ASSOCINFO event.
Does your driver perhaps not provide these when roaming?  AFAIK it
should, but I don't know a ton about the WEXT interface.

(You're using the wpa_supplicant "hermes" driver; does the kernel hermes
driver have support for wireless extensions?  If so, you may want to try
the wpa_supplicant wext driver instead.  You probably need a fairly new
kernel to get that, though.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060113/5839f8f6/attachment.pgp