[PATCH v4] mac80211: keep sending peer candidate events while in listen state

[PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Nishikawa, Kenzoh]

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

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_ATOMIC);
 
 	ieee80211_mps_frame_release(sta, elems);
 out:

Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Johannes Berg]

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

Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Bob Copeland (me@bobcopeland.com)]

On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote:
> 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?

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/

Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Johannes Berg]

On Fri, 2014-12-12 at 11:47 -0500, Bob Copeland (me@bobcopeland.com)
wrote:
> On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote:
> > 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?
> 
> 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

RE: [PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Nishikawa, Kenzoh]

SGkgSm9oYW5uZXMsDQoNCkkgY2hhbmdlZCB0aGUgcGF0Y2ggdGl0bGUgZnJvbSBWMy4gVGhlIHBy
ZXZpb3VzIHBhdGNoIHRpdGxlIHdhcyANCiJtYWM4MDIxMTogU2VuZCBwZWVyaW5nIG9wZW4gZnJh
bWUgYWdhaW4gaWYgYmVhY29uIGZyb20gbGlzdGVuIHN0YXRlIHBlZXIgaXMgcmVjZWl2ZWQiLg0K
DQpUaGUgY29tbWVudHMgZnJvbSB0aGUgbWVzaCBmb3JrcyBhcmUgYXMgZm9sbG93cy4NCmh0dHA6
Ly9tYXJjLmluZm8vP2w9bGludXgtd2lyZWxlc3MmbT0xNDE1OTAzMDkyMDg2NjImdz0yDQpodHRw
Oi8vbWFyYy5pbmZvLz9sPWxpbnV4LXdpcmVsZXNzJm09MTQxNjIzMTQ2MDAzMzQxJnc9Mg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWlsdG86
am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDEyLCAy
MDE0IDg6NDIgUE0NClRvOiBOaXNoaWthd2EsIEtlbnpvaA0KQ2M6IGxpbnV4LXdpcmVsZXNzQHZn
ZXIua2VybmVsLm9yZzsgZGV2ZWxAbGlzdHMub3BlbjgwMjExcy5vcmc7IEJvYiBDb3BlbGFuZCAo
bWVAYm9iY29wZWxhbmQuY29tKTsgVGhvbWFzIFBlZGVyc2VuICh0aG9tYXNAbm9hY2sudXMpDQpT
dWJqZWN0OiBSZTogW1BBVENIIHY0XSBtYWM4MDIxMToga2VlcCBzZW5kaW5nIHBlZXIgY2FuZGlk
YXRlIGV2ZW50cyB3aGlsZSBpbiBsaXN0ZW4gc3RhdGUNCg0KT24gRnJpLCAyMDE0LTExLTIxIGF0
IDExOjI0ICswMDAwLCBOaXNoaWthd2EsIEtlbnpvaCB3cm90ZToNCj4gSW5zdGVhZCBvZiBzZW5k
aW5nIHBlZXIgY2FuZGlkYXRlIGV2ZW50cyBqdXN0IG9uY2UsIHNlbmQgdGhlbSBhcyBsb25nIA0K
PiBhcyB0aGUgcGVlciByZW1haW5zIGluIHRoZSBMSVNURU4gc3RhdGUgaW4gdGhlIHBlZXJpbmcg
c3RhdGUgbWFjaGluZSwgDQo+IHdoZW4gdXNlcnNwYWNlIGlzIGltcGxlbWVudGluZyB0aGUgcGVl
cmluZyBtYW5hZ2VyLg0KPiBVc2Vyc3BhY2UgbWF5IHNpbGVuY2UgdGhlIGV2ZW50cyBmcm9tIGEg
cGVlciBieSBwcm9ncmVzc2luZyB0aGUgc3RhdGUgDQo+IG1hY2hpbmUgb3IgYnkgc2V0dGluZyB0
aGUgbGluayBzdGF0ZSB0byBCTE9DS0VELg0KPiANCj4gRml4ZXMgdGhlIHByb2JsZW0gdGhhdCBh
IG1lc2ggcGVlcmluZyBwcm9jZXNzIHdvbid0IGJlIGZpcmVkIGFnYWluIA0KPiBhZnRlciB0aGUg
cHJldmlvdXMgZmlyc3QgcGVlcmluZyB0cmlhbCBmYWlscyBkdWUgdG8gbGlrZSBhaXIgDQo+IHBy
b3BhZ2F0aW9uIGVycm9yIGlmIHRoZSBwZWVyaW5nIGlzIG1hbmFnZWQgYnkgdXNlciBzcGFjZSBz
dWNoIGFzIA0KPiB3cGFfc3VwcGxpY2FudC4NCj4gDQo+IFRoaXMgcGF0Y2ggd29ya3Mgd2l0aCBh
bm90aGVyIHBhdGNoIGZvciB3cGFfc3VwcGxpY2FudCBkZXNjcmliZWQgaGVyZSANCj4gd2hpY2gg
ZmlyZXMgYSBwZWVyaW5nIHByb2Nlc3MgYWdhaW4gdHJpZ2dlcmVkIGJ5IHRoZSBub3RpY2UgZnJv
bSANCj4ga2VybmVsLg0KPiBodHRwOi8vbGlzdHMuc2htb28uY29tL3BpcGVybWFpbC9ob3N0YXAv
MjAxNC1Ob3ZlbWJlci8wMzEyMzUuaHRtbA0KDQpDYW4gYW55IG9mIHRoZSBtZXNoIGZvbGtzIGNv
bW1lbnQgb24gdGhpcz8NCg0Kam9oYW5uZXMNCg0K

Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Johannes Berg]

On Fri, 2014-11-21 at 11:24 +0000, 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