wpa_supplicant 4 way handshake timeout with some access points
ilan.peer at intel.com
Tue Dec 22 00:00:52 PST 2015
> -----Original Message-----
> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of
> Russell Senior
> Sent: Tuesday, December 22, 2015 06:15
> To: Jouni Malinen
> Cc: hostap at lists.infradead.org; Galen Seitz
> Subject: Re: wpa_supplicant 4 way handshake timeout with some access
> On Mon, Dec 21, 2015 at 2:14 PM, Jouni Malinen <j at w1.fi> wrote:
> > On Mon, Dec 21, 2015 at 11:52:32AM -0800, Galen Seitz wrote:
> >> We are also continuing to to work on collecting relevant
> >> time-correlated packet and wpa_supplicant logs. In the meantime, I
> >> thought I would ask whether anyone has any seen this type of problem
> >> and whether there is a fix or workaround.
> > There are way too many possible reasons for this type of issues to
> > even try to speculate on what could have happened without seeing those
> > In other words, I'd recommend trying again once the logs are available..
> Jouni, et al.
> Here are links to the wpa_supplicant log and an over-the-air packet capture
> made from a nearby device, respectively:
>From a quick look at the sniffer capture and log file, it seems that there is a delay between the time that 3/4 is
received on the station (and acked) to the time it is been processed by the wpa_supplicant. For example have a look
at packet # 1304, it is received immediately after 2/4 is acked, but 4/4 is not seen. After about 1 seconds the AP tries
to send 3/4 once again (different sequence number), and only afterward 4/4 is send. However, in the log it looks like
the first 3/4 is processed only after a delay of 1 sec., and this one is probably dropped by the AP.
Note that after this the other 3/4 are received and are being processed, but no keys are installed, as the keys are already installed.
You might want to check why the RX messages delayed in the driver.
More information about the Hostap