You're right, I did accidentally filter out acks. I have an updated filtered capture attached. It could be either, but I'm going off of wpa_supplicant instructing to transmit the 2nd EAPOL frame, but it never showing up in the air. The consultations I've received so far indicated that it would more likely be a driver/firmware issue, but I don't have enough experience with Linux supplicants to be sure about that. Steve Bateman Wireless Engineer ________________________________________ The FoundationGet Back To Work. 311 North 7th Avenue Minneapolis, MN 55401 612.465.0700 Main 612.787.3202 Direct 612.338.9322 Faxhttp://www.fndtn.com <http://www.fndtn.com/> Facebook <http://www.facebook.com/thefndtn> | Twitter <http://twitter.com/thefndtn> | LinkedIn <http://www.linkedin.com/companies/276539> On 1/20/14 4:33 AM, "Johannes Berg" <johannes@xxxxxxxxxxxxxxxx> wrote: >On Thu, 2014-01-09 at 19:13 +0000, Steven Bateman wrote: > >> I'm writing on behalf of about 4 or 5 users that are having issues >> connecting to a WLAN that I manage. The majority of the information can >>be >> found at the following link, including relevant logs. I've enclosed the >> packet capture from next to the station with failed authentications. > >How did you capture/filter the attached file? It shows no >acknowledgement of the EAPOL packets, but no retries either, so you >probably filtered out the acknowledgements. That leads me to believe >that maybe there was something wrong with those EAPOL frames, maybe >wpa_supplicant didn't get or didn't expect them? > >What makes you so sure it's a driver/firmware bug rather than a bug >related to wpa_supplicant or interaction with it? > >johannes >
Attachment:
bf4a73 updated.pcap
Description: bf4a73 updated.pcap
