wpa_supplicant: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
joey at caltech.edu
Tue Feb 14 17:21:56 EST 2006
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
> 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
More information about the HostAP