| Message ID | 1399038031-23206-1-git-send-email-luca@coelho.fi (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, 2014-05-02 at 16:40 +0300, Luca Coelho wrote: > + * @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY: Notify that a channel switch > + * has been started on an interface, regardless of the initiator > + * (ie. whether it was requested from a remote device or > + * initiated on our own). It indicates that > + * %NL80211_ATTR_IFINDEX will be on %NL80211_ATTR_WIPHY_FREQ > + * after %NL80211_ATTR_CH_SWITCH_COUNT TBTT's. You don't seem to have that now, but it may not always be needed, and we could add it later (unless userspace needs to rely on having the attribute - otherwise it has to check for it) Actually though, maybe you do need it, so that you can determine whether it makes sense to try anything smart - if the count is 1 or you received an action frame then you probably don't have time at all? > + * @NL80211_CMD_CH_SWITCH_FAILED_NOTIFY: Notify that a channel switch > + * has failed on %NL80211_ATTR_IFINDEX. This notification can > + * only be sent after a @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY has > + * been issued. (+Ilan, Andrei) I'm not really sure why you have this - it seems that in this case the interface will be stopped so you'll get a STOP_AP or DISCONNECT or whatever other notification. This may not actually be completely true right now (I seem to remember a fix in this area but can't seem to find it in my tree!!) but we'll have to fix that part anyway. Not really sure why then that couldn't be used instead of this notification? The userspace code is going to have to worry about that anyway, I'd think. 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-05-02 at 16:40 +0300, Luca Coelho wrote: > + * @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY: Notify that a channel switch > + * has been started on an interface, regardless of the initiator > + * (ie. whether it was requested from a remote device or > + * initiated on our own). It indicates that > + * %NL80211_ATTR_IFINDEX will be on %NL80211_ATTR_WIPHY_FREQ > + * after %NL80211_ATTR_CH_SWITCH_COUNT TBTT's. You don't seem to have that now, but it may not always be needed, and we could add it later (unless userspace needs to rely on having the attribute - otherwise it has to check for it) Actually though, maybe you do need it, so that you can determine whether it makes sense to try anything smart - if the count is 1 or you received an action frame then you probably don't have time at all? > + * @NL80211_CMD_CH_SWITCH_FAILED_NOTIFY: Notify that a channel switch > + * has failed on %NL80211_ATTR_IFINDEX. This notification can > + * only be sent after a @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY has > + * been issued. (+Ilan, Andrei) I'm not really sure why you have this - it seems that in this case the interface will be stopped so you'll get a STOP_AP or DISCONNECT or whatever other notification. This may not actually be completely true right now (I seem to remember a fix in this area but can't seem to find it in my tree!!) but we'll have to fix that part anyway. Not really sure why then that couldn't be used instead of this notification? The userspace code is going to have to worry about that anyway, I'd think. 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 6 May 2014 12:47, Johannes Berg <johannes@sipsolutions.net> wrote: > On Fri, 2014-05-02 at 16:40 +0300, Luca Coelho wrote: > >> + * @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY: Notify that a channel switch >> + * has been started on an interface, regardless of the initiator >> + * (ie. whether it was requested from a remote device or >> + * initiated on our own). It indicates that >> + * %NL80211_ATTR_IFINDEX will be on %NL80211_ATTR_WIPHY_FREQ >> + * after %NL80211_ATTR_CH_SWITCH_COUNT TBTT's. > > You don't seem to have that now, but it may not always be needed, and we > could add it later (unless userspace needs to rely on having the > attribute - otherwise it has to check for it) > > Actually though, maybe you do need it, so that you can determine whether > it makes sense to try anything smart - if the count is 1 or you received > an action frame then you probably don't have time at all? > >> + * @NL80211_CMD_CH_SWITCH_FAILED_NOTIFY: Notify that a channel switch >> + * has failed on %NL80211_ATTR_IFINDEX. This notification can >> + * only be sent after a @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY has >> + * been issued. > > (+Ilan, Andrei) > > I'm not really sure why you have this - it seems that in this case the > interface will be stopped so you'll get a STOP_AP or DISCONNECT or > whatever other notification. This may not actually be completely true > right now (I seem to remember a fix in this area but can't seem to find > it in my tree!!) but we'll have to fix that part anyway. Not really sure > why then that couldn't be used instead of this notification? The > userspace code is going to have to worry about that anyway, I'd think. Just a reminder - there's my pending patchset (mac80211/cfg80211: CSA fixes/cleanups) for CSA that disconnects interfaces that fail to switch channel. Perhaps I should re-post? Micha? -- 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 Tue, 2014-05-06 at 14:49 +0200, Michal Kazior wrote: > > (I seem to remember a fix in this area but can't seem to find > > it in my tree!!) > > Just a reminder - there's my pending patchset (mac80211/cfg80211: CSA > fixes/cleanups) for CSA that disconnects interfaces that fail to > switch channel. Perhaps I should re-post? D'oh. No, I have it, I'll pick it up. I just forgot - there was some minor thing with it and I thought Luca might pick it up, so I dropped it. I'll go look at it now. 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
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgtd2lyZWxlc3Mt b3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+IG93bmVyQHZn ZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEpvaGFubmVzIEJlcmcNCj4gU2VudDogVHVlc2Rh eSwgTWF5IDA2LCAyMDE0IDEzOjQ3DQo+IFRvOiBMdWNhIENvZWxobw0KPiBDYzogbGludXgtd2ly ZWxlc3NAdmdlci5rZXJuZWwub3JnOyBtaWNoYWwua2F6aW9yQHRpZXRvLmNvbTsgUGVlciwgSWxh bjsNCj4gT3RjaGVyZXRpYW5za2ksIEFuZHJlaQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvNF0g Y2ZnODAyMTEvbmw4MDIxMTogYWRkIGNoYW5uZWwgc3dpdGNoIHN0YXJ0ZWQgYW5kDQo+IGZhaWxl ZCBub3RpZmljYXRpb25zDQo+IA0KPiBPbiBGcmksIDIwMTQtMDUtMDIgYXQgMTY6NDAgKzAzMDAs IEx1Y2EgQ29lbGhvIHdyb3RlOg0KPiANCj4gPiArICogQE5MODAyMTFfQ01EX0NIX1NXSVRDSF9T VEFSVEVEX05PVElGWTogTm90aWZ5IHRoYXQgYSBjaGFubmVsDQo+IHN3aXRjaA0KPiA+ICsgKglo YXMgYmVlbiBzdGFydGVkIG9uIGFuIGludGVyZmFjZSwgcmVnYXJkbGVzcyBvZiB0aGUgaW5pdGlh dG9yDQo+ID4gKyAqCShpZS4gd2hldGhlciBpdCB3YXMgcmVxdWVzdGVkIGZyb20gYSByZW1vdGUg ZGV2aWNlIG9yDQo+ID4gKyAqCWluaXRpYXRlZCBvbiBvdXIgb3duKS4gIEl0IGluZGljYXRlcyB0 aGF0DQo+ID4gKyAqCSVOTDgwMjExX0FUVFJfSUZJTkRFWCB3aWxsIGJlIG9uICVOTDgwMjExX0FU VFJfV0lQSFlfRlJFUQ0KPiA+ICsgKglhZnRlciAlTkw4MDIxMV9BVFRSX0NIX1NXSVRDSF9DT1VO VCBUQlRUJ3MuDQo+IA0KPiBZb3UgZG9uJ3Qgc2VlbSB0byBoYXZlIHRoYXQgbm93LCBidXQgaXQg bWF5IG5vdCBhbHdheXMgYmUgbmVlZGVkLCBhbmQgd2UNCj4gY291bGQgYWRkIGl0IGxhdGVyICh1 bmxlc3MgdXNlcnNwYWNlIG5lZWRzIHRvIHJlbHkgb24gaGF2aW5nIHRoZSBhdHRyaWJ1dGUgLQ0K PiBvdGhlcndpc2UgaXQgaGFzIHRvIGNoZWNrIGZvciBpdCkNCj4gDQo+IEFjdHVhbGx5IHRob3Vn aCwgbWF5YmUgeW91IGRvIG5lZWQgaXQsIHNvIHRoYXQgeW91IGNhbiBkZXRlcm1pbmUgd2hldGhl ciBpdA0KPiBtYWtlcyBzZW5zZSB0byB0cnkgYW55dGhpbmcgc21hcnQgLSBpZiB0aGUgY291bnQg aXMgMSBvciB5b3UgcmVjZWl2ZWQgYW4gYWN0aW9uDQo+IGZyYW1lIHRoZW4geW91IHByb2JhYmx5 IGRvbid0IGhhdmUgdGltZSBhdCBhbGw/DQo+IA0KPiA+ICsgKiBATkw4MDIxMV9DTURfQ0hfU1dJ VENIX0ZBSUxFRF9OT1RJRlk6IE5vdGlmeSB0aGF0IGEgY2hhbm5lbA0KPiBzd2l0Y2gNCj4gPiAr ICoJaGFzIGZhaWxlZCBvbiAlTkw4MDIxMV9BVFRSX0lGSU5ERVguICBUaGlzIG5vdGlmaWNhdGlv biBjYW4NCj4gPiArICoJb25seSBiZSBzZW50IGFmdGVyIGEgQE5MODAyMTFfQ01EX0NIX1NXSVRD SF9TVEFSVEVEX05PVElGWQ0KPiBoYXMNCj4gPiArICoJYmVlbiBpc3N1ZWQuDQo+IA0KPiAoK0ls YW4sIEFuZHJlaSkNCj4gDQo+IEknbSBub3QgcmVhbGx5IHN1cmUgd2h5IHlvdSBoYXZlIHRoaXMg LSBpdCBzZWVtcyB0aGF0IGluIHRoaXMgY2FzZSB0aGUgaW50ZXJmYWNlDQo+IHdpbGwgYmUgc3Rv cHBlZCBzbyB5b3UnbGwgZ2V0IGEgU1RPUF9BUCBvciBESVNDT05ORUNUIG9yIHdoYXRldmVyIG90 aGVyDQo+IG5vdGlmaWNhdGlvbi4gVGhpcyBtYXkgbm90IGFjdHVhbGx5IGJlIGNvbXBsZXRlbHkg dHJ1ZSByaWdodCBub3cgKEkgc2VlbSB0bw0KPiByZW1lbWJlciBhIGZpeCBpbiB0aGlzIGFyZWEg YnV0IGNhbid0IHNlZW0gdG8gZmluZCBpdCBpbiBteSB0cmVlISEpIGJ1dCB3ZSdsbA0KPiBoYXZl IHRvIGZpeCB0aGF0IHBhcnQgYW55d2F5LiBOb3QgcmVhbGx5IHN1cmUgd2h5IHRoZW4gdGhhdCBj b3VsZG4ndCBiZSB1c2VkDQo+IGluc3RlYWQgb2YgdGhpcyBub3RpZmljYXRpb24/IFRoZSB1c2Vy c3BhY2UgY29kZSBpcyBnb2luZyB0byBoYXZlIHRvIHdvcnJ5DQo+IGFib3V0IHRoYXQgYW55d2F5 LCBJJ2QgdGhpbmsuDQo+IA0KDQpBdCBsZWFzdCBmb3IgQVAvR08sIHRoZXJlIGFyZSBjYXNlcyB0 aGF0IGEgZmFpbGVkIGNoYW5uZWwgc3dpdGNoIHNob3VsZCBub3QgbmVjZXNzYXJpbHkgdHJpZ2dl ciBhIFNUT1BfQVAgZmxvdy4gRm9yIGV4YW1wbGUsIGluIGNhc2UgdGhhdCBtdWx0aS1jaGFubmVs IGlzIHN1cHBvcnRlZCwgd3BhX3N1cHBsaWNhbnQgbWlnaHQgcmVxdWVzdCBhIGNoYW5uZWwgc3dp dGNoIHRvIHRyeSB0byBzd2l0Y2ggYW4gQVAvR08gaW50ZXJmYWNlIHRvIGEgY2hhbm5lbCB1c2Vk IGJ5IGEgc3RhdGlvbiBpbnRlcmZhY2UgKHRvIGF2b2lkIG11bHRpIGNoYW5uZWwgb3BlcmF0aW9u KSwgYnV0IGluIGNhc2UgdGhhdCBzdWNoIGEgdHJhbnNpdGlvbiBmYWlscywgaXQgaXMgc3RpbGwg YSB2YWxpZCB0byBjb250aW51ZSB0byB1c2UgY3VycmVudCBjaGFubmVsIGFuZCBkbyBub3Qgc3Rv cCB0aGUgR08uIEluIHN1Y2ggYSBjYXNlLCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZ2V0IGEgZmFp bHVyZSBub3RpZmljYXRpb24uIEdlbmVyYWxseSwgSSB0aGluayB0aGF0IHNpbmNlIGhvc3RhcGQv d3BhX3N1cHBsaWNhbnQgaGF2ZSBzdGFydGVkIHRoZSBjaGFubmVsIHN3aXRjaCwgaXQgbWlnaHQg YmUgYmV0dGVyIHRvIGhhdmUgdGhlbSBoYW5kbGUgYSBub3RpZmljYXRpb24gYW5kIHRha2UgdGhl IGFwcHJvcHJpYXRlIGFjdGlvbiAoaWYgbmVlZGVkIHN0b3AgdGhlIEFQL0dPIC4uLikuIA0KDQpP dGhlciB0aGFuIHRoYXQsIGEgU1RPUF9BUCBtaWdodCBpbnRyb2R1Y2Ugc29tZSByYWNlcywgYXMg d3BhX3N1cHBsaWNhbnQvaG9zdGFwIHdpbGwgbm90IGtub3cgaWYgdGhlIHN0b3BfYXAgd2FzIGR1 ZSB0byB0aGUgZmFpbGVkIENTIG9yIGR1ZSB0byBzb21lIG90aGVyIHJlYXNvbi4NCg0KUmVnYXJk cywNCg0KSWxhbi4NCg0K -- 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 Wed, 2014-05-07 at 06:08 +0000, Peer, Ilan wrote: > > I'm not really sure why you have this - it seems that in this case the interface > > will be stopped so you'll get a STOP_AP or DISCONNECT or whatever other > > notification. This may not actually be completely true right now (I seem to > > remember a fix in this area but can't seem to find it in my tree!!) but we'll > > have to fix that part anyway. Not really sure why then that couldn't be used > > instead of this notification? The userspace code is going to have to worry > > about that anyway, I'd think. > > > > At least for AP/GO, there are cases that a failed channel switch > should not necessarily trigger a STOP_AP flow. For example, in case > that multi-channel is supported, wpa_supplicant might request a > channel switch to try to switch an AP/GO interface to a channel used > by a station interface (to avoid multi channel operation), but in case > that such a transition fails, it is still a valid to continue to use > current channel and do not stop the GO. In such a case, it would be > useful to get a failure notification. Generally, I think that since > hostapd/wpa_supplicant have started the channel switch, it might be > better to have them handle a notification and take the appropriate > action (if needed stop the AP/GO ...). I don't understand this - there are two ways the channel switch can fail: * the request fails this just returns an error code to userspace during the request, there's no notification even with these patches * the request succeeds, but real switch fails we beacon with the CSA, counting it down etc., but when it comes to actually switching, the switch fails. This should hopefully be rather unlikely, but if it really happens the only thing we can do to recover (and actually do now after Michal's patches) is to STOP_AP In the first case, there's no notification, nor any need for it. In the second case, the scenario you suggest doesn't apply, and STOP_AP has to happen anyway because the state is completely messed up, clients will be in the process of switching etc. > Other than that, a STOP_AP might introduce some races, as > wpa_supplicant/hostap will not know if the stop_ap was due to the > failed CS or due to some other reason. I don't see why that would matter - even if the STOP_AP *was* for some other reason, but happened in the middle of the CS flow, the reaction would presumably be the same? 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
> > > > I'm not really sure why you have this - it seems that in this case > > > the interface will be stopped so you'll get a STOP_AP or DISCONNECT > > > or whatever other notification. This may not actually be completely > > > true right now (I seem to remember a fix in this area but can't seem > > > to find it in my tree!!) but we'll have to fix that part anyway. Not > > > really sure why then that couldn't be used instead of this > > > notification? The userspace code is going to have to worry about that > anyway, I'd think. > > > > > > > At least for AP/GO, there are cases that a failed channel switch > > should not necessarily trigger a STOP_AP flow. For example, in case > > that multi-channel is supported, wpa_supplicant might request a > > channel switch to try to switch an AP/GO interface to a channel used > > by a station interface (to avoid multi channel operation), but in case > > that such a transition fails, it is still a valid to continue to use > > current channel and do not stop the GO. In such a case, it would be > > useful to get a failure notification. Generally, I think that since > > hostapd/wpa_supplicant have started the channel switch, it might be > > better to have them handle a notification and take the appropriate > > action (if needed stop the AP/GO ...). > > I don't understand this - there are two ways the channel switch can > fail: > > * the request fails > this just returns an error code to userspace during the request, there's no > notification even with these patches > * the request succeeds, but real switch fails > we beacon with the CSA, counting it down etc., but when it comes to > actually > switching, the switch fails. This should hopefully be rather unlikely, but if > it really happens the only thing we can do to recover (and actually do now > after Michal's patches) is to STOP_AP > Yep, agree that the only valid option here is to stop the AP. > In the first case, there's no notification, nor any need for it. In the second > case, the scenario you suggest doesn't apply, and STOP_AP has to happen > anyway because the state is completely messed up, clients will be in the > process of switching etc. > > > Other than that, a STOP_AP might introduce some races, as > > wpa_supplicant/hostap will not know if the stop_ap was due to the > > failed CS or due to some other reason. > > I don't see why that would matter - even if the STOP_AP *was* for some > other reason, but happened in the middle of the CS flow, the reaction would > presumably be the same? > It can be beneficial to know that the STOP_AP was called due to failure of CS, as wpa_supplicant/hostap can tear down the AP and then (if possible) set it up again on the new channel or another channel. Regards, Ilan.
On Wed, 2014-05-07 at 10:27 +0000, Peer, Ilan wrote: > > In the first case, there's no notification, nor any need for it. In the second > > case, the scenario you suggest doesn't apply, and STOP_AP has to happen > > anyway because the state is completely messed up, clients will be in the > > process of switching etc. > > > > > Other than that, a STOP_AP might introduce some races, as > > > wpa_supplicant/hostap will not know if the stop_ap was due to the > > > failed CS or due to some other reason. > > > > I don't see why that would matter - even if the STOP_AP *was* for some > > other reason, but happened in the middle of the CS flow, the reaction would > > presumably be the same? > > > > It can be beneficial to know that the STOP_AP was called due to > failure of CS, as wpa_supplicant/hostap can tear down the AP and then > (if possible) set it up again on the new channel or another channel. Maybe that's more of an argument for adding a sort of "reason" or "cause" to the STOP_AP? (Btw, no tear down needed in this case - that's already done) OTOH, what else are you thinking of doing? Why would you ever, under any circumstances, not restart the AP if it was stopped by the device? 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 7 May 2014 13:19, Johannes Berg <johannes@sipsolutions.net> wrote: > On Wed, 2014-05-07 at 10:27 +0000, Peer, Ilan wrote: > >> > In the first case, there's no notification, nor any need for it. In the second >> > case, the scenario you suggest doesn't apply, and STOP_AP has to happen >> > anyway because the state is completely messed up, clients will be in the >> > process of switching etc. >> > >> > > Other than that, a STOP_AP might introduce some races, as >> > > wpa_supplicant/hostap will not know if the stop_ap was due to the >> > > failed CS or due to some other reason. >> > >> > I don't see why that would matter - even if the STOP_AP *was* for some >> > other reason, but happened in the middle of the CS flow, the reaction would >> > presumably be the same? >> > >> >> It can be beneficial to know that the STOP_AP was called due to >> failure of CS, as wpa_supplicant/hostap can tear down the AP and then >> (if possible) set it up again on the new channel or another channel. > > Maybe that's more of an argument for adding a sort of "reason" or > "cause" to the STOP_AP? (Btw, no tear down needed in this case - that's > already done) > > OTOH, what else are you thinking of doing? Why would you ever, under any > circumstances, not restart the AP if it was stopped by the device? I can smell a recursive start-stop ping-pong if you restart unconditionally. Michal -- 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
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9oYW5uZXMgQmVyZyBb bWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5 IDA3LCAyMDE0IDE0OjIwDQo+IFRvOiBQZWVyLCBJbGFuDQo+IENjOiBMdWNhIENvZWxobzsgbGlu dXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBtaWNoYWwua2F6aW9yQHRpZXRvLmNvbTsNCj4g T3RjaGVyZXRpYW5za2ksIEFuZHJlaQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvNF0gY2ZnODAy MTEvbmw4MDIxMTogYWRkIGNoYW5uZWwgc3dpdGNoIHN0YXJ0ZWQgYW5kDQo+IGZhaWxlZCBub3Rp ZmljYXRpb25zDQo+IA0KPiBPbiBXZWQsIDIwMTQtMDUtMDcgYXQgMTA6MjcgKzAwMDAsIFBlZXIs IElsYW4gd3JvdGU6DQo+IA0KPiA+ID4gSW4gdGhlIGZpcnN0IGNhc2UsIHRoZXJlJ3Mgbm8gbm90 aWZpY2F0aW9uLCBub3IgYW55IG5lZWQgZm9yIGl0LiBJbg0KPiA+ID4gdGhlIHNlY29uZCBjYXNl LCB0aGUgc2NlbmFyaW8geW91IHN1Z2dlc3QgZG9lc24ndCBhcHBseSwgYW5kIFNUT1BfQVANCj4g PiA+IGhhcyB0byBoYXBwZW4gYW55d2F5IGJlY2F1c2UgdGhlIHN0YXRlIGlzIGNvbXBsZXRlbHkg bWVzc2VkIHVwLA0KPiA+ID4gY2xpZW50cyB3aWxsIGJlIGluIHRoZSBwcm9jZXNzIG9mIHN3aXRj aGluZyBldGMuDQo+ID4gPg0KPiA+ID4gPiBPdGhlciB0aGFuIHRoYXQsIGEgU1RPUF9BUCBtaWdo dCBpbnRyb2R1Y2Ugc29tZSByYWNlcywgYXMNCj4gPiA+ID4gd3BhX3N1cHBsaWNhbnQvaG9zdGFw IHdpbGwgbm90IGtub3cgaWYgdGhlIHN0b3BfYXAgd2FzIGR1ZSB0byB0aGUNCj4gPiA+ID4gZmFp bGVkIENTIG9yIGR1ZSB0byBzb21lIG90aGVyIHJlYXNvbi4NCj4gPiA+DQo+ID4gPiBJIGRvbid0 IHNlZSB3aHkgdGhhdCB3b3VsZCBtYXR0ZXIgLSBldmVuIGlmIHRoZSBTVE9QX0FQICp3YXMqIGZv cg0KPiA+ID4gc29tZSBvdGhlciByZWFzb24sIGJ1dCBoYXBwZW5lZCBpbiB0aGUgbWlkZGxlIG9m IHRoZSBDUyBmbG93LCB0aGUNCj4gPiA+IHJlYWN0aW9uIHdvdWxkIHByZXN1bWFibHkgYmUgdGhl IHNhbWU/DQo+ID4gPg0KPiA+DQo+ID4gSXQgY2FuIGJlIGJlbmVmaWNpYWwgdG8ga25vdyB0aGF0 IHRoZSBTVE9QX0FQIHdhcyBjYWxsZWQgZHVlIHRvDQo+ID4gZmFpbHVyZSBvZiBDUywgYXMgd3Bh X3N1cHBsaWNhbnQvaG9zdGFwIGNhbiB0ZWFyIGRvd24gdGhlIEFQIGFuZCB0aGVuDQo+ID4gKGlm IHBvc3NpYmxlKSBzZXQgaXQgdXAgYWdhaW4gb24gdGhlIG5ldyBjaGFubmVsIG9yIGFub3RoZXIg Y2hhbm5lbC4NCj4gDQo+IE1heWJlIHRoYXQncyBtb3JlIG9mIGFuIGFyZ3VtZW50IGZvciBhZGRp bmcgYSBzb3J0IG9mICJyZWFzb24iIG9yICJjYXVzZSIgdG8NCj4gdGhlIFNUT1BfQVA/IChCdHcs IG5vIHRlYXIgZG93biBuZWVkZWQgaW4gdGhpcyBjYXNlIC0gdGhhdCdzIGFscmVhZHkgZG9uZSkN Cj4gDQoNClllcyA6KQ0KDQo+IE9UT0gsIHdoYXQgZWxzZSBhcmUgeW91IHRoaW5raW5nIG9mIGRv aW5nPyBXaHkgd291bGQgeW91IGV2ZXIsIHVuZGVyIGFueQ0KPiBjaXJjdW1zdGFuY2VzLCBub3Qg cmVzdGFydCB0aGUgQVAgaWYgaXQgd2FzIHN0b3BwZWQgYnkgdGhlIGRldmljZT8NCg0KQWN0dWFs bHkgdGhpcyBpcyB0aGUgZGVmYXVsdCB0b2RheTogb24gU1RPUF9BUCBub3RpZmljYXRpb24gYSBH TyBpbnRlcmZhY2UgaXMgc2ltcGx5IGRlbGV0ZWQsIGFzIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQg c29tZXRoaW5nIHVucmVjb3ZlcmFibGUgaGFwcGVuZWQuIEluIGNhc2Ugb2YgQ1MgZmFpbHVyZSwg aXQgd291bGQgYmUgKm5pY2UqIHRvIGtub3cgaWYgdGhlIGZhaWx1cmUgaXMgcmVjb3ZlcmFibGUg b3Igbm90Lg0KDQpSZWdhcmRzLA0KDQpJbGFuLg0KDQoNCiANCg0K -- 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
Finally got the time to come back to this... On Wed, 2014-05-07 at 11:55 +0000, Peer, Ilan wrote: > > > > -----Original Message----- > > From: Johannes Berg [mailto:johannes@sipsolutions.net] > > Sent: Wednesday, May 07, 2014 14:20 > > To: Peer, Ilan > > Cc: Luca Coelho; linux-wireless@vger.kernel.org; michal.kazior@tieto.com; > > Otcheretianski, Andrei > > Subject: Re: [PATCH 1/4] cfg80211/nl80211: add channel switch started and > > failed notifications > > > > On Wed, 2014-05-07 at 10:27 +0000, Peer, Ilan wrote: > > > > > > In the first case, there's no notification, nor any need for it. In > > > > the second case, the scenario you suggest doesn't apply, and STOP_AP > > > > has to happen anyway because the state is completely messed up, > > > > clients will be in the process of switching etc. > > > > > > > > > Other than that, a STOP_AP might introduce some races, as > > > > > wpa_supplicant/hostap will not know if the stop_ap was due to the > > > > > failed CS or due to some other reason. > > > > > > > > I don't see why that would matter - even if the STOP_AP *was* for > > > > some other reason, but happened in the middle of the CS flow, the > > > > reaction would presumably be the same? > > > > > > > > > > It can be beneficial to know that the STOP_AP was called due to > > > failure of CS, as wpa_supplicant/hostap can tear down the AP and then > > > (if possible) set it up again on the new channel or another channel. > > > > Maybe that's more of an argument for adding a sort of "reason" or "cause" to > > the STOP_AP? (Btw, no tear down needed in this case - that's already done) > > > > Yes :) > > > OTOH, what else are you thinking of doing? Why would you ever, under any > > circumstances, not restart the AP if it was stopped by the device? > > Actually this is the default today: on STOP_AP notification a GO interface is simply deleted, as the assumption is that something unrecoverable happened. In case of CS failure, it would be *nice* to know if the failure is recoverable or not. Okay, so this is what I'll do: * remove the failed notifications * in a new patch, add a reason attribute to the STOP_AP notification; -- Luca. -- 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/include/net/cfg80211.h b/include/net/cfg80211.h index 7eae46c..43c674e 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -4574,6 +4574,29 @@ bool cfg80211_reg_can_beacon(struct wiphy *wiphy, void cfg80211_ch_switch_notify(struct net_device *dev, struct cfg80211_chan_def *chandef); +/* + * cfg80211_ch_switch_started_notify - notify channel switch start + * @dev: the device on which the channel switch started + * @chandef: the future channel definition + * + * Inform the userspace about the channel switch that has just + * started, so that it can take appropriate actions (eg. starting + * channel switch on other vifs), if necessary. + */ +void cfg80211_ch_switch_started_notify(struct net_device *dev, + struct cfg80211_chan_def *chandef); + +/* + * cfg80211_ch_switch_failed_notify - notify channel switch failure + * @dev: the device on which the channel switch has failed + * @chandef: the channel definition to which we failed to switch + * + * Inform the userspace that a channel switch has failed after the + * channel switch started notification has been sent. + */ +void cfg80211_ch_switch_failed_notify(struct net_device *dev, + struct cfg80211_chan_def *chandef); + /** * ieee80211_operating_class_to_band - convert operating class to band * diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 406010d..d7c5b61 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -638,6 +638,20 @@ * %NL80211_ATTR_IFINDEX is now on %NL80211_ATTR_WIPHY_FREQ and the * attributes determining channel width. * + * @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY: Notify that a channel switch + * has been started on an interface, regardless of the initiator + * (ie. whether it was requested from a remote device or + * initiated on our own). It indicates that + * %NL80211_ATTR_IFINDEX will be on %NL80211_ATTR_WIPHY_FREQ + * after %NL80211_ATTR_CH_SWITCH_COUNT TBTT's. The userspace may + * decide to react to this indication by requesting other + * interfaces to change channel as well. + * + * @NL80211_CMD_CH_SWITCH_FAILED_NOTIFY: Notify that a channel switch + * has failed on %NL80211_ATTR_IFINDEX. This notification can + * only be sent after a @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY has + * been issued. + * * @NL80211_CMD_START_P2P_DEVICE: Start the given P2P Device, identified by * its %NL80211_ATTR_WDEV identifier. It must have been created with * %NL80211_CMD_NEW_INTERFACE previously. After it has been started, the @@ -890,6 +904,9 @@ enum nl80211_commands { NL80211_CMD_SET_QOS_MAP, + NL80211_CMD_CH_SWITCH_STARTED_NOTIFY, + NL80211_CMD_CH_SWITCH_FAILED_NOTIFY, + /* add new commands above here */ /* used to define NL80211_CMD_MAX below */ diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 0f1b18f2..804c3c9 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -11208,7 +11208,8 @@ EXPORT_SYMBOL(cfg80211_pmksa_candidate_notify); static void nl80211_ch_switch_notify(struct cfg80211_registered_device *rdev, struct net_device *netdev, struct cfg80211_chan_def *chandef, - gfp_t gfp) + gfp_t gfp, + enum nl80211_commands notif) { struct sk_buff *msg; void *hdr; @@ -11217,7 +11218,7 @@ static void nl80211_ch_switch_notify(struct cfg80211_registered_device *rdev, if (!msg) return; - hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_CH_SWITCH_NOTIFY); + hdr = nl80211hdr_put(msg, 0, 0, 0, notif); if (!hdr) { nlmsg_free(msg); return; @@ -11259,10 +11260,39 @@ void cfg80211_ch_switch_notify(struct net_device *dev, wdev->chandef = *chandef; wdev->preset_chandef = *chandef; - nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL); + nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL, + NL80211_CMD_CH_SWITCH_NOTIFY); } EXPORT_SYMBOL(cfg80211_ch_switch_notify); +void cfg80211_ch_switch_started_notify(struct net_device *dev, + struct cfg80211_chan_def *chandef) +{ + struct wireless_dev *wdev = dev->ieee80211_ptr; + struct wiphy *wiphy = wdev->wiphy; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + + trace_cfg80211_ch_switch_started_notify(dev, chandef); + + nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL, + NL80211_CMD_CH_SWITCH_STARTED_NOTIFY); +} +EXPORT_SYMBOL(cfg80211_ch_switch_started_notify); + +void cfg80211_ch_switch_failed_notify(struct net_device *dev, + struct cfg80211_chan_def *chandef) +{ + struct wireless_dev *wdev = dev->ieee80211_ptr; + struct wiphy *wiphy = wdev->wiphy; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + + trace_cfg80211_ch_switch_failed_notify(dev, chandef); + + nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL, + NL80211_CMD_CH_SWITCH_FAILED_NOTIFY); +} +EXPORT_SYMBOL(cfg80211_ch_switch_failed_notify); + void cfg80211_cqm_txe_notify(struct net_device *dev, const u8 *peer, u32 num_packets, u32 rate, u32 intvl, gfp_t gfp) diff --git a/net/wireless/trace.h b/net/wireless/trace.h index f3c13ff..1f6443b 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -2259,6 +2259,38 @@ TRACE_EVENT(cfg80211_ch_switch_notify, NETDEV_PR_ARG, CHAN_DEF_PR_ARG) ); +TRACE_EVENT(cfg80211_ch_switch_started_notify, + TP_PROTO(struct net_device *netdev, + struct cfg80211_chan_def *chandef), + TP_ARGS(netdev, chandef), + TP_STRUCT__entry( + NETDEV_ENTRY + CHAN_DEF_ENTRY + ), + TP_fast_assign( + NETDEV_ASSIGN; + CHAN_DEF_ASSIGN(chandef); + ), + TP_printk(NETDEV_PR_FMT ", " CHAN_DEF_PR_FMT, + NETDEV_PR_ARG, CHAN_DEF_PR_ARG) +); + +TRACE_EVENT(cfg80211_ch_switch_failed_notify, + TP_PROTO(struct net_device *netdev, + struct cfg80211_chan_def *chandef), + TP_ARGS(netdev, chandef), + TP_STRUCT__entry( + NETDEV_ENTRY + CHAN_DEF_ENTRY + ), + TP_fast_assign( + NETDEV_ASSIGN; + CHAN_DEF_ASSIGN(chandef); + ), + TP_printk(NETDEV_PR_FMT ", " CHAN_DEF_PR_FMT, + NETDEV_PR_ARG, CHAN_DEF_PR_ARG) +); + TRACE_EVENT(cfg80211_radar_event, TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef), TP_ARGS(wiphy, chandef),