On Tuesday 16 December 2008 22:25:32 Larry Finger wrote: > Christian Lamparter wrote: > > > > and when the traffic dies down, does iwlist wlanX still give you a > > reasonable output, > > Yes - the AP scan is normal. well, so the receiver sort of works. > > > > or has NM some sort of cli interface (e.g: wpa_cli ) because I would > > like to see what > > > > the station supplicant is doing...? > > I switched to ifup/down control. It seems that wpa_supplicant is getting > confused. Attached is a -ddd dump. > > BTW, dmesg does not show anything - nothing is logged. Some of those > wpa_supplicant reconnection events did not kill the connection, but eventually > it does not recover. I did the same test with rtl8187 and found the same kind of > sequences such as > > EAPOL: SUPP_PAE entering state CONNECTING > EAPOL: txStart > WPA: drop TX EAPOL in non-IEEE 802.1X mode (type=1 len=0) > ^CCTRL-EVENT-TERMINATING - signal 2 received > Removing interface wlan1 > State: 4WAY_HANDSHAKE -> DISCONNECTED > wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) > WEXT: Operstate: linkmode=-1, operstate=5 > wpa_driver_wext_deauthenticate > No keys have been configured - skip key clearing > EAPOL: External notification - portEnabled=0 > EAPOL: SUPP_PAE entering state DISCONNECTED > EAPOL: SUPP_BE entering state INITIALIZE > EAPOL: External notification - portValid=0 > wpa_driver_wext_set_wpa > wpa_driver_wext_set_drop_unencrypted > wpa_driver_wext_set_countermeasures > WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported > No keys have been configured - skip key clearing > > When these happen, the flood ping is interrupted with rtl8187 but it always > recovers. I don't remember this behavior from earlier, but it still happens with > 2.6.25 - it doesn't seem to be a mac80211 regression. > > Larry well, looks like TKIP countermeasures after all.... The question is how to "debug" it... jm, are you aware of any compatibility problems or regression between broadcom APs and wpa_supplicant with WPA TKIP? I just added the extract of wpa_supplicant logs that looked important: WPA: Invalid EAPOL-Key MIC when using TPTK - ignoring TPTK WPA: Could not verify EAPOL-Key MIC - dropping packet RTM_NEWLINK: operstate=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP]) [...] WPA: Invalid EAPOL-Key MIC when using TPTK - ignoring TPTK WPA: Could not verify EAPOL-Key MIC - dropping packet [...] Authentication with XX:XX:XX:XX:XX:b1 timed out. Added BSSID XX:XX:XX:XX:XX:b1 into blacklist [...] WPA: Invalid EAPOL-Key MIC when using TPTK - ignoring TPTK WPA: Could not verify EAPOL-Key MIC - dropping packet EAPOL: startWhen --> 0 [...] Authentication with XX:XX:XX:XX:XX:b1 timed out. BSSID XX:XX:XX:XX:XX:b1 blacklist count incremented to 2 [...] 1: XX:XX:XX:XX:XX:b1 ssid='Larry' wpa_ie_len=26 rsn_ie_len=0 caps=0x11 skip - blacklisted [...] No APs found - clear blacklist and try again Removed BSSID 00:00:00:00:00:00 from blacklist (clear) Removed BSSID XX:XX:XX:XX:XX:b1 from blacklist (clear) [...] State: DISCONNECTED -> ASSOCIATING wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) WEXT: Operstate: linkmode=-1, operstate=5 wpa_driver_wext_associate wpa_driver_wext_associate: assoc failed because set_mode failed Association request to the driver failed [...] WPA: Invalid EAPOL-Key MIC when using TPTK - ignoring TPTK WPA: Could not verify EAPOL-Key MIC - dropping packet [.......] Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
