Hi Johannes, I changed the patch title from V3. The previous patch title was "mac80211: Send peering open frame again if beacon from listen state peer is received".
The comments from the mesh forks are as follows. http://marc.info/?l=linux-wireless&m=141590309208662&w=2 http://marc.info/?l=linux-wireless&m=141623146003341&w=2 -----Original Message----- From: Johannes Berg [mailto:[email protected]] Sent: Friday, December 12, 2014 8:42 PM To: Nishikawa, Kenzoh Cc: [email protected]; [email protected]; Bob Copeland ([email protected]); Thomas Pedersen ([email protected]) Subject: Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state On Fri, 2014-11-21 at 11:24 +0000, Nishikawa, Kenzoh wrote: > Instead of sending peer candidate events just once, send them as long > as the peer remains in the LISTEN state in the peering state machine, > when userspace is implementing the peering manager. > Userspace may silence the events from a peer by progressing the state > machine or by setting the link state to BLOCKED. > > Fixes the problem that a mesh peering process won't be fired again > after the previous first peering trial fails due to like air > propagation error if the peering is managed by user space such as > wpa_supplicant. > > This patch works with another patch for wpa_supplicant described here > which fires a peering process again triggered by the notice from > kernel. > http://lists.shmoo.com/pipermail/hostap/2014-November/031235.html Can any of the mesh folks comment on this? johannes _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
