Bug in madwifi communication

[Jouni Malinen]

On Wed, Feb 23, 2005 at 03:15:29PM +0100, Jens Stavnstrup wrote:

> Originally I had no problems with these two running together back in
> November 2004, but now after upgrading wpa_supplicant (through debians
> apt-get) and the madwifi drive (manually), only part of the
> authentification phase seems to work, which of course means I cannot
> connect to the network.

Which version of wpa_supplicant are you using? If it is not 0.3.8, could
you please test this same configuration with 0.3.8?

> Is the following statement normal ?
> 
> WPA: EAPOL frame too short, len 48, expecting at least 99

Yes, that is normal. However, there's a problem in the end of the EAP
authentication shown below in the debug log. Which authentication server
are you using?

> EAP: Received EAP-Request method=25 id=10
> EAP: EAP entering state METHOD
> EAP-PEAP: Received packet(len=38) - Flags 0x00
> EAP-PEAP: received 32 bytes encrypted data for Phase 2
> EAP-PEAP: Decrypted Phase 2 EAP - hexdump(len=11): 01 0a 00 0b 21 80 03 00 02 00 01
> EAP-PEAP: received Phase 2: code=1 identifier=10 length=11
> EAP-PEAP: Phase 2 Request: type=33
> EAP-TLV: Received TLVs - hexdump(len=6): 80 03 00 02 00 01
> EAP-TLV: Result TLV - hexdump(len=2): 00 01
> EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
> EAP-PEAP: Encrypting Phase 2 data - hexdump(len=11): [REMOVED]
> EAP: method process -> ignore=FALSE methodState=DONE decision=UNCOND_SUCC
> EAP: EAP entering state SEND_RESPONSE
> EAP: EAP entering state IDLE
> EAPOL: SUPP_BE entering state RESPONSE
> EAPOL: txSuppRsp

This final part of PEAPv0, i.e., tunneled success notification seems to
go through fine.

> EAPOL: SUPP_BE entering state RECEIVE
> WPA: EAPOL frame too short, len 48, expecting at least 99
> RX EAPOL from 00:0b:0e:02:32:40
> EAPOL: Received EAP-Packet frame
> EAPOL: SUPP_BE entering state REQUEST
> EAPOL: getSuppRsp
> EAP: EAP entering state RECEIVED
> EAP: Received EAP-Success
> EAP: EAP entering state DISCARD

However, this plaintext EAP-Success packet is being ignored which makes
wpa_supplicant believe that the negotiation has not completed. Could you
please send debug log with one more -d on the command line to get some
more information about the reason for this.

> EAP: EAP entering state IDLE
> EAPOL: SUPP_BE entering state RECEIVE
> WPA: EAPOL frame too short, len 48, expecting at least 99
> RX EAPOL from 00:0b:0e:02:32:40
> EAPOL: Ignoring WPA EAPOL-Key frame in EAPOL state machines
> IEEE 802.1X RX: version=1 type=3 length=95
>   EAPOL-Key type=254
> WPA: RX message 1 of 4-Way Handshake from 00:0b:0e:02:32:40 (ver=2)
> WPA: WPA IE for msg 2/4 - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 01
> WPA: Renewed SNonce - hexdump(len=32): d3 4e ef 97 25 b2 99 85 5b d2 8e d2 79 07 81 b0 33 95 df c8 62 3b 07 74 75 72 8f db c4 41 96 14
> WPA: Failed to get master session key from EAPOL state machines
> WPA: Key handshake aborted

WPA handshake fails now since the EAP authentication has not been
completed (due to that EAP-Success packet being discarded).

-- 
Jouni Malinen                                            PGP id EFC895FA