Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state
On Fri, 2014-12-12 at 11:47 -0500, Bob Copeland (m...@bobcopeland.com) wrote: On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote: On Fri, 2014-11-21 at 11:24 +, 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? I think it's fine. It's not strictly necessary: userspace could run its own timers to restart peering with any unpeered candidates periodically, but doing it based on beacon arrival is a little better since it indicates the peer is still alive, and this is also exactly how the in-kernel MPM operates. Great, thanks. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state
On Fri, 2014-11-21 at 11:24 +, Nishikawa, Kenzoh wrote: + cfg80211_notify_new_peer_candidate(sdata-dev, hw_addr, +elems-ie_start, +elems-total_len, +GFP_ATOMIC); Please indent properly (to align after the opening parenthesis) johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] mac80211: keep sending peer candidate events while in listen state
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-wirelessm=141590309208662w=2
http://marc.info/?l=linux-wirelessm=141623146003341w=2
-Original Message-
From: Johannes Berg [mailto:johan...@sipsolutions.net]
Sent: Friday, December 12, 2014 8:42 PM
To: Nishikawa, Kenzoh
Cc: linux-wireless@vger.kernel.org; de...@lists.open80211s.org; Bob Copeland
(m...@bobcopeland.com); Thomas Pedersen (tho...@noack.us)
Subject: Re: [PATCH v4] mac80211: keep sending peer candidate events while in
listen state
On Fri, 2014-11-21 at 11:24 +, 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�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state
On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote: On Fri, 2014-11-21 at 11:24 +, 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? I think it's fine. It's not strictly necessary: userspace could run its own timers to restart peering with any unpeered candidates periodically, but doing it based on beacon arrival is a little better since it indicates the peer is still alive, and this is also exactly how the in-kernel MPM operates. -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
