WPA2 Connection Problems between Android and DLink DIR-825 running OpenWRT

[David Levitan]

On 07/28/2010 07:44 AM, Jouni Malinen wrote:
>
> The driver and wpa_supplicant need to agree on the RSN IE contents. This
> can be resolved by changing either the driver or the supplicant.. I
> haven't looked at the newer Android versions, so I do not know what
> exactly they have done with wpa_supplicant. Anyway, it should be easy to
> change this in wpa_supplicant to match the driver (assuming the driver
> is hardcoding the value) by modifying src/rsn_supp/wpa_ie.c
> wpa_gen_wpa_ie_rsn() function (search for RSN Capabilities to find the
> field that was different). This is not really a complete fix for the
> issue, though.
>
> More proper fix would be to make the driver report the WPA/RSN IE it
> used during association to wpa_supplicant, so that wpa_supplicant knows
> which value needs to be used in 4-way handshake. This would be needed
> for PMKSA caching to work.
>

So after looking through the code, capturing the data between the 
clients and the routers, and trying to figure out what was going on, 
I've figured out the following interesting things.

1. The beacon frames from the D-Link (ath9k driver) contain a value of 
16 (base 10) for PTKSA replay counters, The rest of the capabilities are 
0. hostapd believes that the capabilities should be 0.

2. The response from my mac contains an RSN information element with 
capability set to 0

3. The response from the Droid contains two RSN information elements. 
The first contains capabilities with both PTKSA and GTKSA set to 16. The 
second contains capabilities with PTKSA and GTKSA set to 0. All other 
capabilities in both elements are set to 0.

4. If I associate to my old AP, the Droid again sends two RSN elements, 
but both with PTKSA=GTKSA = 0. The old AP beacon frames contains 
PTKSA=GTKSA=0.

5. The RSN information in the Droid appears to be set by the TI driver, 
but I'm not 100% sure about this. wpa_supplicant in android 2.2 appears 
very similar to the official version.

So my questions are:

1. Is the Droid breaking the WPA2 spec by sending two RSN elements?
2. Should hostapd be aware that ath9k is sending beacons with PTKSA=16, 
given that it expects the returned capabilities to be set to 0?
3. How should ath9k deal with the two RSN elements? Or should hostapd be 
dealing with this somehow?
4. What's the best way to solve this problem?

I can send packet captures if anyone is interested.

Thanks,
David