* Re: Commit 0711d638 breaks mwifiex
From: Johannes Berg @ 2017-10-17 10:48 UTC (permalink / raw)
To: Jesse Sung
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <CAH10aOj8xTPDyEufGS47hytnT8RSL+qSbiRVmePrMpaaUu7gPQ@mail.gmail.com>
On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
> > Does mwifiex treat this -EALREADY as *keeping* an old connection,
> > or tearing it down entirely?
>
> From the call trace:
Well, the call trace can't really answer that :-)
Does mwifiex firmware stay connected?
> 139.451318: nl80211_get_valid_chan <-nl80211_connect
> 139.451321: cfg80211_connect <-nl80211_connect
> 139.451322: cfg80211_oper_and_ht_capa <-cfg80211_connect
> 139.451323: mwifiex_cfg80211_connect <-cfg80211_connect
> 139.451337: nl80211_post_doit <-genl_family_rcv_msg
> 139.451423: nl80211_pre_doit <-genl_family_rcv_msg
> 139.451425: nl80211_disconnect <-genl_family_rcv_msg
> 139.451426: cfg80211_disconnect <-nl80211_disconnect
> 139.451430: mwifiex_cfg80211_disconnect <-cfg80211_disconnect
>
> mwifiex_cfg80211_disconnect() would be called after
> mwifiex_cfg80211_connect(), though I'm not sure if it's triggered by
> the error returned.
I think so - it's probably wpa_supplicant trying to get back to a well-
known state (of being disconnected).
> > I think your fix is invalid because we then reset ssid_len and
> > still
> > keep an old connection (current_bss) which will lead to strange
> > nl80211
> > behaviour when getting interface data etc.
>
> Since this is how it works before commit 0711d638 (use current_bss
> instead of ssid_len), so I'm guessing this would still work. But I
> agree that this may not be a proper fix...
It would probably work, but we get data inconsistencies, and at the
very least you get no SSID data back when you query the current state.
I don't see anything in nl80211 or so that would say we should accept a
connect() while already connected, so how about this?
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index b347e63d7aaa..fe0037ad1f5e 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1042,6 +1042,9 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
ASSERT_WDEV_LOCK(wdev);
+ if (wdev->current_bss)
+ return -EALREADY;
+
if (WARN_ON(wdev->connect_keys)) {
kzfree(wdev->connect_keys);
wdev->connect_keys = NULL;
Not really quite sure about it yet, but that should address the issue?
johannes
^ permalink raw reply related
* Re: AP6335 with mainline kernel
From: Vanessa Maegima @ 2017-10-17 12:07 UTC (permalink / raw)
To: arend.vanspriel@broadcom.com, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com,
joerg.krause@embedded.rocks
In-Reply-To: <CABACg+wyKfFNyZurY7vVMHS+AG-tcih6uZTZM=d5TUPjOM9Qcw@mail.gmail.com>
SGkgQXJlbmQsDQoNCk9uIFF1aSwgMjAxNy0wOS0yMSBhdCAxMjozMCAtMDMwMCwgVmFuZXNzYSBB
eXVtaSBNYWVnaW1hIHdyb3RlOg0KPiBIaSBBcmVuZCwNCj4gDQo+IE9uIFRodSwgU2VwIDIxLCAy
MDE3IGF0IDQ6MjYgQU0sIEFyZW5kIHZhbiBTcHJpZWwNCj4gPGFyZW5kLnZhbnNwcmllbEBicm9h
ZGNvbS5jb20+IHdyb3RlOg0KPiA+IA0KPiA+IE9uIDIwLTA5LTE3IDIxOjMzLCBWYW5lc3NhIEF5
dW1pIE1hZWdpbWEgd3JvdGU6DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSGksDQo+ID4gPiANCj4g
PiA+IEkgYW0gdHJ5aW5nIHRvIGVuYWJsZSBXaWZpIG9uIGlteDdkLXBpY28gdXNpbmcgbWFpbmxp
bmUga2VybmVsLg0KPiA+ID4gaW14N2QtcGljbw0KPiA+ID4gaGFzIGFuIEFQNjMzNSBjaGlwLg0K
PiA+ID4gDQo+ID4gPiBJIGFtIGZhY2luZyBzb21lIGlzc3VlcyByZWxhdGVkIHRvIHRoZSBudnJh
bSBmaWxlLiBJIGFtIHVzaW5nIHRoZQ0KPiA+ID4gZmlybXdhcmUNCj4gPiA+IHByb3ZpZGVkIGJ5
IEJ1aWxkcm9vdCAoYnJjbWZtYWM0MzM5LXNkaW8uYmluKS4gSSBnZXQgdGhlDQo+ID4gPiBmb2xs
b3dpbmcgZXJyb3I6DQo+ID4gPiANCj4gPiA+IFvCoMKgwqDCoDguNjMwMzgwXSBicmNtZm1hYzog
YnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91dA0KPiA+ID4gKDEwMDAwMDApOg0KPiA+
ID4gY2xrY3RsIDB4NTANCj4gPiA+IA0KPiA+ID4gSSBoYXZlIHRyaWVkIHRvIHVzZSB0aGUgZmly
bXdhcmUgYW5kIG52cmFtIHByb3ZpZGVkIGJ5IFRlY2hOZXhpb24NCj4gPiA+IGJ1dCBJDQo+ID4g
PiBnZXQNCj4gPiA+IHRoZSBzYW1lIGVycm9yLg0KPiA+ID4gDQo+ID4gPiBJcyB0aGVyZSBhbnlv
bmUgdGhhdCBjb3VsZCBlbmFibGUgV2lmaSBvbiBBUDYzMzUgdXNpbmcga2VybmVsDQo+ID4gPiBt
YWlubGluZT8NCj4gPiA+IFdoYXQgbnZyYW0gZmlsZSB3YXMgdXNlZD8NCj4gPiA+IA0KPiA+ID4g
SSBhbSBhYmxlIHRvIHVzZSBXaWZpIG9uIHRoZSBib2FyZCBpZiBJIHVzZSB0aGUgZmlybXdhcmUs
IG52cmFtDQo+ID4gPiBmaWxlIGFuZA0KPiA+ID4ga2VybmVsDQo+ID4gPiBwcm92aWRlZCBieSBU
ZWNoTmV4aW9uLiBUaGV5IHVzZSBhIDQuMSBrZXJuZWwgZnJvbSBOWFAgd2l0aCB0aGUNCj4gPiA+
IGJjbWRoZA0KPiA+ID4gZHJpdmVyLg0KPiA+ID4gDQo+ID4gPiBTbyBJIGtub3cgdGhhdCB0aGUg
aGFyZHdhcmUgaXMgZnVuY3Rpb25hbC4NCj4gPiA+IA0KPiA+ID4gQW55IHN1Z2dlc3Rpb25zIGFz
IGhvdyB0byBnZXQgaXQgd29ya2luZyB3aXRoIGEgNC4xMyBhbmQgYnJjbWZtYWMNCj4gPiA+IGRy
aXZlcg0KPiA+ID4gaXMNCj4gPiA+IGFwcHJlY2lhdGVkLg0KPiA+IA0KPiA+IFNvIHRoZSBudnJh
bSBmaWxlIGlzIHNwZWNpZmljIHRvIHRoZSB3aWZpIGNoaXBzZXQgb24geW91ciBwbGF0Zm9ybQ0K
PiA+IHNvIGJlc3QNCj4gPiB0byBzdGljayB3aXRoIHRoZSBwcm92aWRlZCBvbmUuIFRoZSAiSFQg
QXZhaWwgdGltZW91dCIgbW9zdCBvZnRlbg0KPiA+IGlzIGFuDQo+ID4gaW5kaWNhdGlvbiB0aGF0
IHRoZSBmaXJtd2FyZSBjcmFzaGVkLiBTbyBnZXR0aW5nIG1vcmUgZGVidWcgb3V0cHV0DQo+ID4g
d291bGQNCj4gPiBoZWxwIHVzIHVuZGVyc3RhbmQgaG93IGl0IGVuZGVkIHVwIGxpa2UgdGhhdC4g
Q2FuIHlvdSBidWlsZCB0aGUNCj4gPiBicmNtZm1hYw0KPiA+IHdpdGggQ09ORklHX0JSQ01EQkcg
YW5kIGxvYWQgdGhlIGRyaXZlciB1c2luZzoNCj4gPiANCj4gPiAkIGluc21vZCBicmNtZm1hYy5r
byBkZWJ1Zz0weDE0MTYNCj4gVGhhbmtzIGZvciB0aGUgcmVwbHkhDQo+IA0KPiBIZXJlIGlzIHRo
ZSBsb2cgKHVzaW5nIDQuMTQtcmMxKToNCj4gDQo+ICMgZG1lc2cgfCBncmVwIGJyY21mbWFjDQo+
IFvCoMKgwqAxOS4yOTcyMDZdIGJyY21mbWFjOiBicmNtZm1hY19tb2R1bGVfaW5pdCBObyBwbGF0
Zm9ybSBkYXRhDQo+IGF2YWlsYWJsZS4NCj4gW8KgwqDCoDE5LjMwNzA3NV0gYnJjbWZtYWM6IGJy
Y21mX3NkaW9fcHJvYmUgRW50ZXINCj4gW8KgwqDCoDE5LjMwODM4NF0gYnJjbWZtYWM6IEYxIHNp
Z25hdHVyZSByZWFkIEAweDE4MDAwMDAwPTB4MTYyMjQzMzUNCj4gW8KgwqDCoDE5LjMwOTAyNl0g
YnJjbWZtYWM6IGJyY21mX2NoaXBfcmVjb2duaXRpb24gZm91bmQgQVhJIGNoaXA6DQo+IEJDTTQz
MzksIHJldj0yDQo+IFvCoMKgwqAxOS4zMTcxMTVdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVz
X2NoZWNrwqDCoFsxIF0gY29yZSAweDgwMDo0Ng0KPiBiYXNlIDB4MTgwMDAwMDAgd3JhcCAweDE4
MTAwMDAwDQo+IFvCoMKgwqAxOS4zMTcxNDFdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2No
ZWNrwqDCoFsyIF0gY29yZSAweDgxMjo0Ng0KPiBiYXNlIDB4MTgwMDEwMDAgd3JhcCAweDE4MTAx
MDAwDQo+IFvCoMKgwqAxOS4zMTcxNjVdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNr
wqDCoFszIF0gY29yZSAweDgzZTo0DQo+IGJhc2UgMHgxODAwMjAwMCB3cmFwIDB4MTgxMDIwMDAN
Cj4gW8KgwqDCoDE5LjMxNzE4OF0gYnJjbWZtYWM6IGJyY21mX2NoaXBfY29yZXNfY2hlY2vCoMKg
WzQgXSBjb3JlIDB4ODNjOjQNCj4gYmFzZSAweDE4MDAzMDAwIHdyYXAgMHgxODEwMzAwMA0KPiBb
wqDCoMKgMTkuMzE3MjEwXSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNSBd
IGNvcmUgMHg4MWE6MjANCj4gYmFzZSAweDE4MDA0MDAwIHdyYXAgMHgxODEwNDAwMA0KPiBbwqDC
oMKgMTkuMzE3MjMzXSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNiBdIGNv
cmUgMHg4Mjk6MjENCj4gYmFzZSAweDE4MDA1MDAwIHdyYXAgMHgxODEwNTAwMA0KPiBbwqDCoMKg
MTkuMzE3MjU2XSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNyBdIGNvcmUg
MHgxMzU6MA0KPiBiYXNlIDB4MDAwMDAwMDAgd3JhcCAweDE4MTA5MDAwDQo+IFvCoMKgwqAxOS4z
MTcyNzldIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFs4IF0gY29yZSAweDI0
MDowDQo+IGJhc2UgMHgwMDAwMDAwMCB3cmFwIDB4MDAwMDAwMDANCj4gW8KgwqDCoDE5LjMxNzI5
OF0gYnJjbWZtYWM6IGJyY21mX2NoaXBfc2V0X3Bhc3NpdmUgRW50ZXINCj4gW8KgwqDCoDE5LjMy
MjIzMl0gYnJjbWZtYWM6IGJyY21mX2NoaXBfZ2V0X3JhbWluZm8gUkFNOiBiYXNlPTB4MTgwMDAw
DQo+IHNpemU9Nzg2NDMyICgweGMwMDAwKSBzcj0wICgweDApDQo+IFvCoMKgwqAxOS4zMjI0NTdd
IGJyY21mbWFjOiBicmNtZl9jaGlwX3NldHVwIGNjcmV2PTQ2LCBwbXVyZXY9MjMsDQo+IHBtdWNh
cHM9MHgzOWNjNWYxNw0KPiBbwqDCoMKgMTkuMzIyNDgxXSBicmNtZm1hYzogYnJjbWZfZ2V0X21v
ZHVsZV9wYXJhbSBFbnRlciwgYnVzPTAsDQo+IGNoaXA9MTcyMDksIHJldj0yDQo+IFvCoMKgwqAx
OS4zMjI1MDRdIGJyY21mbWFjOiBicmNtZl9zZGlvZF9zZ3RhYmxlX2FsbG9jIG5lbnRzPTM1DQo+
IFvCoMKgwqAxOS4zMjI1MzFdIGJyY21mbWFjOiBicmNtZl9zZGlvX2tzb19pbml0IEVudGVyDQo+
IFvCoMKgwqAxOS4zMjI2MThdIGJyY21mbWFjOiBicmNtZl9zZGlvX2RyaXZlc3RyZW5ndGhpbml0
IE5vIFNESU8gZHJpdmVyDQo+IHN0cmVuZ3RoIGluaXQgbmVlZGVkIGZvciBjaGlwIDQzDQo+IDM5
IHJldiAyIHBtdXJldiAyMw0KPiBbwqDCoMKgMTkuMzIzMjM1XSBicmNtZm1hYzogYnJjbWZfYXR0
YWNoIEVudGVyDQo+IFvCoMKgwqAxOS4zMjM3MjVdIGJyY21mbWFjOiBicmNtZl9wcm90b19hdHRh
Y2ggRW50ZXINCj4gW8KgwqDCoDE5LjMyMzc2OV0gYnJjbWZtYWM6IGJyY21mX2Z3ZWhfcmVnaXN0
ZXIgZXZlbnQgaGFuZGxlciByZWdpc3RlcmVkDQo+IGZvciBQU01fV0FUQ0hET0cNCj4gW8KgwqDC
oDE5LjMyNDMwNl0gYnJjbWZtYWM6IGJyY21mX3NkaW9fcHJvYmUgY29tcGxldGVkISENCj4gW8Kg
wqDCoDE5LjMyNDMzN10gYnJjbWZtYWM6IGJyY21mX2Z3X21hcF9jaGlwX3RvX25hbWU6IHVzaW5n
DQo+IGJyY20vYnJjbWZtYWM0MzM5LXNkaW8uYmluIGZvciBjaGlwIDB4MDA0MzMNCj4gOSgxNzIw
OSkgcmV2IDB4MDAwMDAyDQo+IFvCoMKgwqAxOS4zMzUzNTNdIGJyY21mbWFjOiBicmNtZl9md19n
ZXRfZmlybXdhcmVzX3BjaWUgZW50ZXI6DQo+IGRldj1tbWMwOjAwMDE6MQ0KPiBbwqDCoMKgMTku
MzUxNzg3XSBicmNtZm1hYzogYnJjbWZfZndfcmVxdWVzdF9jb2RlX2RvbmUgZW50ZXI6DQo+IGRl
dj1tbWMwOjAwMDE6MQ0KPiBbwqDCoMKgMTkuMzUzMjAyXSBicmNtZm1hYzogYnJjbWZfZndfcmVx
dWVzdF9udnJhbV9kb25lIGVudGVyOg0KPiBkZXY9bW1jMDowMDAxOjENCj4gW8KgwqDCoDE5LjM1
MzQyNF0gYnJjbWZtYWM6IGJyY21mX3NkaW9fZmlybXdhcmVfY2FsbGJhY2sgRW50ZXI6DQo+IGRl
dj1tbWMwOjAwMDE6MSwgZXJyPTANCj4gW8KgwqDCoDE5LjM1MzgxNF0gYnJjbWZtYWM6IGJyY21m
X3NkaW9fZG93bmxvYWRfY29kZV9maWxlIEVudGVyDQo+IFvCoMKgwqAxOS4zODg1ODZdIGJyY21m
bWFjOiBicmNtZl9zZGlvX3ZlcmlmeW1lbW9yeSBDb21wYXJlIFJBTSBkbCAmIHVsDQo+IGF0IDB4
MDAxODAwMDA7IHNpemU9NDkzNTk5DQo+IFvCoMKgwqAxOS41NDY2NzVdIGJyY21mbWFjOiBicmNt
Zl9zZGlvX2Rvd25sb2FkX252cmFtIEVudGVyDQo+IFvCoMKgwqAxOS41NDc0MzJdIGJyY21mbWFj
OiBicmNtZl9zZGlvX3ZlcmlmeW1lbW9yeSBDb21wYXJlIFJBTSBkbCAmIHVsDQo+IGF0IDB4MDAy
M2Y3MzA7IHNpemU9MjI1Ng0KPiBbwqDCoMKgMTkuNTQ4NjY1XSBicmNtZm1hYzogYnJjbWZfY2hp
cF9zZXRfYWN0aXZlIEVudGVyDQo+IFvCoMKgwqAyMC41NjI5NzRdIGJyY21mbWFjOiBicmNtZl9z
ZGlvX2h0Y2xrOiBIVCBBdmFpbCB0aW1lb3V0DQo+ICgxMDAwMDAwKToNCj4gY2xrY3RsIDB4NTAN
Cj4gW8KgwqDCoDIwLjU3MDQ5MF0gYnJjbWZtYWM6IGJyY21mX3NkaW9fZmlybXdhcmVfY2FsbGJh
Y2sgZmFpbGVkOg0KPiBkZXY9bW1jMDowMDAxOjEsIGVycj0wDQo+IFvCoMKgwqAyMC41NzA3Mzld
IGJyY21mbWFjOiBicmNtZl9zZGlvX3JlbW92ZSBFbnRlcg0KPiBbwqDCoMKgMjAuNTcwNzc1XSBi
cmNtZm1hYzogYnJjbWZfZGV0YWNoIEVudGVyDQo+IFvCoMKgwqAyMC42MTA0MTRdIGJyY21mbWFj
OiBicmNtZl9idXNfY2hhbmdlX3N0YXRlIDAgLT4gMA0KPiBbwqDCoMKgMjAuNjEwNDQxXSBicmNt
Zm1hYzogYnJjbWZfc2Rpb19idXNfc3RvcCBFbnRlcg0KPiBbwqDCoMKgMjEuNjIyNDc3XSBicmNt
Zm1hYzogYnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91dA0KPiAoMTAwMDAwMCk6DQo+
IGNsa2N0bCAweDUwDQo+IFvCoMKgwqAyMS42MzA5MTJdIGJyY21mbWFjOiBicmNtZl9wcm90b19k
ZXRhY2ggRW50ZXINCj4gW8KgwqDCoDIxLjYzMDk2N10gYnJjbWZtYWM6IGJyY21mX2Z3ZWhfdW5y
ZWdpc3RlciBldmVudCBoYW5kbGVyIGNsZWFyZWQNCj4gZm9yIFBTTV9XQVRDSERPRw0KPiBbwqDC
oMKgMjIuNjQyNDU3XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91
dA0KPiAoMTAwMDAwMCk6DQo+IGNsa2N0bCAweDUwDQo+IFvCoMKgwqAyMi42ODAxMzFdIGJyY21m
bWFjOiBicmNtZl9jaGlwX3NldF9wYXNzaXZlIEVudGVyDQo+IFvCoMKgwqAyMi42ODI1ODBdIGJy
Y21mbWFjOiBicmNtZl9zZGlvX3JlbW92ZSBEaXNjb25uZWN0ZWQNCj4gDQo+ID4gDQo+ID4gDQo+
ID4gUmVnYXJkcywNCj4gPiBBcmVuZA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IFRoYW5rcyENCj4g
PiA+IA0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFZhbmVzc2ENCj4gPiA+IA0KDQpEbyB5b3UgaGF2
ZSBhbnkgY29tbWVudHM/DQoNClRoYW5rcyENClZhbmVzc2E=
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Jesse Sung @ 2017-10-17 13:07 UTC (permalink / raw)
To: Johannes Berg
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <1508237298.10607.76.camel@sipsolutions.net>
On Tue, Oct 17, 2017 at 6:48 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
>
>> > Does mwifiex treat this -EALREADY as *keeping* an old connection,
>> > or tearing it down entirely?
>>
>> From the call trace:
>
> Well, the call trace can't really answer that :-)
> Does mwifiex firmware stay connected?
Sorry I don't know how to tell firmware's state. @@
>> 139.451318: nl80211_get_valid_chan <-nl80211_connect
>> 139.451321: cfg80211_connect <-nl80211_connect
>> 139.451322: cfg80211_oper_and_ht_capa <-cfg80211_connect
>> 139.451323: mwifiex_cfg80211_connect <-cfg80211_connect
>> 139.451337: nl80211_post_doit <-genl_family_rcv_msg
>> 139.451423: nl80211_pre_doit <-genl_family_rcv_msg
>> 139.451425: nl80211_disconnect <-genl_family_rcv_msg
>> 139.451426: cfg80211_disconnect <-nl80211_disconnect
>> 139.451430: mwifiex_cfg80211_disconnect <-cfg80211_disconnect
>>
>> mwifiex_cfg80211_disconnect() would be called after
>> mwifiex_cfg80211_connect(), though I'm not sure if it's triggered by
>> the error returned.
>
> I think so - it's probably wpa_supplicant trying to get back to a well-
> known state (of being disconnected).
>
>> > I think your fix is invalid because we then reset ssid_len and
>> > still
>> > keep an old connection (current_bss) which will lead to strange
>> > nl80211
>> > behaviour when getting interface data etc.
>>
>> Since this is how it works before commit 0711d638 (use current_bss
>> instead of ssid_len), so I'm guessing this would still work. But I
>> agree that this may not be a proper fix...
>
> It would probably work, but we get data inconsistencies, and at the
> very least you get no SSID data back when you query the current state.
>
> I don't see anything in nl80211 or so that would say we should accept a
> connect() while already connected, so how about this?
>
> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index b347e63d7aaa..fe0037ad1f5e 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -1042,6 +1042,9 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
>
> ASSERT_WDEV_LOCK(wdev);
>
> + if (wdev->current_bss)
> + return -EALREADY;
> +
> if (WARN_ON(wdev->connect_keys)) {
> kzfree(wdev->connect_keys);
> wdev->connect_keys = NULL;
>
> Not really quite sure about it yet, but that should address the issue?
A very rough test by issuing reassociate in wpa_cli:
mwifiex works after reassociate - looks good
> reassociate
OK
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>Trying to associate with <BSSID1> (SSID=<SSID> freq=<freq1>)
<3>Association request to the driver failed
<3>CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with <BSSID2> (SSID=<SSID> freq=<freq2>)
<3>Associated with <BSSID2>
<3>WPA: Key negotiation completed with <BSSID2> [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to <BSSID2> completed [id=0 id_str=]
<3>CTRL-EVENT-SCAN-STARTED
> reassociate
OK
<3>CTRL-EVENT-SCAN-RESULTS
<3>Trying to associate with <BSSID2> (SSID=<SSID> freq=<freq2>)
<3>Associated with <BSSID2>
<3>CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
<3>WPA: Key negotiation completed with <BSSID2> [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to <BSSID2> completed [id=0 id_str=]
> reassociate
OK
<3>CTRL-EVENT-SCAN-STARTED
>
<3>CTRL-EVENT-SCAN-RESULTS
<3>Trying to associate with <BSSID2> (SSID=<SSID> freq=<freq2>)
<3>Association request to the driver failed
<3>CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with <BSSID3> (SSID=<SSID> freq=<freq3>)
<3>Associated with <BSSID3>
<3>WPA: Key negotiation completed with <BSSID3> [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to <BSSID3> completed [id=0 id_str=]
> reassociate
OK
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>Trying to associate with <BSSID3> (SSID=<SSID> freq=<freq3>)
<3>Association request to the driver failed
<3>CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with <BSSID1> (SSID=<SSID> freq=<freq1>)
<3>Associated with <BSSID1>
<3>WPA: Key negotiation completed with <BSSID1> [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to <BSSID1> completed [id=0 id_str=]
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>Trying to associate with <BSSID2> (SSID=<SSID> freq=<freq2>)
<3>Association request to the driver failed
<3>CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS
<3>WPS-AP-AVAILABLE
<3>Trying to associate with <BSSID1> (SSID=<SSID> freq=<freq1>)
<3>Associated with <BSSID1>
<3>WPA: Key negotiation completed with <BSSID1> [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to <BSSID1> completed [id=0 id_str=]
Thanks,
Jesse
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Johannes Berg @ 2017-10-17 13:13 UTC (permalink / raw)
To: Jesse Sung
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <CAH10aOjmMdN2pGP8FDwZQ6BRcu2O5PiGjk+kKb6bAa7nS=ap8g@mail.gmail.com>
On Tue, 2017-10-17 at 21:07 +0800, Jesse Sung wrote:
>
> > Not really quite sure about it yet, but that should address the
> > issue?
>
> A very rough test by issuing reassociate in wpa_cli:
> mwifiex works after reassociate - looks good
Ok. Discussing this with Ilan, we realized that this was buggy, and
came up with this patch instead:
https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
Can you also give that a spin?
johannes
^ permalink raw reply
* Re: After upgrading to 4.11.1, wifi driver refuses to load after being unloaded once.
From: Luca Coelho @ 2017-10-17 14:05 UTC (permalink / raw)
To: Marc MERLIN; +Cc: linux-wireless, linuxwifi
In-Reply-To: <20171017094440.25tpkoeyfm6q2lqw@merlins.org>
Hi,
On Tue, 2017-10-17 at 02:44 -0700, Marc MERLIN wrote:
> Was broken in 4.11, still broken in 4.12. This is crippling, I'm not
> running linux so that I have to reboot it to reload an intel wireless
> driver :-/
Can you report a bug in https://bugzilla.kernel.org so it's easier to
track this?
The problem seems to be that the rootport is not leaving D3 for some
reason when the driver is loaded again. Do you have
CONFIG_IWLWIFI_PCIE_RTPM enabled in your .config? (you shouldn't)
In any case, better continue tracking this in bugzilla, so please
report it there and include the full dmesg output so we can better
understand what is going on.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Jesse Sung @ 2017-10-17 14:08 UTC (permalink / raw)
To: Johannes Berg
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <1508246019.10607.77.camel@sipsolutions.net>
On Tue, Oct 17, 2017 at 9:13 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> On Tue, 2017-10-17 at 21:07 +0800, Jesse Sung wrote:
> >
> > > Not really quite sure about it yet, but that should address the
> > > issue?
> >
> > A very rough test by issuing reassociate in wpa_cli:
> > mwifiex works after reassociate - looks good
>
> Ok. Discussing this with Ilan, we realized that this was buggy, and
> came up with this patch instead:
>
> https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
>
> Can you also give that a spin?
Issued four reassociate, the network interface is still alive. Also with this
patch it stays with BSSID1 and I don't see any "Association request to
the driver failed" in the process.
Thanks,
Jesse
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Jesse Sung @ 2017-10-17 14:10 UTC (permalink / raw)
To: Johannes Berg
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <CAH10aOgfNZbhUYfRa7VRPwvzDNTYtmeDYnDEMtq+6HPqbq94hg@mail.gmail.com>
On Tue, Oct 17, 2017 at 10:08 PM, Jesse Sung <jesse.sung@canonical.com> wrote:
> On Tue, Oct 17, 2017 at 9:13 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>>
>> On Tue, 2017-10-17 at 21:07 +0800, Jesse Sung wrote:
>> >
>> > > Not really quite sure about it yet, but that should address the
>> > > issue?
>> >
>> > A very rough test by issuing reassociate in wpa_cli:
>> > mwifiex works after reassociate - looks good
>>
>> Ok. Discussing this with Ilan, we realized that this was buggy, and
>> came up with this patch instead:
>>
>> https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
>>
>> Can you also give that a spin?
>
> Issued four reassociate, the network interface is still alive. Also with this
> patch it stays with BSSID1 and I don't see any "Association request to
> the driver failed" in the process.
Correction: I can still see "Association request to the driver failed" and
switching between BSSIDs with more reassociates but I think that shouldn't
be an issue?
^ permalink raw reply
* Re: Help with bug "Black screen freeze on suspend to ram (rtl8188ee)"
From: Larry Finger @ 2017-10-17 14:17 UTC (permalink / raw)
To: Lauro Costa; +Cc: linux-wireless
In-Reply-To: <03101f6d-5160-a3cf-3507-4d79a59cccea@polilinux.com.br>
On 10/17/2017 09:03 AM, Lauro Costa wrote:
> Dear maintainer,
>
> I have opened a bug report on bugzilla [1] regarding this issue I find when I
> attempt to suspend to ram, unfortunately no one has replied to me yet.
>
> I assumed this issue is related to the driver rtl8188ee since the black screen
> doesn't happen when I rmmod the wifi driver, but I'm not sure what I have is
> enough to assume this.
>
> Do you know if this driver rtl8188ee is supposed to support suspend to ram?
>
> This system log message:
>
> |(NULL device *): firmware: direct-loading firmware rtlwifi/rtl8188efw.bin|
>
> is something I haven't seen before, I don't understand why it says (NULL device
> *). Could it mean there is something else wrong and the rtl driver crashes as a
> result of that?
>
> I'm not sure how to further investigate this issue, so any advice you could give
> here or in the bug report would be much appreciated.
Sorry that I missed that bug report. Unfortunately, without the traceback from
the occurrence of the bug, it will be very difficult to find the problem.
If you add a script to unload the module when the machine hibernates or
suspends, and reloads it on startup, you should be able to avoid the lockups.
I will try to duplicate the problem here.
Larry
^ permalink raw reply
* Re: [PATCH 00/58] networking: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-17 14:18 UTC (permalink / raw)
To: Kees Cook
Cc: David S. Miller, netdev, Thomas Gleixner, linux-kernel,
linux-wireless
In-Reply-To: <1508200182-104605-1-git-send-email-keescook@chromium.org>
+ linux-wireless
Hi Kees,
Kees Cook <keescook@chromium.org> writes:
> This is the current set of outstanding networking patches to perform
> conversions to the new timer interface (rebased to -next). This is not
> all expected conversions, but it contains everything needed in networking
> to eliminate init_timer(), and all the non-standard setup_*_timer() uses.
So this also includes patches which I had queued for
wireless-drivers-next:
https://patchwork.kernel.org/patch/9986253/
https://patchwork.kernel.org/patch/9986245/
And looking at patchwork[1] I have even more timer_setup() related
patches from you. It would be really helpful if you could clearly
document to which tree you want the patches to be applied. I don't care
if it's net-next or wireless-drivers-next as long as it's not the both
(meaning that both Dave and me apply the same patch, which would be
bad). The thing is that I really do not have time to figure out for
every patch via which tree it's supposed to go.
For now I'll just drop all your timer_setup() related patches from my
queue and I'll assume Dave will take those. Ok?
[1] https://patchwork.kernel.org/project/linux-wireless/list/
--
Kalle Valo
^ permalink raw reply
* Re: rtlwifi: Fix typo in if ... else if ... else construct
From: Kalle Valo @ 2017-10-17 14:21 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting, kbuild-all, Julia Lawall
In-Reply-To: <20171015015402.11217-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The kbuild test robot reports two conditions with no effect (if == else).
> These are the result of copy and paste typographical errors.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Cc: Birming Chiu <birming@realtek.com>
> Cc: Shaofu <shaofu@realtek.com>
> Cc: Steven Ting <steventing@realtek.com>
> Cc: kbuild-all@01.org
> Cc: Julia Lawall <julia.lawall@lip6.fr>
Patch applied to wireless-drivers-next.git, thanks.
a7986ce1cb01 rtlwifi: Fix typo in if ... else if ... else construct
--
https://patchwork.kernel.org/patch/10006693/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: bcma: use bcma_debug and pr_cont in MIPS driver
From: Kalle Valo @ 2017-10-17 14:23 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, Hauke Mehrtens, Rafał Miłecki
In-Reply-To: <20171016125432.11655-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Using bcma_debug gives a device-specific prefix for messages and pr_cont
> is a common helper for continuing a line.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-By: Hauke Mehrtens <hauke@hauke-m.de>
Patch applied to wireless-drivers-next.git, thanks.
66cc04424960 bcma: use bcma_debug and pr_cont in MIPS driver
--
https://patchwork.kernel.org/patch/10008245/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Johannes Berg @ 2017-10-17 15:10 UTC (permalink / raw)
To: Jesse Sung
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <CAH10aOizMKboDOW27gvz=YEcRT1_tMj+W6iwJ47n=T=-Q7U14A@mail.gmail.com>
Hi,
> > > https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
> > >
> > > Can you also give that a spin?
Thanks for testing!
> > Issued four reassociate, the network interface is still alive. Also
> > with this patch it stays with BSSID1 and I don't see any
> > "Association request to the driver failed" in the process.
>
> Correction: I can still see "Association request to the driver
> failed" and switching between BSSIDs with more reassociates but I
> think that shouldn't be an issue?
Not sure what you mean by "with more reassociates"?
In any case, we suspect that there's another underlying issue in
mwifiex, which happens to tickle this problem.
Could you record a full trace with -e cfg80211 for me (and send it
privately, please compress trace.dat e.g. with xz, it compresses really
well)
Thanks,
johannes
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Jesse Sung @ 2017-10-17 15:25 UTC (permalink / raw)
To: Johannes Berg
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer, Anthony Wong,
Jason Yen, Terry.Wey, linux-wireless
In-Reply-To: <1508253043.10607.89.camel@sipsolutions.net>
On Tue, Oct 17, 2017 at 11:10 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Hi,
>
>> > > https://p.sipsolutions.net/8f9d5917a5cbe4b3.txt
>> > >
>> > > Can you also give that a spin?
>
> Thanks for testing!
>
>> > Issued four reassociate, the network interface is still alive. Also
>> > with this patch it stays with BSSID1 and I don't see any
>> > "Association request to the driver failed" in the process.
>>
>> Correction: I can still see "Association request to the driver
>> failed" and switching between BSSIDs with more reassociates but I
>> think that shouldn't be an issue?
>
> Not sure what you mean by "with more reassociates"?
I mean do more "reassociate" in the wpa_cli. :)
Thanks,
Jesse
^ permalink raw reply
* Re: [PATCH v2] ath10k: Retry pci probe on failure.
From: Ben Greear @ 2017-10-17 15:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Adrian Chadd, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <87376imabh.fsf@kamboji.qca.qualcomm.com>
On 10/17/2017 01:45 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 10/13/2017 08:50 AM, Adrian Chadd wrote:
>>> On 13 October 2017 at 05:41, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>>> greearb@candelatech.com writes:
>>>>
>>>>> From: Ben Greear <greearb@candelatech.com>
>>>>>
>>>>> This works around a problem we see when sometimes the wifi NIC does
>>>>> not respond the first time. This seems to happen especially often on
>>>>> some of the 9984 NICs in mid-range platforms.
>>>>>
>>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>>
>>>> [...]
>>>>
>>>>> -static int ath10k_pci_probe(struct pci_dev *pdev,
>>>>> - const struct pci_device_id *pci_dev)
>>>>> +static int __ath10k_pci_probe(struct pci_dev *pdev,
>>>>> + const struct pci_device_id *pci_dev)
>>>>> {
>>>>> int ret = 0;
>>>>> struct ath10k *ar;
>>>>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>>>>> return ret;
>>>>> }
>>>>>
>>>>> +static int ath10k_pci_probe(struct pci_dev *pdev,
>>>>> + const struct pci_device_id *pci_dev)
>>>>> +{
>>>>> + int cnt = 0;
>>>>> + int rv;
>>>>> + do {
>>>>> + rv = __ath10k_pci_probe(pdev, pci_dev);
>>>>> + if (rv == 0)
>>>>> + return rv;
>>>>> + pr_err("ath10k: failed to probe PCI : %d, retry-count: %d\n", rv, cnt);
>>>>> + mdelay(10); /* let the ath10k firmware gerbil take a small break */
>>>>> + } while (cnt++ < 10);
>>>>> + return rv;
>>>>> +}
>>>>
>>>> This is a sledgehammer approach and it causes reload for all error
>>>> cases, like when hardware is broken or memory allocation is failing.
>>>>
>>>> When the problem happens does it always fail at the the same place? Is
>>>> it hw reset or something else? It's better to retry the invidiual action
>>>> than to do this hack. Or is it just some more delay needed somewhere?
>>>
>>> I am seeing WMI timeouts during initial firmware load and wait on
>>> QCA9984 + BCM7444S SoC.
>>> My guess is the WMI wakeup time is not "right" enough and needs to be
>>> extended a little bit.
>>>
>>> But then, I have played a lot of whackamole with WMI timeouts during
>>> my loooong porting effort..
>>
>> The failure I saw was a failure to wake pci, and from comments, it seems that
>> the current wait is longer than what should be required, and it warns on slow
>> wakes, and I never saw that warning. So I assume that waiting longer would not help.
>>
>> I saw it fail twice in a row to wake pci and then succeed on the third
>> try, for instance,
>> when testing my patch.
>>
>> As for a big hammer, I guess we could check for certain return codes if you think
>> that is better than just retrying all failures?
>
> ath10k_pci_probe() has a lots of stuff which should not affect your
> problem, like allocating memory, setting up timers and interrupts etc.
> It's quite ugly to redo that in every cycle. A more fine grained
> solution, like looping specific action (reset, wake whatever) is much
> more preferred.
>
> Do you have debug logs of failing cases?
I'll gather the logs next time I see this problem.
The patch I wrote likely does more than the minimal required to fix
this problem, but it does not complicate the code much, so I think that
is a benefit. If we try to make it more specific, it will first likely
require a lot of testing effort to see if it is as effective, and second, it
will likely complicate the probe method quite a bit.
Its not like this is a performance issue...the extra loops will only be run
if the probe fails, and only on driver load.
If the driver fails to load due to issues that my hack cannot work around,
then the user has bigger problems than an extra second of time during the
boot.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: pull-request: mac80211 2017-10-16
From: Jason A. Donenfeld @ 2017-10-17 18:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, Netdev, linux-wireless
In-Reply-To: <1508219181.10607.45.camel@sipsolutions.net>
On Tue, Oct 17, 2017 at 7:46 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> If it's not equal, you execute so much code
> beneath, going to the driver etc., that I'd think this particular time
> is in the noise.
Usually presumptions like this get you in trouble when some crafty
academic has a smart idea about that noise. I'll send a patch.
^ permalink raw reply
* [PATCH] mac80211: use constant time comparison with keys
From: Jason A. Donenfeld @ 2017-10-17 18:32 UTC (permalink / raw)
To: Johannes Berg, David Miller, netdev, linux-wireless; +Cc: Jason A. Donenfeld
In-Reply-To: <CAHmME9qd_m-FDj1E+eiBYWKvnMBvr0tWVcJ4ph2tr=Y1d_tb1g@mail.gmail.com>
Otherwise we risk leaking information via timing side channel.
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
net/mac80211/key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index ae995c8480db..035d16fe926e 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/export.h>
#include <net/mac80211.h>
+#include <crypto/algapi.h>
#include <asm/unaligned.h>
#include "ieee80211_i.h"
#include "driver-ops.h"
@@ -635,7 +636,7 @@ int ieee80211_key_link(struct ieee80211_key *key,
* new version of the key to avoid nonce reuse or replay issues.
*/
if (old_key && key->conf.keylen == old_key->conf.keylen &&
- !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ !crypto_memneq(key->conf.key, old_key->conf.key, key->conf.keylen)) {
ieee80211_key_free_unused(key);
ret = 0;
goto out;
--
2.14.2
^ permalink raw reply related
* [PATCH] wil6210: remove SSID debugfs
From: Johannes Berg @ 2017-10-17 19:33 UTC (permalink / raw)
To: linux-wireless; +Cc: Maya Erez, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This driver shouldn't be using wdev->ssid to start with, as
it's more or less an internal field in cfg80211 used for
various purposes. Reading it is possible through nl80211,
even if that's not really what we should be doing there
for anything but AP type interfaces.
It *really* shouldn't allow modifying it!
Remove the whole debugfs entry.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/ath/wil6210/debugfs.c | 45 ------------------------------
1 file changed, 45 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c
index 6db00c167d2e..e58dc6dc1f9c 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1048,50 +1048,6 @@ static const struct file_operations fops_bf = {
.llseek = seq_lseek,
};
-/*---------SSID------------*/
-static ssize_t wil_read_file_ssid(struct file *file, char __user *user_buf,
- size_t count, loff_t *ppos)
-{
- struct wil6210_priv *wil = file->private_data;
- struct wireless_dev *wdev = wil_to_wdev(wil);
-
- return simple_read_from_buffer(user_buf, count, ppos,
- wdev->ssid, wdev->ssid_len);
-}
-
-static ssize_t wil_write_file_ssid(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct wil6210_priv *wil = file->private_data;
- struct wireless_dev *wdev = wil_to_wdev(wil);
- struct net_device *ndev = wil_to_ndev(wil);
-
- if (*ppos != 0) {
- wil_err(wil, "Unable to set SSID substring from [%d]\n",
- (int)*ppos);
- return -EINVAL;
- }
-
- if (count > sizeof(wdev->ssid)) {
- wil_err(wil, "SSID too long, len = %d\n", (int)count);
- return -EINVAL;
- }
- if (netif_running(ndev)) {
- wil_err(wil, "Unable to change SSID on running interface\n");
- return -EINVAL;
- }
-
- wdev->ssid_len = count;
- return simple_write_to_buffer(wdev->ssid, wdev->ssid_len, ppos,
- buf, count);
-}
-
-static const struct file_operations fops_ssid = {
- .read = wil_read_file_ssid,
- .write = wil_write_file_ssid,
- .open = simple_open,
-};
-
/*---------temp------------*/
static void print_temp(struct seq_file *s, const char *prefix, u32 t)
{
@@ -1695,7 +1651,6 @@ static const struct {
{"stations", 0444, &fops_sta},
{"desc", 0444, &fops_txdesc},
{"bf", 0444, &fops_bf},
- {"ssid", 0644, &fops_ssid},
{"mem_val", 0644, &fops_memread},
{"reset", 0244, &fops_reset},
{"rxon", 0244, &fops_rxon},
--
2.14.2
^ permalink raw reply related
* [PATCH] wil6210: remove wil6210_uapi.h from MAINTAINERS
From: Johannes Berg @ 2017-10-17 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Maya Erez, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This file doesn't exist.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3944f1626911..7051e2ae9971 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14565,7 +14565,6 @@ L: wil6210@qca.qualcomm.com
S: Supported
W: http://wireless.kernel.org/en/users/Drivers/wil6210
F: drivers/net/wireless/ath/wil6210/
-F: include/uapi/linux/wil6210_uapi.h
WIMAX STACK
M: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
--
2.14.2
^ permalink raw reply related
* [PATCH] libertas: don't write wdev->ssid/_len
From: Johannes Berg @ 2017-10-17 19:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When joining an IBSS network, wdev->ssid/_len will already be
set, so there's no need to write them. In any case, they are
internal cfg80211 values, and have very little user-visible
impact.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/marvell/libertas/cfg.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index 71ba2c8d09b5..bb76707881cd 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -1698,9 +1698,6 @@ static void lbs_join_post(struct lbs_private *priv,
0, GFP_KERNEL);
cfg80211_put_bss(priv->wdev->wiphy, bss);
- memcpy(priv->wdev->ssid, params->ssid, params->ssid_len);
- priv->wdev->ssid_len = params->ssid_len;
-
cfg80211_ibss_joined(priv->dev, bssid, params->chandef.chan,
GFP_KERNEL);
--
2.14.2
^ permalink raw reply related
* Re: iwlwifi crash with hostapd
From: Mario Theodoridis @ 2017-10-17 19:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20171016033727.GB13209@us.netrek.org>
[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]
On 16.10.2017 05:37, James Cameron wrote:
> On Sun, Oct 15, 2017 at 06:21:36PM +0200, Mario Theodoridis wrote:
>> Thanks for the pointers, James.
>>
>> On 12.10.2017 23:24, James Cameron wrote:
>>> There's a good chance this problem has been fixed already. You
>>> are using a v4.4 kernel with many patches applied by Ubuntu. Here, we
>>> are more concerned with the latest kernels, and v4.4 is quite old.
>>>
>>> Please test some of the later kernels, see
>>> https://wiki.ubuntu.com/Kernel/MainlineBuilds
>>>
>>> In particular, test v4.13 or v4.14-rc4.
>>
>> I'm having a hard time with that, because the virtualbox-dkms build fails
>> with the 4.13 kernel, and virtualbox unfortunately is essential.
>
> Is virtualbox essential for reproducing the problem, or essential for
> your general use?
It is essential for general use, like Internet connectivity.
> If the former, then that's interesting.
>
> If the latter, then you might instead test the v4.13 or v14-rc4
> kernels for only the problem, and then revert to an older kernel after
> testing.
>
> Either way, to use virtualbox-dkms with a later kernel you may be able
> to upgrade just the virtualbox packages from a later Ubuntu release.
>
> See https://packages.ubuntu.com/virtualbox-dkms and
> https://packages.ubuntu.com/virtualbox for the later versions available.
>
> Purpose of the test can be to help isolate the cause, not only to
> solve your problem.
Thanks for the info.
>
> [...]
> You might also try with later firmware package.
> See https://packages.ubuntu.com/linux-firmware
>
> You might also test with booting installation media in live-mode,
> ignoring the internal disk.
Ok, that was completely off the radar.
I ended up going the other way. I still had a 4.4.0-79-generic kernel
and booted that. It does not have this problem.
After checking out
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
i tried to find the culprit but was not able to trace the back trace to
a potential null pointer or some such. I got stuck at
iwl_mvm_send_cmd_pdu_status not finding a reference to
iwl_mvm_disable_txq from there.
I did got the following diff though
git diff Ubuntu-4.4.0-79.100 Ubuntu-4.4.0-93.116 --
drivers/net/wireless/iwlwifi/ drivers/net/wireless/mac80211_hwsim.c >
wifi.patch
I don't know whether this came from upstream or was ubuntu sourced.
This fixed the issue for now, but now i'm stuck on that kernel :(
While i'm perfectly comfortable with user land C, i have no kernel
experience (clue stick links definitely welcome).
--
Mit freundlichen Grüßen/Best regards
Mario Theodoridis
[-- Attachment #2: wifi.patch --]
[-- Type: text/x-diff, Size: 3174 bytes --]
diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
index b3ad34e..1eb1a82 100644
--- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
@@ -729,12 +729,15 @@ static inline bool iwl_enable_tx_ampdu(const struct iwl_cfg *cfg)
static int iwlagn_mac_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
- enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn,
- u8 buf_size, bool amsdu)
+ struct ieee80211_ampdu_params *params)
{
struct iwl_priv *priv = IWL_MAC80211_GET_DVM(hw);
int ret = -EINVAL;
+ struct ieee80211_sta *sta = params->sta;
+ enum ieee80211_ampdu_mlme_action action = params->action;
+ u16 tid = params->tid;
+ u16 *ssn = ¶ms->ssn;
+ u8 buf_size = params->buf_size;
struct iwl_station_priv *sta_priv = (void *) sta->drv_priv;
IWL_DEBUG_HT(priv, "A-MPDU action on addr %pM tid %d\n",
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index ce12717..1a8ea77 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -826,13 +826,16 @@ iwl_mvm_ampdu_check_trigger(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
static int iwl_mvm_mac_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
- enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid,
- u16 *ssn, u8 buf_size, bool amsdu)
+ struct ieee80211_ampdu_params *params)
{
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
int ret;
bool tx_agg_ref = false;
+ struct ieee80211_sta *sta = params->sta;
+ enum ieee80211_ampdu_mlme_action action = params->action;
+ u16 tid = params->tid;
+ u16 *ssn = ¶ms->ssn;
+ u8 buf_size = params->buf_size;
IWL_DEBUG_HT(mvm, "A-MPDU action on addr %pM tid %d: action %d\n",
sta->addr, tid, action);
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 0cd9512..019d716 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1817,10 +1817,12 @@ static int mac80211_hwsim_testmode_cmd(struct ieee80211_hw *hw,
static int mac80211_hwsim_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
- enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn,
- u8 buf_size, bool amsdu)
+ struct ieee80211_ampdu_params *params)
{
+ struct ieee80211_sta *sta = params->sta;
+ enum ieee80211_ampdu_mlme_action action = params->action;
+ u16 tid = params->tid;
+
switch (action) {
case IEEE80211_AMPDU_TX_START:
ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
@@ -2537,7 +2539,7 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
tasklet_hrtimer_init(&data->beacon_timer,
mac80211_hwsim_beacon,
- CLOCK_MONOTONIC_RAW, HRTIMER_MODE_ABS);
+ CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
spin_lock_bh(&hwsim_radio_lock);
list_add_tail(&data->list, &hwsim_radios);
^ permalink raw reply related
* [PATCH] wil6210: disallow changing RSN in beacon change
From: Johannes Berg @ 2017-10-17 19:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Maya Erez, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This is a code path that will never really get hit anyway, since
it's nonsense to change the beacon of an existing BSS to suddenly
include or no longer include the RSN IE. Reject this instead of
having the dead code, and get rid of accessing wdev->ssid/_len by
way of that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/ath/wil6210/cfg80211.c | 22 ++++------------------
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 85d5c04618eb..a81711451691 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1389,7 +1389,6 @@ static int wil_cfg80211_change_beacon(struct wiphy *wiphy,
struct cfg80211_beacon_data *bcon)
{
struct wil6210_priv *wil = wiphy_to_wil(wiphy);
- int rc;
u32 privacy = 0;
wil_dbg_misc(wil, "change_beacon\n");
@@ -1400,24 +1399,11 @@ static int wil_cfg80211_change_beacon(struct wiphy *wiphy,
bcon->tail_len))
privacy = 1;
- /* in case privacy has changed, need to restart the AP */
- if (wil->privacy != privacy) {
- struct wireless_dev *wdev = ndev->ieee80211_ptr;
-
- wil_dbg_misc(wil, "privacy changed %d=>%d. Restarting AP\n",
- wil->privacy, privacy);
-
- rc = _wil_cfg80211_start_ap(wiphy, ndev, wdev->ssid,
- wdev->ssid_len, privacy,
- wdev->beacon_interval,
- wil->channel, bcon,
- wil->hidden_ssid,
- wil->pbss);
- } else {
- rc = _wil_cfg80211_set_ies(wiphy, bcon);
- }
+ /* privacy (really RSN) shouldn't be changing */
+ if (wil->privacy != privacy)
+ return -EINVAL;
- return rc;
+ return _wil_cfg80211_set_ies(wiphy, bcon);
}
static int wil_cfg80211_start_ap(struct wiphy *wiphy,
--
2.14.2
^ permalink raw reply related
* Re: [PATCH 00/58] networking: Convert timers to use timer_setup()
From: Kees Cook @ 2017-10-17 19:47 UTC (permalink / raw)
To: Kalle Valo
Cc: David S. Miller, Network Development, Thomas Gleixner, LKML,
linux-wireless
In-Reply-To: <87mv4pvowa.fsf@purkki.adurom.net>
On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> + linux-wireless
>
> Hi Kees,
>
> Kees Cook <keescook@chromium.org> writes:
>
>> This is the current set of outstanding networking patches to perform
>> conversions to the new timer interface (rebased to -next). This is not
>> all expected conversions, but it contains everything needed in networking
>> to eliminate init_timer(), and all the non-standard setup_*_timer() uses.
>
> So this also includes patches which I had queued for
> wireless-drivers-next:
>
> https://patchwork.kernel.org/patch/9986253/
> https://patchwork.kernel.org/patch/9986245/
>
> And looking at patchwork[1] I have even more timer_setup() related
> patches from you. It would be really helpful if you could clearly
> document to which tree you want the patches to be applied. I don't care
Hi! Sorry about that. It's been a bit tricky to juggle everything.
> if it's net-next or wireless-drivers-next as long as it's not the both
> (meaning that both Dave and me apply the same patch, which would be
> bad). The thing is that I really do not have time to figure out for
> every patch via which tree it's supposed to go.
Which split is preferred? I had been trying to separate wireless from
the rest of net (but missed some cases).
> For now I'll just drop all your timer_setup() related patches from my
> queue and I'll assume Dave will take those. Ok?
>
> [1] https://patchwork.kernel.org/project/linux-wireless/list/
I guess I'll wait to see what Dave says.
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] nl80211: don't expose wdev->ssid for most interfaces
From: Johannes Berg @ 2017-10-17 19:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Antonio Quartulli, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
For mesh, this is simply wrong - there's no SSID, only the
mesh ID, so don't expose it at all.
For (P2P) client, it's wrong, because it exposes an internal
value that's only used when certain APIs are used.
For AP, it's actually the only correct case, so leave that.
All other interface types shouldn't be setting this anyway,
so there it won't change anything.
Fixes: b84e7a05f619 ("nl80211: send the NL80211_ATTR_SSID in nl80211_send_iface()")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fce2cbe6a193..d23eb5700788 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2605,10 +2605,32 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 portid, u32 seq, int flag
goto nla_put_failure;
}
- if (wdev->ssid_len) {
- if (nla_put(msg, NL80211_ATTR_SSID, wdev->ssid_len, wdev->ssid))
+ wdev_lock(wdev);
+ switch (wdev->iftype) {
+ case NL80211_IFTYPE_AP:
+ if (wdev->ssid_len &&
+ nla_put(msg, NL80211_ATTR_SSID, wdev->ssid_len, wdev->ssid))
goto nla_put_failure;
+ break;
+ case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_P2P_CLIENT:
+ case NL80211_IFTYPE_ADHOC: {
+ const u8 *ssid_ie;
+ if (!wdev->current_bss)
+ break;
+ ssid_ie = ieee80211_bss_get_ie(&wdev->current_bss->pub,
+ WLAN_EID_SSID);
+ if (!ssid_ie)
+ break;
+ if (nla_put(msg, NL80211_ATTR_SSID, ssid_ie[1], ssid_ie + 2))
+ goto nla_put_failure;
+ break;
+ }
+ default:
+ /* nothing */
+ break;
}
+ wdev_unlock(wdev);
genlmsg_end(msg, hdr);
return 0;
--
2.14.2
^ permalink raw reply related
* [PATCH] cfg80211: fix connect/disconnect edge cases
From: Johannes Berg @ 2017-10-17 19:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
If we try to connect while already connected/connecting, but
this fails, we set ssid_len=0 but leave current_bss hanging,
leading to errors.
Check all of this better, first of all ensuring that we can't
try to connect to a different SSID while connected/ing; ensure
that prev_bssid is set for re-association attempts even in the
case of the driver supporting the connect() method, and don't
reset ssid_len in the failure cases.
While at it, also reset ssid_len while disconnecting unless we
were connected and expect a disconnected event, and warn on a
successful connection without ssid_len being set.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/sme.c | 50 +++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index f38ed490e42b..29bf453a0d5f 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -522,11 +522,6 @@ static int cfg80211_sme_connect(struct wireless_dev *wdev,
return -EOPNOTSUPP;
if (wdev->current_bss) {
- if (!prev_bssid)
- return -EALREADY;
- if (prev_bssid &&
- !ether_addr_equal(prev_bssid, wdev->current_bss->pub.bssid))
- return -ENOTCONN;
cfg80211_unhold_bss(wdev->current_bss);
cfg80211_put_bss(wdev->wiphy, &wdev->current_bss->pub);
wdev->current_bss = NULL;
@@ -1106,11 +1101,35 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
ASSERT_WDEV_LOCK(wdev);
- if (WARN_ON(wdev->connect_keys)) {
- kzfree(wdev->connect_keys);
- wdev->connect_keys = NULL;
+ /*
+ * If we have an ssid_len, we're trying to connect or are
+ * already connected, so reject a new SSID unless it's the
+ * same (which is the case for re-association.)
+ */
+ if (wdev->ssid_len &&
+ (wdev->ssid_len != connect->ssid_len ||
+ memcmp(wdev->ssid, connect->ssid, wdev->ssid_len)))
+ return -EALREADY;
+
+ /*
+ * If connected, reject (re-)association unless prev_bssid
+ * matches the current BSSID.
+ */
+ if (wdev->current_bss) {
+ if (!prev_bssid)
+ return -EALREADY;
+ if (!ether_addr_equal(prev_bssid, wdev->current_bss->pub.bssid))
+ return -ENOTCONN;
}
+ /*
+ * Reject if we're in the process of connecting with WEP,
+ * this case isn't very interesting and trying to handle
+ * it would make the code much more complex.
+ */
+ if (wdev->connect_keys)
+ return -EINPROGRESS;
+
cfg80211_oper_and_ht_capa(&connect->ht_capa_mask,
rdev->wiphy.ht_capa_mod_mask);
@@ -1161,7 +1180,12 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
if (err) {
wdev->connect_keys = NULL;
- wdev->ssid_len = 0;
+ /*
+ * This could be reassoc getting refused, don't clear
+ * ssid_len in that case.
+ */
+ if (!wdev->current_bss)
+ wdev->ssid_len = 0;
return err;
}
@@ -1188,6 +1212,14 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
else if (wdev->ssid_len)
err = rdev_disconnect(rdev, dev, reason);
+ /*
+ * Clear ssid_len unless we actually were fully connected,
+ * in which case cfg80211_disconnected() will take care of
+ * this later.
+ */
+ if (!wdev->current_bss)
+ wdev->ssid_len = 0;
+
return err;
}
--
2.14.2
^ permalink raw reply related
* [PATCH] mac80211: aggregation: Convert timers to use timer_setup()
From: Kees Cook @ 2017-10-17 20:25 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, David S. Miller, netdev, linux-kernel
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
This removes the tid mapping array and expands the tid structures to
add a pointer back to the station, along with the tid index itself.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
Resend, with linux-wireless in Cc (no idea how it got missed before)
---
net/mac80211/agg-rx.c | 41 +++++++++++++++++------------------------
net/mac80211/agg-tx.c | 42 ++++++++++++++++--------------------------
net/mac80211/sta_info.c | 8 --------
net/mac80211/sta_info.h | 12 ++++++++++--
4 files changed, 43 insertions(+), 60 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 88cc1ae935ea..63aba6dbc92a 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -151,21 +151,17 @@ EXPORT_SYMBOL(ieee80211_stop_rx_ba_session);
* After accepting the AddBA Request we activated a timer,
* resetting it after each frame that arrives from the originator.
*/
-static void sta_rx_agg_session_timer_expired(unsigned long data)
+static void sta_rx_agg_session_timer_expired(struct timer_list *t)
{
- /* not an elegant detour, but there is no choice as the timer passes
- * only one argument, and various sta_info are needed here, so init
- * flow in sta_info_create gives the TID as data, while the timer_to_id
- * array gives the sta through container_of */
- u8 *ptid = (u8 *)data;
- u8 *timer_to_id = ptid - *ptid;
- struct sta_info *sta = container_of(timer_to_id, struct sta_info,
- timer_to_tid[0]);
+ struct tid_ampdu_rx *tid_rx_timer =
+ from_timer(tid_rx_timer, t, session_timer);
+ struct sta_info *sta = tid_rx_timer->sta;
+ u16 tid = tid_rx_timer->tid;
struct tid_ampdu_rx *tid_rx;
unsigned long timeout;
rcu_read_lock();
- tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[*ptid]);
+ tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
if (!tid_rx) {
rcu_read_unlock();
return;
@@ -180,21 +176,18 @@ static void sta_rx_agg_session_timer_expired(unsigned long data)
rcu_read_unlock();
ht_dbg(sta->sdata, "RX session timer expired on %pM tid %d\n",
- sta->sta.addr, (u16)*ptid);
+ sta->sta.addr, tid);
- set_bit(*ptid, sta->ampdu_mlme.tid_rx_timer_expired);
+ set_bit(tid, sta->ampdu_mlme.tid_rx_timer_expired);
ieee80211_queue_work(&sta->local->hw, &sta->ampdu_mlme.work);
}
-static void sta_rx_agg_reorder_timer_expired(unsigned long data)
+static void sta_rx_agg_reorder_timer_expired(struct timer_list *t)
{
- u8 *ptid = (u8 *)data;
- u8 *timer_to_id = ptid - *ptid;
- struct sta_info *sta = container_of(timer_to_id, struct sta_info,
- timer_to_tid[0]);
+ struct tid_ampdu_rx *tid_rx = from_timer(tid_rx, t, reorder_timer);
rcu_read_lock();
- ieee80211_release_reorder_timeout(sta, *ptid);
+ ieee80211_release_reorder_timeout(tid_rx->sta, tid_rx->tid);
rcu_read_unlock();
}
@@ -356,14 +349,12 @@ void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
spin_lock_init(&tid_agg_rx->reorder_lock);
/* rx timer */
- setup_deferrable_timer(&tid_agg_rx->session_timer,
- sta_rx_agg_session_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_agg_rx->session_timer,
+ sta_rx_agg_session_timer_expired, TIMER_DEFERRABLE);
/* rx reorder timer */
- setup_timer(&tid_agg_rx->reorder_timer,
- sta_rx_agg_reorder_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_agg_rx->reorder_timer,
+ sta_rx_agg_reorder_timer_expired, 0);
/* prepare reordering buffer */
tid_agg_rx->reorder_buf =
@@ -399,6 +390,8 @@ void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
tid_agg_rx->auto_seq = auto_seq;
tid_agg_rx->started = false;
tid_agg_rx->reorder_buf_filtered = 0;
+ tid_agg_rx->tid = tid;
+ tid_agg_rx->sta = sta;
status = WLAN_STATUS_SUCCESS;
/* activate it for RX */
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index bef516ec47f9..dedbb1fb10e7 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -422,15 +422,12 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
* add Block Ack response will arrive from the recipient.
* If this timer expires sta_addba_resp_timer_expired will be executed.
*/
-static void sta_addba_resp_timer_expired(unsigned long data)
+static void sta_addba_resp_timer_expired(struct timer_list *t)
{
- /* not an elegant detour, but there is no choice as the timer passes
- * only one argument, and both sta_info and TID are needed, so init
- * flow in sta_info_create gives the TID as data, while the timer_to_id
- * array gives the sta through container_of */
- u16 tid = *(u8 *)data;
- struct sta_info *sta = container_of((void *)data,
- struct sta_info, timer_to_tid[tid]);
+ struct tid_ampdu_tx *tid_tx_timer =
+ from_timer(tid_tx_timer, t, addba_resp_timer);
+ struct sta_info *sta = tid_tx_timer->sta;
+ u16 tid = tid_tx_timer->tid;
struct tid_ampdu_tx *tid_tx;
/* check if the TID waits for addBA response */
@@ -525,21 +522,17 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
* After accepting the AddBA Response we activated a timer,
* resetting it after each frame that we send.
*/
-static void sta_tx_agg_session_timer_expired(unsigned long data)
+static void sta_tx_agg_session_timer_expired(struct timer_list *t)
{
- /* not an elegant detour, but there is no choice as the timer passes
- * only one argument, and various sta_info are needed here, so init
- * flow in sta_info_create gives the TID as data, while the timer_to_id
- * array gives the sta through container_of */
- u8 *ptid = (u8 *)data;
- u8 *timer_to_id = ptid - *ptid;
- struct sta_info *sta = container_of(timer_to_id, struct sta_info,
- timer_to_tid[0]);
+ struct tid_ampdu_tx *tid_tx_timer =
+ from_timer(tid_tx_timer, t, session_timer);
+ struct sta_info *sta = tid_tx_timer->sta;
+ u16 tid = tid_tx_timer->tid;
struct tid_ampdu_tx *tid_tx;
unsigned long timeout;
rcu_read_lock();
- tid_tx = rcu_dereference(sta->ampdu_mlme.tid_tx[*ptid]);
+ tid_tx = rcu_dereference(sta->ampdu_mlme.tid_tx[tid]);
if (!tid_tx || test_bit(HT_AGG_STATE_STOPPING, &tid_tx->state)) {
rcu_read_unlock();
return;
@@ -555,9 +548,9 @@ static void sta_tx_agg_session_timer_expired(unsigned long data)
rcu_read_unlock();
ht_dbg(sta->sdata, "tx session timer expired on %pM tid %d\n",
- sta->sta.addr, (u16)*ptid);
+ sta->sta.addr, tid);
- ieee80211_stop_tx_ba_session(&sta->sta, *ptid);
+ ieee80211_stop_tx_ba_session(&sta->sta, tid);
}
int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
@@ -672,14 +665,11 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
tid_tx->timeout = timeout;
/* response timer */
- setup_timer(&tid_tx->addba_resp_timer,
- sta_addba_resp_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_tx->addba_resp_timer, sta_addba_resp_timer_expired, 0);
/* tx timer */
- setup_deferrable_timer(&tid_tx->session_timer,
- sta_tx_agg_session_timer_expired,
- (unsigned long)&sta->timer_to_tid[tid]);
+ timer_setup(&tid_tx->session_timer,
+ sta_tx_agg_session_timer_expired, TIMER_DEFERRABLE);
/* assign a dialog token */
sta->ampdu_mlme.dialog_token_allocator++;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 877d35796776..b5add1464aeb 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -379,14 +379,6 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
if (sta_prepare_rate_control(local, sta, gfp))
goto free_txq;
- for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
- /*
- * timer_to_tid must be initialized with identity mapping
- * to enable session_timer's data differentiation. See
- * sta_rx_agg_session_timer_expired for usage.
- */
- sta->timer_to_tid[i] = i;
- }
for (i = 0; i < IEEE80211_NUM_ACS; i++) {
skb_queue_head_init(&sta->ps_tx_buf[i]);
skb_queue_head_init(&sta->tx_filtered[i]);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 5c54acd10562..1b9c1e81495d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -126,6 +126,8 @@ enum ieee80211_agg_stop_reason {
AGG_STOP_DESTROY_STA,
};
+struct sta_info;
+
/**
* struct tid_ampdu_tx - TID aggregation information (Tx).
*
@@ -133,8 +135,10 @@ enum ieee80211_agg_stop_reason {
* @session_timer: check if we keep Tx-ing on the TID (by timeout value)
* @addba_resp_timer: timer for peer's response to addba request
* @pending: pending frames queue -- use sta's spinlock to protect
+ * @sta: station we are attached to
* @dialog_token: dialog token for aggregation session
* @timeout: session timeout value to be filled in ADDBA requests
+ * @tid: index in station tid list
* @state: session state (see above)
* @last_tx: jiffies of last tx activity
* @stop_initiator: initiator of a session stop
@@ -158,9 +162,11 @@ struct tid_ampdu_tx {
struct timer_list session_timer;
struct timer_list addba_resp_timer;
struct sk_buff_head pending;
+ struct sta_info *sta;
unsigned long state;
unsigned long last_tx;
u16 timeout;
+ u16 tid;
u8 dialog_token;
u8 stop_initiator;
bool tx_stop;
@@ -181,12 +187,14 @@ struct tid_ampdu_tx {
* @reorder_time: jiffies when skb was added
* @session_timer: check if peer keeps Tx-ing on the TID (by timeout value)
* @reorder_timer: releases expired frames from the reorder buffer.
+ * @sta: station we are attached to
* @last_rx: jiffies of last rx activity
* @head_seq_num: head sequence number in reordering buffer.
* @stored_mpdu_num: number of MPDUs in reordering buffer
* @ssn: Starting Sequence Number expected to be aggregated.
* @buf_size: buffer size for incoming A-MPDUs
* @timeout: reset timer value (in TUs).
+ * @tid: index in station tid list
* @rcu_head: RCU head used for freeing this struct
* @reorder_lock: serializes access to reorder buffer, see below.
* @auto_seq: used for offloaded BA sessions to automatically pick head_seq_and
@@ -208,6 +216,7 @@ struct tid_ampdu_rx {
u64 reorder_buf_filtered;
struct sk_buff_head *reorder_buf;
unsigned long *reorder_time;
+ struct sta_info *sta;
struct timer_list session_timer;
struct timer_list reorder_timer;
unsigned long last_rx;
@@ -216,6 +225,7 @@ struct tid_ampdu_rx {
u16 ssn;
u16 buf_size;
u16 timeout;
+ u16 tid;
u8 auto_seq:1,
removed:1,
started:1;
@@ -447,7 +457,6 @@ struct ieee80211_sta_rx_stats {
* plus one for non-QoS frames)
* @tid_seq: per-TID sequence numbers for sending to this STA
* @ampdu_mlme: A-MPDU state machine state
- * @timer_to_tid: identity mapping to ID timers
* @mesh: mesh STA information
* @debugfs_dir: debug filesystem directory dentry
* @dead: set to true when sta is unlinked
@@ -554,7 +563,6 @@ struct sta_info {
* Aggregation information, locked with lock.
*/
struct sta_ampdu_mlme ampdu_mlme;
- u8 timer_to_tid[IEEE80211_NUM_TIDS];
#ifdef CONFIG_MAC80211_DEBUGFS
struct dentry *debugfs_dir;
--
2.7.4
--
Kees Cook
Pixel Security
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox