[PATCH 11/12] mesh: Send peering open frame again if beacon from listen state peer is received
Bob Copeland
me
Wed Nov 5 05:09:46 PST 2014
On Wed, Nov 05, 2014 at 04:29:34PM +0900, Masashi Honma wrote:
> Ordinary processing is like this.
Ok, I see now, ap_sta_add() is called unconditionally. Sorry, I missed
that on previous reading.
> --------
> kernel: Receive a beacon from peer
> kernel: Fire notify_new_peer_candidate event
> wpa_supplicant: Receive EVENT_NEW_PEER_CANDIDATE event
> wpa_supplicant: Start peering
> wpa_supplicant: Success peering
> --------
>
> But peering can fail like this.
> --------
> kernel: Receive a beacon from peer
> kernel: Fire notify_new_peer_candidate event
> wpa_supplicant: Receive EVENT_NEW_PEER_CANDIDATE event
> wpa_supplicant: Start peering
> wpa_supplicant: *** FAIL *** peering (because of fail to receive
> peerinf frame etc...)
> kernel: Receive a beacon from peer
> kernel: Don't fire notify_new_peer_candidate event. Because of known peer
> wpa_supplicant: Can not start peering any more
> --------
Yes, I think what we should do in this case instead though is delete the sta
from the kernel when peering fails (or SAE/timeout or whatever). Then we'll
get NEW_PEER_CANDIDATE events again. This way, we don't get
NEW_PEER_CANDIDATE events on every single beacon.
I fixed a similar problem with authsae here:
https://github.com/cozybit/authsae/commit/295164a83717ce59ca280468fc2f7edcea6b3cbf
--
Bob Copeland %% www.bobcopeland.com
More information about the Hostap
mailing list