key exchange issue with Aironet 1232AG AP

[Jouni Malinen]

On Mon, Sep 12, 2005 at 12:00:48PM -0700, CHui wrote:

> The wpa_supplicant 0.3.9 running on Windows XP starts getting the handshake
> failure after I upgraded the Cisco Aironet 1232AG AP from IOS 12.3(2)JA to
> 12.3(7)JA.  Although it seems to be a Cisco issue since the only variant in
> this case was the IOS version upgrade, other supplicant software like
> Windows Zero Configuration and SecureW2 continue to work without problem.

I'm aware of at least one Cisco releated oddity in WPA2 handshake and
there is a workaround for that in wpa_supplicant. In some cases,
wpa_supplicant may still be more strict about standard compliance than,
e.g., Microsoft supplicant. I would suggest running a quick test with
the latest development version (0.4.4) to see whether that has a
different behavior here since I may have added some extra workarounds at
some point.

> When the connection failed, the Cisco Aironet reported handshake timeout
> after sending "PTK msg 1".  Likewise, the wpa_supplicant  would drop and try
> to associate again.  This process could go on for many times before the
> wpa_supplicant finally connected with the message "WPA: Key negotiation
> completed with 00:13:.. {PTK=CMP GTK=TKIP]".  The AP handshake timeout is
> set to 100 ms by default.  I am not sure if this timeout value could be
> adjusted (pending on the vendor's reply).  Nevertheless, with the
> wpa_supplicant, I would like to know if the key exchange process be tuned to
> fix this timeout issue.  Has anybody experience the same issue with the
> Cisco AP and has a work around? 

Is this with WPA or WPA2? If you can send me a debug log from
wpa_supplicant, I can take a look at whether there is something that
would indicate what could be happening.

One thing to note is that wpa_supplicant is using polling to get EAPOL
packets on Windows. This could be enough to trigger some of the timeouts
since the polls are done every 100 ms by default. You should be able to
change this, but doing that will require building a new version. This
can be changed in l2_packet_pcap.c (or l2_packet.c in 0.3.9). Search for
these lines:

        eloop_register_timeout(0, 100000, l2_packet_receive_timeout,
                               l2, pcap);


That 100000 is number of microseconds, i.e., 100 ms, till the next poll.

-- 
Jouni Malinen                                            PGP id EFC895FA