FW: [wpa_supplicant] Most WPA AP:s dont get to WPA_4WAY_HANDSHAKE state when wrong PSK is supplied

[Olsson, Ola1]

Hi again,

Jouni, You are totally right and I am truly sorry for this. I had two different prototype devices which looks the same, only one of them has its mac address in the AP:s mac address filter, that is why I thought I had a problem in the first place, the device that is in the filter gets to 4-WAY-HANDSHAKE before it gets disconnected.

/Ola


-----Original Message-----
From: Jouni Malinen [mailto:j at w1.fi] 
Sent: m?ndag den 13 december 2010 22:15
To: Olsson, Ola1
Cc: 'Paul Stewart'; Helmut Schaa; hostap at lists.shmoo.com
Subject: Re: FW: [wpa_supplicant] Most WPA AP:s dont get to WPA_4WAY_HANDSHAKE state when wrong PSK is supplied

On Mon, Dec 13, 2010 at 06:19:19PM +0100, Olsson, Ola1 wrote:
> I have attached the whole log from a bad-psk on a less good behaving AP. I can't see why I am inconsistent as the first example was a "bad psk on a bad AP" which is now attached. The logs you were referring to were an example of a good behaving AP " Bad PSK on a good AP (Dlink DIR-635)". I am sorry if that confused you, I am not interested in that case as it works perfectly. I just brought it up to show you that I actually have an AP where the supplicant is working fine.

Are you able to associate with this "bad AP" even with the correct
passphrase? The debug log here seemed to indicate that the driver did
not event manage to get associated and there was not even a single
EAPOL-Key frame coming to wpa_supplicant. As such, there was no way of
the incorrect passphrase having been used and there should not have been
any difference whatsoever on which passphrase were configured. In this
type of case, wpa_supplicant has no way of knowing whether the
passphrase was correct and as such, not seeing an event indicating
possible incorrect passphrase is the expected and correct behavior.

-- 
Jouni Malinen                                            PGP id EFC895FA