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

[Joey Richards]

Jouni,

FYI, I booted into Windows XP SP2 and set it up to use wpa_supplicant in 
place of the Windows wireless management.  It stayed connected for at 
least 8 hours without a problem.  I don't know enough about the protocol 
to know if this says anything, but it suggests to me that the AP is 
probably not misbehaving.

By the way, I am using wpa_supplicant 0.5.1 on both Windows and Linux.

I'm posting the log at 
http://www.its.caltech.edu/~joey/wpa_supplicant/windows-wpa-supplicant.log

joey


> From: Jouni Malinen <jkmaline at cc.hut.fi> Subject: Re: wpa_supplicant: WPA: EAPOL-Key Replay Counter did not increase - dropping packet To: hostap at shmoo.com Message-ID: <20060213035639.GB8579 at jm.kir.nu> Content-Type: text/plain; charset=us-ascii 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