wpa_supplicant WPA crashes Sitecom WL-114 router

[Lorenzo Colitti]

Jouni Malinen wrote:
> I'm not sure what you mean by this. Client side does not request any
> specific key length in 4-Way Handshake.

I was referring to what ethereal sees as the "key length" field in 
messages 2/4 and 4/4. wpa_supplicant sets it to 32 in wpa.c:

>         reply->key_length = wpa_s->proto == WPA_PROTO_RSN ?
>                 0 : key->key_length;

but Windows sends 0. I hacked this but it doesn't seem to make a big 
difference.

I dug a little bit deeper and I think that the key to understanding the 
problem is that the AP skips a number in the replay counters between 4/4 
4-way and 1/2 group. This suggests it's hardcoding replies and receiving 
packets from the supplicant that it doesn't expect. wpa_supplicant does 
complain about the replay counters:

> Custom wireless event: 'MLME-REPLAYFAILURE.indication(keyid=0 unicast addr=00:11:0a:81:6b:64)' 

and perhaps madwifi bails out for that reason (with a "new AP 
00:00:00:00:00:00 found" wireless event).

I found that one thing the AP didn't like was that wpa_supplicant 
doesn't send an EAPOL start message. I hacked wpa_supplicant to include 
that and the packets that the AP sends are much more similar to the ones 
it sends to Windows.

But I still can't get it to work. I used Ethereal to sniff the 
unencrypted packets both on Windows and on Linux, and the only 
significant differences I see, apart from the fact that the Windows 
driver sends WPA keys of length 26 instead of 24, are the replay 
counters. (See attached text files for decoded packets and diff.txt for 
differences.)

I can't for the life of me understand why the AP is behaving like that! 
It seems to receive almost exactly the same packets, but to Windows it 
sends a correct replay counter and to wpa_supplicant it skips a number.

I hacked wpa_supplicant to send keys of length 26, but that didn't help.

Any ideas? Should I try to get a second card in monitor mode and see 
what happens?


Cheers,
Lorenzo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wpa-win.pcap
Type: application/octet-stream
Size: 1201 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050325/b0fe45a8/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wpa-linux.pcap
Type: application/octet-stream
Size: 1200 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050325/b0fe45a8/attachment-0001.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wpa-win.txt
Url: http://lists.shmoo.com/pipermail/hostap/attachments/20050325/b0fe45a8/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wpa-linux.txt
Url: http://lists.shmoo.com/pipermail/hostap/attachments/20050325/b0fe45a8/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
Url: http://lists.shmoo.com/pipermail/hostap/attachments/20050325/b0fe45a8/attachment-0002.txt