Group key negotiation failure with D-link AP leading to unstable connectivity?

[Jouni Malinen]

On Mon, Aug 02, 2004 at 02:13:50PM +0930, Duncan Grove wrote:

> Logs from "wpa_supplicant -D hermes -c/etc/wpa_supplicant.conf -dd" show 
> the following behaviour:
> 
> 1) wpa_supplicant scans for an AP and associates
> 2) pings to AP do not flow for 3 seconds
> 3) 4-way handshake for pairwise key succeeds
> 4) pings to AP flow for 10 seconds (wpa_state=GROUP_HANDSHAKE)
> 5) group key negotiation times out
> 6) repeat from step 1

Based on the debug logs, it looks clear that the problem is caused by
either client not receiving the Group Key message or AP not sending (at
least a valid) one.

Have you used a wireless sniffer to capture the packet exchange? That
should probide useful information about the real reason for this issue.

Some WPA implementations do not care about whether the Group Key
messages are encrypted even though the standard clearly specifies that
they must be encrypted. If the AP is sending unencrypted EAPOL-Key
packets when pairwise keys are configured (this would happen, e.g., if
Group Key handshake is using unencrypted packets), the client driver is
supposed to drop the frames. Since many Windows WPA implementations do
not verify this, number of APs (even Wi-Fi certified) may be using
incorrect frames without vendors and most testers even realizing this..

> After many, many hours of this broken operation the group key 
> negotiation finally succeeds (immediately after 
> wpa_driver_hermes_set_key above) and everything after that worked fine:

That's interesting.. Maybe there is some kind of race in which the AP
actually ends up finally encrypting the Group Key frame. The encryption
key is configured just before sending this frame which could explain the
race.

> I presume this is what is meant to happen all the time. It seems to me 
> like my AP is just not sending message 1 of the Group Key Handshake most 
> of the time and this is the source of my problem. Is this correct?

WPA is indeed supposed to use the Group Key exchange every time after
4-Way (PTK) Handshake. Your AP might be sending message 1 incorrectly
(unencrypted) in most case; wireless sniffer would tell this..

> I have also noticed a couple of other problems that may or may not be 
> related:
> 
> 1) If I stop and restart wpa_supplicant, the 4-way handshake gets stuck 
> in a rapidly repeating cycle of steps 1 and 2.

I'm not completely sure what you mean with steps 1 and 2 in this
context. This could be because of AP not clearing state properly after
new association or the client driver not actually associating again in
this case.

> 2) If I power off/power on the AP, it remains in wpa_supplicants scan 
> list, and I need to restart wpa_supplicant.

This seems to work with at least Host AP driver..

If you can send debug logs from wpa_supplicant that show these cases, I
could at least add them to my to do list as targets for more examination
at some point.

> Oh, and I have one final question: I have been able to find lots of 
> dicsussion about how often a WPA rekey happens (eg every minute, every 
> day, every 10,000 packets, etc) but I've seen hardly anything on how 
> long it takes when it does (for eg if reassociating with a new AP during 
> roaming). Is about 3 seconds (what I got above) normal, or very slow?

I would call that somewhat slow. I can completely full auth + assoc +
4-Way Handshake + Group Key handshake in well below one second even with
full debugging enabled (probably closer to 0.1 sec without debugging).
Anyway, this depends on the implementations and CPU speed to both the
client and AP, so the results are likely to vary quite a bit.

-- 
Jouni Malinen                                            PGP id EFC895FA