lost connectivity until "wpa_cli reassociate" is issued
davidm at egauge.net
Tue Jan 5 15:43:54 PST 2016
Thanks for your analysis!
On Tue, Jan 5, 2016 at 1:24 PM, Jouni Malinen <j at w1.fi> wrote:
> On Tue, Jan 05, 2016 at 12:28:24PM -0700, David Mosberger wrote:
> 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.
Is it normal that "only" the key for broadcast/multicast would be
re-keyed once an hour? Or is there a separate key for the AP that
should be re-keyed? I'm trying to understand what the difference is
between the re-keying that is happening and what "reassociate" does.
I'm hoping that will help me narrow down what to look at in the
> 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).
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
More information about the Hostap