lost connectivity until "wpa_cli reassociate" is issued

[Jouni Malinen]

On Tue, Jan 05, 2016 at 12:28:24PM -0700, David Mosberger wrote:
> We do have debug and syslogging enabled, which already adds timestamps.
> 
> Attached is one example of a failure.  This failure resolved itself
> after about 6 hours, so I can't be sure that wpa_cli reassociate would
> have fixed it immediately.
> 
> In this instance, connectivity was fine as of 3:28am.  Around 3:44am,
> connectivity was lost (hostnames no longer resolve).  Finally, around
> 9:30am hostnames start to resolve again.  In between, there is some
> WPA traffic (about once an hour).  I anonymized the data in that part
> of the log (all hexdump output) but if more detail is needed, I can
> dig it out.

As far as I can tell, everything looked fine from wpa_supplicant view
point. The AP seems to be rekeying GTK (i.e., the key using to protected
broadcast/multicast frames in the network) once an hour. While there
were some retries of the group key handshake msg 1/2, no more than two
attempts was needed and all those cases concluded successfully.

This looks like an issue that would be more likely somewhere in the
driver side. Something could be going wrong in how the encryption keys
are configured and somehow this ends up dropping traffic either due to
an incorrect key being used or due to replay protection dropping frames.
In either case, there is not much that can be done with wpa_supplicant
debugging and one would need to debug driver behavior and/or get a full
capture trace of all the frames exchanged here through the association
from the beginning to a point where connectivity was lost (that could
then be decrypted and analyzed to see what is going wrong in the end).

-- 
Jouni Malinen                                            PGP id EFC895FA