Re: WPA regression

[Jukka Salmi <j+nbsd%2008.salmi.ch@localhost>]

Jukka Salmi --> current-users (2008-02-06 23:01:02 +0100):
> It seems that not only wpa_supplicant but also hostapd is having
> problems on -current systems: I just upgraded my access point from
> netbsd-4 to HEAD (4.99.52 kernel, 4.99.50 userland, latest hostapd
> including todays fixes by Joerg) and noticed other systems are also
> having problems authenticating. This is what syslogd logged (with the
> station's address replaced by its operating system name):
> 
> Feb  6 15:01:18 clam hostapd: ath0: STA [macosx] IEEE 802.11: deauthenticated 
> due to local deauth request
> Feb  6 15:01:18 clam hostapd: ath0: STA [macosx] IEEE 802.11: deassociated
> Feb  6 15:01:21 clam hostapd: ath0: STA [macosx] IEEE 802.11: associated
> Feb  6 15:01:22 clam hostapd: ath0: STA [macosx] WPA: received EAPOL-Key 2/4 
> Pairwise with unexpected replay counter
> Feb  6 15:01:22 clam hostapd: ath0: STA [macosx] WPA: pairwise key handshake 
> completed (WPA)
> Feb  6 15:01:22 clam hostapd: ath0: STA [macosx] WPA: group key handshake 
> completed (WPA)
> Feb  6 15:11:16 clam hostapd: ath0: STA [macosx] WPA: received EAPOL-Key 2/2 
> Group with unexpected replay counter
> Feb  6 15:11:17 clam hostapd: ath0: STA [macosx] WPA: received EAPOL-Key 2/2 
> Group with unexpected replay counter
> Feb  6 15:11:17 clam hostapd: ath0: STA [macosx] WPA: group key handshake 
> completed (WPA)
> [...]
> Feb  6 19:01:19 clam hostapd: ath0: STA [win] IEEE 802.11: deauthenticated 
> due to local deauth request
> Feb  6 19:01:19 clam hostapd: ath0: STA [win] IEEE 802.11: deassociated
> Feb  6 19:01:19 clam hostapd: ath0: STA [win] IEEE 802.11: associated
> Feb  6 19:01:22 clam hostapd: ath0: STA [win] IEEE 802.11: deauthenticated 
> due to local deauth request
> Feb  6 19:01:22 clam hostapd: ath0: STA [win] IEEE 802.11: deassociated
> Feb  6 19:01:22 clam hostapd: ath0: STA [win] IEEE 802.11: associated
> Feb  6 19:01:25 clam hostapd: ath0: STA [win] IEEE 802.11: deassociated
> Feb  6 19:01:26 clam hostapd: ath0: STA [win] IEEE 802.11: associated
> Feb  6 19:01:27 clam hostapd: ath0: STA [win] WPA: received EAPOL-Key 2/2 
> Group with unexpected replay counter
> Feb  6 19:01:27 clam last message repeated 2 times
> Feb  6 19:01:27 clam hostapd: ath0: STA [win] WPA: received EAPOL-Key 2/4 
> Pairwise with unexpected replay counter
> Feb  6 19:01:27 clam last message repeated 5 times
> Feb  6 19:01:29 clam hostapd: ath0: STA [win] IEEE 802.11: deauthenticated 
> due to local deauth request
> Feb  6 19:01:29 clam hostapd: ath0: STA [win] IEEE 802.11: deassociated
> Feb  6 19:01:29 clam hostapd: ath0: STA [win] IEEE 802.11: associated
> Feb  6 19:01:30 clam hostapd: ath0: STA [win] WPA: received EAPOL-Key 2/4 
> Pairwise with unexpected replay counter
> Feb  6 19:01:31 clam hostapd: ath0: STA [win] WPA: pairwise key handshake 
> completed (WPA)
> Feb  6 19:01:31 clam hostapd: ath0: STA [win] WPA: group key handshake 
> completed (WPA)
> [...]
> Feb  6 22:31:06 clam hostapd: ath0: STA [nbsd] WPA: received EAPOL-Key 2/4 
> Pairwise with unexpected replay counter
> Feb  6 22:31:06 clam hostapd: ath0: STA [nbsd] WPA: pairwise key handshake 
> completed (WPA)
> Feb  6 22:31:07 clam hostapd: ath0: STA [nbsd] WPA: received EAPOL-Key 2/2 
> Group with unexpected replay counter
> Feb  6 22:31:07 clam hostapd: ath0: STA [nbsd] WPA: group key handshake 
> completed (WPA)

As another data point, I don't see any of those problems when running
-current's hostapd and wpa_supplicant (0.6.2) on netbsd-4 systems;
therefore I suspect it's not a hostapd/wpa_supplicant bug at all...
This makes sense since the problem [1]appeared after some changes from
the vmlocking branch were merged, without hostapd/wpa_supplicant being
modified.


Regards, Jukka

[1] http://mail-index.netbsd.org/current-users/2007/08/04/0009.html

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~