| Message ID | 2EB4F5C65A3B8E4E92660930F4EF6B5B06C981@JPYOKXMS113.jp.sony.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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:
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(+) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html