To start with, let me tell you that this issue has been resolved by manually updating ndiswrapper (1.42 > 1.45) and wpa_supplicant (0.5.7 > 0.5.8). Had to build BOTH packages manually, because ubuntu package repositories didn't have the latest versions, but it fixed the problem.
<br><br>Meanwhile, to answer your questions in the hopes of solving future problems...<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> When was the last time you rebooted the devices (both the client and<br>> AP)? Has anything changed in software versions or configuration?</blockquote><div><br>Both devices were rebooted immediately upon experiencing the problem, and several more times throughout the course of the day.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Can you reproduce this issue every time?</blockquote><div><br>I could reproduce it ALMOST every time. Sometimes, apparently randomly, the device would NOT associate with the AP (giving me "association with 00:00:00...etc failed), followed immediately by 2-3 EAPOL-Key Reset Counter error messages in a row. This would repeat indefinitely until I killed wpa_supplicant. 9 times out of 10, however, the problem was exactly identical to the posted log.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> It looks like the 4-way handshake goes through fine, but for some reason the client does not
<br>> receive (or AP does not send) the first EAPOL-Key of the group key <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> handshake which would be the first encrypted frame on the connection. AP<br>> will likely end up disconnecting the client at this point and the replay<br>> counter issue is triggered by the client driver not reporting this
<br>> disassociation/re-association to the supplicant. Or well, that would at<br>> least be my guess on what is happening here.<br><br>> Could you please re-test this with -t added to the command line for time<br>
> stamps and with the other networks removed from (or disabled in) the<br>> configuration? I would like to see couple of attempts on connecting in<br>> order to be able to compare timing and frame contents between the
<br>> attempts.</blockquote><div><br>Worth noting, this problem also turned up the same day that I updated the Linux kernel to the most recent stable.<br><br>Now that I know the problem can be fixed with the newest versions of ndiswrapper and wpa_supplicant, I'd be willing to downgrade in an attempt to reproduce the problem if you think it would be worth it. Yes/no?
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--<br>Jouni Malinen PGP id EFC895FA<br>
_______________________________________________<br>HostAP mailing list<br><a href="mailto:HostAP@shmoo.com">HostAP@shmoo.com</a><br><a href="http://lists.shmoo.com/mailman/listinfo/hostap">http://lists.shmoo.com/mailman/listinfo/hostap
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Brian "Neatchee" Resnik<br>Host of Critical Hit and commentator<br>Inside the Game