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

Bob Copeland me at bobcopeland.com
Wed Nov 5 08:09:46 EST 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