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:johannes@xxxxxxxxxxxxxxxx] Sent: Friday, December 12, 2014 8:42 PM To: Nishikawa, Kenzoh Cc: linux-wireless@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxx; Bob Copeland (me@xxxxxxxxxxxxxxx); Thomas Pedersen (thomas@xxxxxxxx) 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 ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
