hi Wolfgang, On Thu, Dec 2, 2010 at 4:24 PM, Wolfgang Breyha <wbreyha@xxxxxxx> wrote: > But introducing a usleep(100000) in > wpa_supplicant/src/eap_peer/eap.c:136, or in other words.... >> wpa_supplicant logs: >> >>> 1291215721.998646: Process pending EAPOL frame that was received just before association notification >>> 1291215721.998677: RX EAPOL from 00:26:cb:xx:xx:xx >>> 1291215721.998713: Setting authentication timeout: 70 sec 0 usec >>> 1291215721.998747: EAPOL: Received EAP-Packet frame >>> 1291215721.998778: EAPOL: SUPP_PAE entering state RESTART >>> 1291215721.998806: EAP: EAP entering state INITIALIZE > ............ HERE ................ >>> 1291215721.998835: EAP: EAP entering state IDLE >>> 1291215721.998865: EAPOL: SUPP_PAE entering state AUTHENTICATING >>> 1291215721.998895: EAPOL: SUPP_BE entering state REQUEST >>> 1291215721.998924: EAPOL: getSuppRsp >>> 1291215721.998952: EAP: EAP entering state RECEIVED > > I haven't found the source of this race condition which causes this. The > reason why it only happens on 5GHz channels is unknown as well. > sounds a bit similar to another case i've encountered: http://lists.shmoo.com/pipermail/hostap/2010-November/021940.html Eliad. -- 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
