[PATCH 11/12] mesh: Send peering open frame again if beacon from listen state peer is received

Masashi Honma masashi.honma
Fri Nov 7 00:11:33 PST 2014

I think I need to consider more about this.

So I will drop this patch from the patch set for now.

As thomas said, to use scan result is reasonable way (thanks thomas).
Because the sequence scan -> find peer -> connect -> timeout -> scan -> ... is
similar to infrastructure BSS.
If NEW_PEER_CANDIDATE based connection trigger can not avoid this issue,
I will consider scan based.

2014-11-06 19:29 GMT+09:00 Nishikawa, Kenzoh <Kenzoh.Nishikawa at jp.sony.com>:
>> 2014-11-05 22:09 GMT+09:00 Bob Copeland <me at bobcopeland.com>:
>>> I fixed a similar problem with authsae here:
>>> https://github.com/cozybit/authsae/commit/295164a83717ce59ca280468fc2f7edcea6b3cbf
>> Great!
>> I could fix this problem by adding one line based on your idea.
>> Thank you !
> I found the problem for this solution.
> NodeA registers NodeB by receiving the beacon and sends open frames.
> But NodeB ignore the open frames because NodeB has not registered NodeA.
> So NodeA goes to Holding state and forget NodeB by the solution.
> Then NodeB starts sending open frames after receiving the NodeA beacon
> and fails since NodeA doesn't remember NodeB anymore.
> And repeats this forever.
> Nearly same problem happens when a peer is deleted since mesh_mpm_fsm_restart()
> is called with the reason code "WLAN_REASON_MESH_CLOSE_RCVD".

More information about the Hostap mailing list