[PATCH v2] mac80211: Send peering open frame again if beacon from listen state peer is received

[PATCH v2] mac80211: Send peering open frame again if beacon from listen state peer is received

[Nishikawa, Kenzoh]

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

Signed-off-by: Kenzoh Nishikawa <Kenzoh.Nishikawa at jp.sony.com>
---
net/mac80211/mesh_plink.c |    7 +++++++
1 file changed, 7 insertions(+)

diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 32c7bd0..dfc429b 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -524,6 +524,13 @@ void mesh_neighbour_update(struct ieee80211_sub_if_data *sdata,
 	    sdata->u.mesh.mshcfg.auto_open_plinks &&
 	    rssi_threshold_check(sta, sdata))
 		changed = mesh_plink_open(sta);
+	else if (sta->plink_state == NL80211_PLINK_LISTEN &&
+		(sdata->u.mesh.user_mpm ||
+		sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED))
+		cfg80211_notify_new_peer_candidate(sdata->dev, hw_addr,
+							   elems->ie_start,
+							   elems->total_len,
+							   GFP_KERNEL);
 
 	ieee80211_mps_frame_release(sta, elems);
 out:

Re: [PATCH v2] mac80211: Send peering open frame again if beacon from listen state peer is received

[Bob Copeland]

On Mon, Nov 17, 2014 at 09:35:42AM +0000, Nishikawa, Kenzoh via Devel wrote:
> 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

I think this makes sense in principle.  I also checked authsae and it
should handle getting these additional events so no problems with
existing userspace.

However, some comments:

The subject doesn't really match what this does.  I would also describe
the new kernel behavior in the commit log in addition to the motivation.

Maybe something like this:

mac80211: keep sending peer candidate events while in listen state

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

> +		(sdata->u.mesh.user_mpm ||
> +		sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED))
> +		cfg80211_notify_new_peer_candidate(sdata->dev, hw_addr,
> +							   elems->ie_start,
> +							   elems->total_len,
> +							   GFP_KERNEL);

>From a cursory glance I think this needs to be GFP_ATOMIC -- don't you get
lockdep warnings?  (If not, make sure CONFIG_PROVE_LOCKING is enabled, and
that you aren't hitting other lockdep warnings prior to this code running.)
This code is in an RCU read critical section as far as I can tell.

-- 
Bob Copeland %% http://bobcopeland.com/

RE: [PATCH v2] mac80211: Send peering open frame again if beacon from listen state peer is received

[Nishikawa, Kenzoh]

> The subject doesn't really match what this does.  I would also describe
> the new kernel behavior in the commit log in addition to the motivation.
> 
> Maybe something like this:

Thank you for your comment. I will change the subject and the commit log.

> From a cursory glance I think this needs to be GFP_ATOMIC -- don't you get
> lockdep warnings?  (If not, make sure CONFIG_PROVE_LOCKING is enabled, and
> that you aren't hitting other lockdep warnings prior to this code running.)
> This code is in an RCU read critical section as far as I can tell.

Yes, this should be GFP_ATOMIC. I will change.