EAPOL frame too short error with Cisco 1200 AP

[Derek Schuff]

Thanks for your reply!

Here's some good news:
I tried it again this morning (after flashing the firmware to 1.1.1 / 1.7.4; 
previously it was just RAM upload).
This time it worked. After a little investigation I discovered that my problem 
was indeed related to my second email (about the choice of APs to associate); 
it was simply that the AP it associated to had the wrong RADIUS server 
configured (I didn't expect to associate to it in the first place). So that's 
why it wasn't working there.

On a similar note, I found another question:
It seemed to scan several times, and the last time it found the proper AP, and 
that's why it worked.
During the AP scan, I found this:

Starting AP scan (broadcast SSID)
Wireless event: cmd=0x8b19 len=12
Received 2053 bytes of scan results (10 BSSes)
Scan results: 10
0: 00:0c:85:60:f1:c0 ssid='ornl-visitor' wpa_ie_len=0 rsn_ie_len=0
   skip - no WPA/RSN IE
1: 00:0c:85:60:f1:f1 ssid='ornl-visitor' wpa_ie_len=0 rsn_ie_len=0
   skip - no WPA/RSN IE
2: 00:0c:85:60:f1:f1 ssid='ornlwpa' wpa_ie_len=24 rsn_ie_len=0
Trying to associate with 00:0c:85:60:f1:f1 (SSID='ornlwpa' freq=2437 MHz)

Now, I checked and made sure that this AP is configured to respond to a 
broadcast SSID with the ornl-visitor SSID and not the ornlwpa SSID, but the 
client seems to have found it in the broadcast scan.  Also note that we got 
back 2 SSIDs from the same AP. Does this look like an error, or something to 
be concerned about? Could the client possibly have scanned with a specific 
SSID, or does the AP seem to be responding incorrectly?

Also, how are roaming decisions handled? Is that in the firmware?

Thanks again for your help.

On Tuesday 01 June 2004 11:14 pm, Jouni Malinen wrote:
> On Tue, Jun 01, 2004 at 01:11:56PM -0400, Derek Schuff wrote:
> > It seems to be enabling WPA and associating but i get this error message:
> >
> > WPA: EAPOL frame too short, len 46, expecting at least 99
>
> That is not an error.
>
> > These APs have multiple SSIDs, and they advertise a different SSID
> > (ornl-visitor) than the one I want (ornlwpa) so scanning is enabled.
>
> If I remember correctly, I haven't tested Host AP driver with Cisco AP
> and secondary SSID, but I know that wpa_supplicant works with another
> driver in that kind of configuration. Host AP driver was able to use an
> AP that did not include SSID in the beacon (but did include matching WPA
> IE, what the Cisco AP might not do in all cases).
>
> > Starting AP scan (specific SSID)
> > Scan SSID - hexdump_ascii(len=7):
> >      6f 72 6e 6c 77 70 61                              ornlwpa
> > Wireless event: cmd=0x8b19 len=12
> > Received 1813 bytes of scan results (9 BSSes)
> > Scan results: 9
> > 0: 00:0c:85:60:f1:b4 ssid='ornlwpa' wpa_ie_len=24 rsn_ie_len=0
> > Trying to associate with 00:0c:85:60:f1:b4 (SSID='ornlwpa' freq=2412 MHz)
> > WPA: using IEEE 802.11i/D3.0
> > WPA: Own WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01
> > 00 00 50 f2 02 01 00 00 50 f2 01
> >
> > Wireless event: cmd=0x8b1a len=19
> > RX EAPOL from 00:0c:85:60:f1:b4
> > EAPOL frame received in disassociated state - dropped
> > Wireless event: cmd=0x8b15 len=20
> > Wireless event: new AP: 00:0c:85:60:f1:b4
> > Association event - clear replay counter
> > Associated to a new BSS: BSSID=00:0c:85:60:f1:b4
>
> This is a race condition in the client. Notification of the association
> event is processed after having received the first EAPOL frame from the
> AP. I should probably change wpa_supplicant to process this frame anyway
> or at least first try to verify whether the driver reports a matching
> BSSID even though the association event has not yet been received. The
> dropped frames was most probably EAP-Request Identity.
>
> Anyway, it looks like the association did succeed.
>
> > EAPOL: SUPP_PAE entering state CONNECTING
> > EAPOL: txStart
>
> wpa_supplicant is sending EAPOL-Start message immediately, so the
> dropped identity request should not be an issue. Authenticator should
> reply to EAPOL-Start by sending a new EAP-Request Identity, which is
>
> does:
> > EAPOL: Received EAP-Packet frame
> > EAP: Received EAP-Request method=1 id=2
> > EAP: EAP entering state IDENTITY
> > EAP: EAP-Request Identity data - hexdump_ascii(len=0):
>
> wpa_supplicant replies:
> > EAP: using real identity - hexdump(len=9): 74 65 73 74 5f 75 73 65 72
> > EAP: EAP entering state SEND_RESPONSE
> > EAP: EAP entering state IDLE
> > EAPOL: SUPP_BE entering state RESPONSE
> > EAPOL: txSuppRsp
> >
> > EAPOL: SUPP_BE entering state RECEIVE
> >
> > -->Heres what I think the real error message is, but i could be wrong
> > WPA: EAPOL frame too short, len 46, expecting at least 99
>
> This is not an error message (well, at least in most cases). Both the
> IEEE 802.1X and WPA state machines process the incoming frames and the
> EAPOL frames from 802.1X state machines are ignored in the WPA
> processing (like here). I'm not sure whether you removed some lines
> here, but this log file does not look correct. wpa_supplicant (the IEEE
> 802.1X part) is supposed to process the following EAP packets. In this
> case, the authentication server should send EAP-Request for its default
> authentication method.
>
> > -->If I let it go, it just repeats, so I kill it here.
>
> Please send a log file that includes more attempts.. In addition, please
> also make a packet capture from the wlan0 interface and send it to me.
> For example, with "tcpdump -s 1500 -w wlan0.dump -i wlan0" records
> packets to wlan0.dump. You can also use Ethereal for this. Please also
> include the .config file you used when compiling wpa_supplicant.