Yeah, you're right and thanks for the reply! I later realize I made wrong conclusion. I looked further and saw lots of timeout happened: Aug 1 20:30:43 daemon.debug wpa_supplicant[2358]: wlan1: ap_handle_timer: a0:76:2f:00:1f:04 flags=0xe00 timeout_next=0 Aug 1 20:30:43 daemon.debug wpa_supplicant[2358]: wlan1: Timeout, sending disassociation info to STA a0:76:2f:00:1f:04 We did increase the SAE timeout from 30ms to 200ms but it didn't help. Wonder whether this is triggered by a different timeout. Will dig further. Thanks! On Thu, Aug 2, 2018 at 7:00 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > On Thu, Aug 02, 2018 at 01:22:59PM -0700, Joshua Zhao wrote: >> Hi, >> I'm running the open source 11s mesh with QCA Dakota radios. But as we >> set up more spaces, say > 4 spaces, mesh authentication starts to >> become difficult. As I look into the code, it appears to me that the >> SAE state machine is not tracking/identifying the peers? So when the >> commit & confirm messages between multiple peers interleave each >> other, the state machine either sees ECC/FFC mismatch or keeps >> resetting the states. >> >> Is my observation correct? And is this a known issue? > > The peers are tracked: this is what the sta parameter in sae_sm_step() is > for. What hardware is this? Some devices have limits in terms of the > number of peers or keys they can handle. > > -- > Bob Copeland %% https://bobcopeland.com/ _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
