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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
