wpa_supplicant: WPA: EAPOL-Key Replay Counter did not increase - dropping packet

[Jouni Malinen]

On Sat, Feb 11, 2006 at 12:12:07PM -0800, Joey Richards wrote:

> I am suffering from the same problem as Vidar.  I'm running on an AMD 
> Turion laptop with kernel 2.6.15-r1 built for x86_64.  My wireless card 
> is a Broadcom, using the bcmwl5a 64-bit driver through ndiswrapper.  I 
> connect to a Netgear WGR614 wireless router using WPA-PSK.
> 
> I have collected two logs -- one is an annotated log from wpa_supplicant 
> with the -ddt option (search for <<<<< to find my comments).  The other 
> is the iwevent log from the same period.  These are available at
> http://www.its.caltech.edu/~joey/wpa_supplicant

Thanks for the debug log.

> What you'll see in the logs is my connecting to the access point 
> (bork-wireless), accompanied by a couple events in the iwevent log. 
> About 7 minutes later, wpa_supplicant successfully handshakes with no 
> event in the iwevent log.  Next, about half an hour later, it attempts 
> to handshake, fails due to the "Replay Counter" error, and repeats until 
> I noticed the connection had died.

The initial handshake and the following group key update (the first case
that did not show up in iwevent log) are working fine. After this (30
min later), the AP seems to start re-authentication by sending 4-way
message 1/4. However, this is using a replay counter that did not
increment from the previously used value and as such, the supplicant is
required to drop the frame to avoid replay attacks.

There are two possible explanations for this:
1) there was (re-)association, but the association event was lost
   somewhere (association clears the replay counter, so the new frame
   would have been valid)
2) the AP has a bug in re-authentication case

In order to determine, which one is the cause here, a wireless capture
log would be needed. Do you happen to have access to another device that
could be used to capture the frames exchanged between the AP and
station at the time the replay counter errors started? If the log
includes 802.11 association request/response just before the ignored
EAPOL-Key frame (which would also be unencrypted in this case),
explanation (1) would be valid. Otherwise, explanation (2) sounds like
more likely reason for this. In that case, the EAPOL-Key frame should
actually be encrypted and it may not be that clearly visible in the
capture log.


I've opened a Bugzilla case to collect reports relating to this kind of
issues into one place: http://hostap.epitest.fi/bugz/show_bug.cgi?id=113

-- 
Jouni Malinen                                            PGP id EFC895FA