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

[Jouni Malinen]

On Wed, Jul 28, 2010 at 02:18:23PM -0700, David Levitan wrote:
> 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.

What do you mean with "hostapd believes"..? hostapd generates the IEs
for Beacon frames with all mac80211-based drivers, including ath9k.

> 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.

That sounds broken..

> 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.

Do you have WMM/QoS disabled on the old AP?

> 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.

I would guess that something goes wrong and the driver ends up including
both the internally generated RSN IE and the one that wpa_supplicant
asks it to use..

> 1. Is the Droid breaking the WPA2 spec by sending two RSN elements?

Yes.

> 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?

hostapd is aware of what ath9k is sending because hostapd is generating
the IE.. There is no expectation on the RSN Capabilities being same
between the AP and the stations. The key is that the RSN IE from AP must
be same in Beacon, Probe Response, and EAPOL-Key msg 3 of 4 and that the
RSN IE from the station must be same in (Re)Association Request and
EAPOL-Key msg 2 of 4.

> 3. How should ath9k deal with the two RSN elements? Or should hostapd be 
> dealing with this somehow?

ath9k does not care about RSN IE. hostapd needs to take care of this and
since two RSN IEs are not expected to be included in (Re)Association
Request, the behavior can be unspecified. hostapd could as well reject
the connection just because of that, but now, it is likely picking the
last RSN IE in the message and comparing it to EAPOL-Key msg 2/4.

> 4. What's the best way to solve this problem?

Fix the station to send just one RSN IE in (Re)Association Request and
make sure it matches with the value sent in EAPOL-Key msg 2/4.

> I can send packet captures if anyone is interested.

I would like to see the capture log.

-- 
Jouni Malinen                                            PGP id EFC895FA