* Re: [v2] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-10-04 0:16 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain
In-Reply-To: <20161003130407.4D94161803@smtp.codeaurora.org>
Hello Kalie,
On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rajat Jain <rajatja@google.com> wrote:
>> Enable notifying wakeup source to the PM core in case of
>> a wake on wireless LAN event.
>>
>> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
>> Signed-off-by: Rajat Jain <rajatja@google.com>
>> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
>> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
>> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
>
> The commit log doesn't give any background info. Does this fix a bug or
> why is it needed?
Some of chromeos' features (called "darkresume" in chromeos
terminology) use and track the wake up sources using the wakeup
attributes in sysfs. Since the wireless device can wake up the host,
hence we wanted to add it as a wakeup source to the system, and in the
case of an actual wakeup event, trigger to the PM core that it was
indeed caused by the device and it increments the different counters
etc. In the absence of this patch, the feature wasn't working very
well (as it was apparently confused about the cause of wake up).
Thanks,
Rajat
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-09-30
From: David Miller @ 2016-10-04 0:07 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1475489220.5817.0.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 03 Oct 2016 12:07:00 +0200
> On Mon, 2016-10-03 at 01:54 -0400, David Miller wrote:
>>
>> Could you please look into this and send me a new pull request with
>> the conflicts resolved?
>>
>
> Sure, will do (tomorrow, we have a holiday today).
>
> Would you prefer I send you the merge resolution for your tree, or just
> pull in net for a new pull request?
Resolve it using net-next since that is what I will pull it into.
^ permalink raw reply
* Re: Final 4.8 w-t build is wt-2016-10-03
From: Bob Copeland @ 2016-10-03 23:36 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <1651822.AbJigUgJvV@debian64>
On Mon, Oct 03, 2016 at 04:42:58PM +0200, Christian Lamparter wrote:
> Thanks for the timely update.
> I have a request: can you please pull Linus' kernel tags?
> Currently the last tag from Linus' is v4.4-rc4 [0] and
> everything between v4.4-rc5 and v4.8 is missing?!
I've done this now.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Malinen, Jouni @ 2016-10-03 21:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <1473674982.29016.10.camel@sipsolutions.net>
T24gTW9uLCBTZXAgMTIsIDIwMTYgYXQgMTI6MDk6NDJQTSArMDIwMCwgSm9oYW5uZXMgQmVyZyB3
cm90ZToNCj4gSSBoYXZlIG5vIG1ham9yIG9iamVjdGlvbnMgdG8gdGhpcy4gSG93ZXZlciwgYSBm
ZXcgdGhpbmdzOg0KPiANCj4gMSkgYXJlIHlvdSBwbGFubmluZyB0byBhZGQgc3VwcG9ydCBmb3Ig
dGhpcyBpbnRvIGEga2VybmVsIGRyaXZlciBhdA0KPiDCoCDCoGFsbCwgYW55d2F5Pw0KPiAyKSBh
cmUgeW91IHBsYW5uaW5nIHRvIGhhdmUgYSBkcml2ZXIgdXBzdHJlYW0gdGhhdCBjb250YWlucyB0
aGUgbm93DQo+IMKgIMKgbmVjZXNzYXJ5IHBhcnNpbmc/DQo+IA0KPiBEZXBlbmRpbmcgb24gdGhl
IGFuc3dlcnMsIEkgc3VwcG9zZSB3ZSBjb3VsZC9zaG91bGQgbWVyZ2UgdGhpczoNCj4gDQo+IG5v
IMKgKiDCoDogZG9uJ3QgbWVyZ2UNCj4geWVzIG5vIDogbWVyZ2UNCj4geWVzIHllczogZG9uJ3Qg
bWVyZ2UsIHB1dCBwYXJzaW5nIGludG8gY2ZnODAyMTENCj4gDQo+IEkgZ3Vlc3M/DQoNClRoZSBt
YWluIGdvYWwgb2YgdGhpcyB3YXMgdG8gc2VlIGlmIHdlIGNhbiByZWR1Y2UgYWN0dWFsIGRyaXZl
cg0KaW1wbGVtZW50YXRpb24gc2l6ZSBhbmQgbWF5YmUgZXZlbiBtb3JlIHNvIHRvIHByZXBhcmUg
Zm9yIDgwMi4xMWF4DQpjaGFuZ2VzIChpLmUuLCBzZWUgd2hhdCB3ZSBhcmUgZG9pbmcgY3VycmVu
dGx5IGZvciBjb25maWd1cmluZyBIVC9WSFQgaW4NCmEgd2F5IHRoYXQgY291bGQgYmUgZG9uZSBi
ZXR0ZXIpLg0KDQpBcyB5b3Ugbm90ZWQgZWFybGllciwgdGhpcyB3b3VsZCBub3QgcmVhbGx5IGFs
bG93IHRoZSBkcml2ZXIgdG8gZHJvcCBpdHMNCkhUL1ZIVCByZWxhdGVkIHBhcnNpbmcgb3BlcmF0
aW9ucyB3aXRob3V0IG1ha2luZyBzdXJlIHVzZXIgc3BhY2UNCmNvbXBvbmVudHMgd2VyZSB1cGRh
dGVkIGFzIHdlbGwuIFRoZSBhcHByb2FjaCB0byBhdm9pZCB0aGF0IGlzIHRoYXQNCiJwYXJzaW5n
IGludG8gY2ZnODAyMTEiLg0KDQpMb29raW5nIGF0IHRoZSBjdXJyZW50IGluLXRyZWUgZHJpdmVy
cywgaXQgbG9va3MgbGlrZSBmb2xsb3dpbmcNCmFwcHJvYWNoZXMgaGF2ZSBiZWVuIHVzZWQ6DQoN
CmF0aDZrbDoNClVzZSBjZmc4MDIxMV9nZXRfY2hhbmRlZl90eXBlKCZpbmZvLT5jaGFuZGVmKSAh
PSBOTDgwMjExX0NIQU5fTk9fSFQgdG8NCmRldGVybWluZSB3aGV0aGVyIEhUIGlzIGVuYWJsZWQu
IE5vIFZIVCBzdXBwb3J0LiBIVC1yZXF1aXJlZCBjYXNlIG5vdA0KY292ZXJlZC4gTm8gcGFyc2lu
ZyBvZiBIVC9WSFQgSUVzIHVzZWQuDQoNCmJyY21mbWFjOg0KVXNlcyBpbmZvLT5jaGFuZGVmLiBO
b3QgY2xlYXIgaG93IEhUL1ZIVCBjb3VsZCBiZSBkaXNhYmxlZCBvciByZXF1aXJlZC4NCk5vdGU6
IFBhcnNlcyBCZWFjb24gSUVzIGZvciBDb3VudHJ5IGFuZCBTU0lEIChhcyBiYWNrdXAgZm9yIHNz
aWQgPT0NCk5VTEwhPyksIFJTTiwgV1BBLg0KDQptd2lmaWV4Og0KVXNlcyBpbmZvLT5jaGFuZGVm
LiBQYXJzZXMgQmVhY29uIHRhaWw6IEVuYWJsZXMgVkhUIGJhc2VkIG9uIHNlYXJjaGluZw0KaW5m
by0+YmVhY29uLnRhaWwgZm9yIFZIVCBDYXBhYmlsaXR5IGVsZW1lbnQuIFBhcnNlcyBIVCBDYXBh
YmlsaXR5IHRvDQpkZXRlcm1pbmUgd2hldGhlciBIVCBpcyB0byBiZSBzdXBwb3J0ZWQgYW5kIGFs
c28gdG8gc2V0IHZhcmlvdXMgSFQNCnBhcmFtZXRlcnMuIERvZXMgbm90IHNlZW0gdG8gaGF2ZSBz
dXBwb3J0IGZvciBIVC9WSFQtcmVxdWlyZWQuDQoNCg0KU28gSSBndWVzcyB0aGVyZSBjb3VsZCBi
ZSBzb21lIGNvZGUgc2hhcmluZyBhbmQgY2xlYW51cCBkb25lIHdpdGggdGhlDQpleGlzdGluZyBp
bi10cmVlIGRyaXZlcnMuIEVzcGVjaWFsbHkgdGhlIG13aWZpZXggZXhhbXBsZSBsb29rcyBsaWtl
DQpzb21ldGhpbmcgdGhhdCB0cmlnZ2VyZWQgdXMgdG8gbG9vayBhdCB0aGlzLiBJJ20gbm90IHN1
cmUgd2UnZCBwcm9wb3NlDQphZGRpbmcgYW55IG5ldyBkcml2ZXIgd2l0aCB0aGUgZHJpdmVyIGNv
ZGUgaXRzZWxmIGRvaW5nIEhUL1ZIVCBJRQ0KcGFyc2luZyBhbmQgc2luY2UgYXRoNmtsIGRpZCBu
b3QgZG8gdGhpcyBlaXRoZXIsIEkgZG9uJ3Qgc2VlIHVzIGNoYW5naW5nDQpleGlzdGluZyBpbi10
cmVlIGRyaXZlcnMgdG8gdXNlIHRoaXMgZWl0aGVyLg0KDQpJJ20gbm90IHN1cmUgdGhlcmUgd291
bGQgcmVhbGx5IGJlIGVub3VnaCBqdXN0aWZpY2F0aW9uIHRvIGFkZCB0aGlzDQpzcGVjaWZpYyBw
YXRjaCBkdWUgdG8gdGhlIGFzc3VtZWQgdXNlciBzcGFjZSB1cGRhdGUuIEFkZGluZyBzb21lIG9m
IHRoZQ0KSFQvVkhUIGVsZW1lbnQgcGFyc2luZyBpbiBjZmc4MDIxMSBtaWdodCBiZW5lZml0IG9u
IG9yIHR3byBvZiB0aGUNCmluLXRyZWUgZHJpdmVycyBpZiB0aGVpciBtYWludGFpbmVycyBhcmUg
aW50ZXJlc3RlZCBpbiB0aGF0LiBUaGF0IHNhaWQsDQp3aXRob3V0IGFkZGl0aW9uYWwgaW50ZXJl
c3QsIEknbSBzdGFydGluZyB0byBsZWFuIHRvd2FyZHMgdXNpbmcgdGhpcyBhcw0KYW4gZXhhbXBs
ZSBvZiB3aGF0IHR5cGUgb2YgcGFyYW1ldGVycyB3ZSBuZWVkIHRvIGFkZCBmb3IgSEUgZnJvbSB0
aGUNCmJlZ2lubmluZyBhbmQgbm90IG1lcmdlIHRoaXMgcGF0Y2guDQoNCi0tIA0KSm91bmkgTWFs
aW5lbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUEdQIGlkIEVG
Qzg5NUZB
^ permalink raw reply
* [PATCH 3/3] ath6kl: configure SDIO when power is reapplied
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475517604-17710-1-git-send-email-james.minor@ni.com>
When power is removed from the device, all of the SDIO settings
return to default. Fix that by reconfiguring after power is
applied.
Signed-off-by: James Minor <james.minor@ni.com>
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index 8261e24..c2df075 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -75,6 +75,8 @@ struct ath6kl_sdio {
#define CMD53_ARG_FIXED_ADDRESS 0
#define CMD53_ARG_INCR_ADDRESS 1
+static int ath6kl_sdio_config(struct ath6kl *ar);
+
static inline struct ath6kl_sdio *ath6kl_sdio_priv(struct ath6kl *ar)
{
return ar->hif_priv;
@@ -526,8 +528,15 @@ static int ath6kl_sdio_power_on(struct ath6kl *ar)
*/
msleep(10);
+ ret = ath6kl_sdio_config(ar);
+ if (ret) {
+ ath6kl_err("Failed to config sdio: %d\n", ret);
+ goto out;
+ }
+
ar_sdio->is_disabled = false;
+out:
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] ath6kl: fix busreqs so they can be reused when sg is cleaned up
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475517604-17710-1-git-send-email-james.minor@ni.com>
To reuse the busreqs in case of hardware restart, they must be
properly reinitialized. If the scat_req pointer isn't reset to
0, __ath6kl_sdio_write_async() will assume there is sg work to be
done (causing a kernel OOPS).
Signed-off-by: James Minor <james.minor@ni.com>
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index eab0ab9..96ed060 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -703,8 +703,10 @@ static void ath6kl_sdio_cleanup_scatter(struct ath6kl *ar)
* ath6kl_hif_rw_comp_handler() with status -ECANCELED so
* that the packet is properly freed?
*/
- if (s_req->busrequest)
+ if (s_req->busrequest) {
+ s_req->busrequest->scat_req = 0;
ath6kl_sdio_free_bus_req(ar_sdio, s_req->busrequest);
+ }
kfree(s_req->virt_dma_buf);
kfree(s_req->sgentries);
kfree(s_req);
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Allow ath6kl to be restarted
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475510510-16906-1-git-send-email-james.minor@ni.com>
To work around a boot issue with the AR6234, I discovered a few
instances where error cleanup code is not working as expected.
A full solution for the boot issue is being worked up, but in the
mean time these fixes make error cleanup work properly.
James Minor (3):
ath6kl: fix busreqs so they can be reused when sg is cleaned up
ath6kl: after cleanup properly reflect that sg is disabled
ath6kl: configure SDIO when power is reapplied
drivers/net/wireless/ath/ath6kl/sdio.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/3] ath6kl: after cleanup properly reflect that sg is disabled
From: James Minor @ 2016-10-03 18:00 UTC (permalink / raw)
To: linux-wireless, ath6kl
Cc: kvalo, julia.cartwright, steve.derosier, James Minor
In-Reply-To: <1475517604-17710-1-git-send-email-james.minor@ni.com>
This allows the hardware to be restarted, as it will cause the
sg to be reinitialized.
Signed-off-by: James Minor <james.minor@ni.com>
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/net/wireless/ath/ath6kl/sdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index 96ed060..8261e24 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -714,6 +714,8 @@ static void ath6kl_sdio_cleanup_scatter(struct ath6kl *ar)
spin_lock_bh(&ar_sdio->scat_lock);
}
spin_unlock_bh(&ar_sdio->scat_lock);
+
+ ar_sdio->scatter_enabled = false;
}
/* setup of HIF scatter resources */
--
1.9.1
^ permalink raw reply related
* Re: Final 4.8 w-t build is wt-2016-10-03
From: Bob Copeland @ 2016-10-03 15:41 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <1651822.AbJigUgJvV@debian64>
On Mon, Oct 03, 2016 at 04:42:58PM +0200, Christian Lamparter wrote:
> Hello,
>
> On Monday, October 3, 2016 9:45:07 AM CEST Bob Copeland wrote:
> > Per the subject, Linus released 4.8 yesterday so, unless I broke something
> > in recent conflict resolutions, wireless-testing is on pause until the
> > merge window closes in two weeks. Have a happy (Canadian) thanksgiving!
> >
> > https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
>
> Thanks for the timely update.
> I have a request: can you please pull Linus' kernel tags?
> Currently the last tag from Linus' is v4.4-rc4 [0] and
> everything between v4.4-rc5 and v4.8 is missing?!
Sure, I can start including them. I stopped pushing them in 4.4 era
because I thought it might be too cluttered to have these non-wt tags
sitting around, but it's no problem to go back and push the old ones
and do that going forward.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands
From: Rob Herring @ 2016-10-03 15:22 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Mark Rutland, Frank Rowand, devicetree@vger.kernel.org,
Felix Fietkau, linux-wireless, ath9k-devel, ath9k-devel,
Kalle Valo
In-Reply-To: <20161002225059.16757-1-martin.blumenstingl@googlemail.com>
On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> There are at least two drivers (ath9k and mt76) out there, where
> devicetree authors need to override the enabled bands.
>
> For ath9k there is only one use-case: disabling a band which has been
> incorrectly enabled by the vendor in the EEPROM (enabling a band is not
> possible because the calibration data would be missing in the EEPROM).
> The mt76 driver (currently pending for review) however allows enabling
> and disabling the 2.4GHz and 5GHz band, see [0].
>
> Based on the discussion of (earlier versions of) my ath9k devicetree
> patch it was suggested [1] that we use enable- and disable- properties.
> The current patch implements:
> - bands can be enabled or disabled with the corresponding property
> - if both (disable and enable) properties are given and a driver asks
> whether the band is enabled then the logic will return false (= not
> enabled, preferring the disabled flag)
> - if both (disable and enable) properties are given and a driver asks
> whether the band is disabled then the logic will return true (again,
> preferring the disabled flag over the enabled flag)
>
> We can still change the logic to do what the mt76 driver does (I am
> fine with both solutions):
> - property not available: driver decides which bands to enable
> - property set to 0: disable the band
> - property set to 1: enable the band
I prefer this way. Really, I'd prefer just a boolean disable property.
I'm not sure why you need the enable. We usually have these tri-state
properties when you want not present to mean use the bootloader or
default setting. Try to make not present the most common case.
> The new code has been integrated into ath9k to demonstrate how to use
> it (with the benefit that the disable_2ghz and disable_5ghz settings
> from the ath9k_platform_data can now also be configured via .dts).
>
> open questions/decisions needed:
> - where to place this new code? I put it into drivers/of/of_ieee80211
> because that's where most other functions live.
> However, I found that this makes backporting the code harder (using
> wireless-backports from the driver-backports project [2])
We are generally moving subsystem specific code like this out of
drivers/of/, so please do that here. Maybe someone will get motivated
to move the other networking code out too.
> - we need a decision whether we want to go with two flags for each
> band (enable-ieee80211-band and disable-ieee80211-band) or if we
> prefer the solution from the mt76 driver (which means that the
> property for a band is absent for auto-detection, or
> ieee80211-band-enabled = <0/1> is specified. we could also move
> the 0 and 1 to a header file of course to make it easer to read,
> such as IEEE80211_BAND_ENABLED and IEEE80211_BAND_DISABLED)
Please don't add defines for this. 0/1 meaning false/true is clear enough IMO.
Rob
^ permalink raw reply
* Re: Final 4.8 w-t build is wt-2016-10-03
From: Christian Lamparter @ 2016-10-03 14:42 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <20161003134507.GA9911@localhost>
Hello,
On Monday, October 3, 2016 9:45:07 AM CEST Bob Copeland wrote:
> Per the subject, Linus released 4.8 yesterday so, unless I broke something
> in recent conflict resolutions, wireless-testing is on pause until the
> merge window closes in two weeks. Have a happy (Canadian) thanksgiving!
>
> https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
Thanks for the timely update.
I have a request: can you please pull Linus' kernel tags?
Currently the last tag from Linus' is v4.4-rc4 [0] and
everything between v4.4-rc5 and v4.8 is missing?!
Regards,
Christian
[0] <https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git/refs/tags>
^ permalink raw reply
* Final 4.8 w-t build is wt-2016-10-03
From: Bob Copeland @ 2016-10-03 13:45 UTC (permalink / raw)
To: linux-wireless
Per the subject, Linus released 4.8 yesterday so, unless I broke something
in recent conflict resolutions, wireless-testing is on pause until the
merge window closes in two weeks. Have a happy (Canadian) thanksgiving!
https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Kalle Valo @ 2016-10-03 13:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Felix Fietkau, linux-wireless, devicetree
In-Reply-To: <201609301658.35039.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> On Friday 30 September 2016, Felix Fietkau wrote:
>> >> >> >> + device_type = "pci";
>> >> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> >> >> >> + mediatek,2ghz = <0>;
>> >> >
>> >> > It's not clear what the possible values for the 2ghz property are,
>> >> > can you be more verbose in the description? How is <0> different
>> >> > from no property?
>> >> 0 means disabled, no property means unchanged (compared to EEPROM).
>> >
>> > Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
>> >
>> > If zero is the only possible value, there is no need to put a number in there.
>> 1 is also possible, which will force-enable the capability.
>
> Ok, then both those values should be documented in the binding.
Related to this, Martin sent patches which add generic bindings for
enabling 2 Ghz and 5 Ghz bands.
[RFC,1/3] Documentation: dt-bindings: add IEEE 802.11 binding documentation
https://patchwork.kernel.org/patch/9359833/
[RFC,2/3] of: add IEEE 802.11 device configuration support code
https://patchwork.kernel.org/patch/9359837/
--
Kalle Valo
^ permalink raw reply
* Re: [v2] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-10-03 13:04 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <1475027104-17423-1-git-send-email-rajatja@google.com>
Rajat Jain <rajatja@google.com> wrote:
> Enable notifying wakeup source to the PM core in case of
> a wake on wireless LAN event.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
The commit log doesn't give any background info. Does this fix a bug or
why is it needed?
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9353051/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix big-endian problem reporting mactime
From: Jes Sorensen @ 2016-10-03 12:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <87shsdsxj9.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Jes.Sorensen@redhat.com writes:
>
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> The full RX descriptor is converted so converting tsfl again would
>> return it to it's original endian value.
>>
>> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> I'll add:
>
> Cc: stable@vger.kernel.org # 4.8+
Appreciate it!
Jes
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Jes Sorensen @ 2016-10-03 12:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <87wphpsxky.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Jes.Sorensen@redhat.com writes:
>
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> A device running without RX package aggregation could return more data
>> in the USB packet than the actual network packet. In this case the
>> could would clone the skb but then determine that that there was no
>> packet to handle and exit without freeing the cloned skb first.
>
> s/case the/case we/? I can edit that before applying the patch.
Sounds good - thanks!
Jes
^ permalink raw reply
* Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Jes Sorensen @ 2016-10-03 12:21 UTC (permalink / raw)
To: Franc[e]sco; +Cc: linux-wireless
In-Reply-To: <ec3a2db3-1e52-e2f1-1a3a-52bdfed3c803@waifu.club>
"Franc[e]sco" <lolisamurai@waifu.club> writes:
> Thanks for the patch, just tested the rtl8xxxu-devel branch and it seems
> to have the same exact issue with the same dmesg output with the
> addition of "rtl8192eu_active_to_emu: Disabling MAC timed out" when I
> disconnect the dongle.
>
> I checked out and compiled the whole kernel from the branch because the
> 4.7.4 sources seemed to be missing the rtl8192eu_active_to_emu function.
There are other patches related to the 8192eu in the wireless tree which
fix some issues with the dongle if you reload the driver. Alternatively
pull my git tree and build that.
Jes
^ permalink raw reply
* Re: [PATCH] mac80211: fix CMD_FRAME for AP_VLAN
From: M. Braun @ 2016-10-03 11:31 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1474786035-15410-1-git-send-email-michael-dev@fami-braun.de>
Am 03.10.2016 um 13:03 schrieb M. Braun:
> because the in ieee80211_mgmt_tx the
ups, that was the patch itself.
I think I carried it over from ieee80211_add_key, that does
>
> if (mac_addr) {
> if (ieee80211_vif_is_mesh(&sdata->vif))
> sta = sta_info_get(sdata, mac_addr);
> else
> sta = sta_info_get_bss(sdata, mac_addr);
>
Regards,
M. Braun
^ permalink raw reply
* [PATCHv3 3/3] mwifiex: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-10-03 11:14 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan, akarwar, nishants
In-Reply-To: <1475493257-21841-1-git-send-email-michael-dev@fami-braun.de>
When using WPA security, the station and thus the required key is
identified by its mac address when packets are received. So a
station usually cannot spoof its source mac address.
But when a station sends an A-MSDU frame, port control and crypto
is done using the outer mac address, while the packets delivered
and forwarded use the inner mac address.
This might affect ARP/IP filtering on the AccessPoint.
IEEE 802.11-2012 mandates that the outer source mac address should
match the inner source address (section 8.3.2.2). For the destination
mac address, matching is not required, as a wifi client may send all
its traffic to the AP in order to have it forwarded.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Cc: projekt-wlan@fem.tu-ilmenau.de
Cc: akarwar@marvell.com
Cc: nishants@marvell.com
---
drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index 49d0efe..f4469d7 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -30,7 +30,8 @@
* layer.
*/
static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
- struct sk_buff *skb)
+ struct sk_buff *skb,
+ const u8 *ta)
{
struct rxpd *local_rx_pd = (struct rxpd *)(skb->data);
int ret;
@@ -45,7 +46,7 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
skb_trim(skb, le16_to_cpu(local_rx_pd->rx_pkt_length));
ieee80211_amsdu_to_8023s(skb, &list, priv->curr_addr,
- priv->wdev.iftype, 0, NULL);
+ priv->wdev.iftype, 0, ta);
while (!skb_queue_empty(&list)) {
struct rx_packet_hdr *rx_hdr;
@@ -76,9 +77,10 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
/* This function will process the rx packet and forward it to kernel/upper
* layer.
*/
-static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
+static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload,
+ const u8 *ta)
{
- int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
+ int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload, ta);
if (!ret)
return 0;
@@ -119,7 +121,7 @@ mwifiex_11n_dispatch_pkt_until_start_win(struct mwifiex_private *priv,
}
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
if (rx_tmp_ptr)
- mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+ mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr, tbl->ta);
}
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
@@ -161,7 +163,7 @@ mwifiex_11n_scan_and_dispatch(struct mwifiex_private *priv,
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
- mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+ mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr, tbl->ta);
}
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
@@ -568,12 +570,12 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
if (!tbl) {
if (pkt_type != PKT_TYPE_BAR)
- mwifiex_11n_dispatch_pkt(priv, payload);
+ mwifiex_11n_dispatch_pkt(priv, payload, ta);
return ret;
}
if ((pkt_type == PKT_TYPE_AMSDU) && !tbl->amsdu) {
- mwifiex_11n_dispatch_pkt(priv, payload);
+ mwifiex_11n_dispatch_pkt(priv, payload, ta);
return ret;
}
--
2.1.4
^ permalink raw reply related
* [PATCHv3 2/3] mac80211: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-10-03 11:14 UTC (permalink / raw)
To: johannes
Cc: Michael Braun, linux-wireless, projekt-wlan, kvalo, akarwar,
nishants, Larry.Finger, Jes.Sorensen
In-Reply-To: <1475493257-21841-1-git-send-email-michael-dev@fami-braun.de>
When using WPA security, the station and thus the required key is
identified by its mac address when packets are received. So a
station usually cannot spoof its source mac address.
But when a station sends an A-MSDU frame, port control and crypto
is done using the outer mac address, while the packets delivered
and forwarded use the inner mac address.
This might affect ARP/IP filtering on the AccessPoint.
IEEE 802.11-2012 mandates that the outer source mac address should
match the inner source address (section 8.3.2.2). For the destination
mac address, matching is not required, as a wifi client may send all
its traffic to the AP in order to have it forwarded.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Cc: projekt-wlan@fem.tu-ilmenau.de
Cc: kvalo@codeaurora.org
Cc: akarwar@marvell.com
Cc: nishants@marvell.com
Cc: Larry.Finger@lwfinger.net
Cc: Jes.Sorensen@redhat.com
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 3 ++-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 2 +-
drivers/staging/rtl8723au/core/rtw_recv.c | 2 +-
include/net/cfg80211.h | 9 ++++----
net/mac80211/rx.c | 11 +++++++--
net/wireless/util.c | 26 ++++++++--------------
6 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 4fdc3da..05dcaef 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -1436,7 +1436,8 @@ static void iwl_mvm_report_wakeup_reasons(struct iwl_mvm *mvm,
memcpy(skb_put(pkt, pktsize), pktdata, pktsize);
- if (ieee80211_data_to_8023(pkt, vif->addr, vif->type))
+ if (ieee80211_data_to_8023(pkt, NULL, vif->addr,
+ vif->type))
goto report;
wakeup.packet = pkt->data;
wakeup.packet_present_len = pkt->len;
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index a74cc43..49d0efe 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -45,7 +45,7 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
skb_trim(skb, le16_to_cpu(local_rx_pd->rx_pkt_length));
ieee80211_amsdu_to_8023s(skb, &list, priv->curr_addr,
- priv->wdev.iftype, 0, false);
+ priv->wdev.iftype, 0, NULL);
while (!skb_queue_empty(&list)) {
struct rx_packet_hdr *rx_hdr;
diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c b/drivers/staging/rtl8723au/core/rtw_recv.c
index 150dabc..caa0e7c 100644
--- a/drivers/staging/rtl8723au/core/rtw_recv.c
+++ b/drivers/staging/rtl8723au/core/rtw_recv.c
@@ -1687,7 +1687,7 @@ int amsdu_to_msdu(struct rtw_adapter *padapter, struct recv_frame *prframe)
skb_pull(skb, prframe->attrib.hdrlen);
__skb_queue_head_init(&skb_list);
- ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, false);
+ ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, NULL);
while (!skb_queue_empty(&skb_list)) {
sub_skb = __skb_dequeue(&skb_list);
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index beb7610..d768fcd 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3905,12 +3905,13 @@ unsigned int ieee80211_get_mesh_hdrlen(struct ieee80211s_hdr *meshhdr);
/**
* ieee80211_data_to_8023 - convert an 802.11 data frame to 802.3
* @skb: the 802.11 data frame
+ * @ehdr: (out) buffer for source/destination address (optional)
* @addr: the device MAC address
* @iftype: the virtual interface type
* Return: 0 on success. Non-zero on error.
*/
-int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
- enum nl80211_iftype iftype);
+int ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
+ const u8 *addr, enum nl80211_iftype iftype);
/**
* ieee80211_data_from_8023 - convert an 802.3 frame to 802.11
@@ -3938,12 +3939,12 @@ int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
* @addr: The device MAC address.
* @iftype: The device interface type.
* @extra_headroom: The hardware extra headroom for SKBs in the @list.
- * @has_80211_header: Set it true if SKB is with IEEE 802.11 header.
+ * @ta: transmitter address (or NULL)
*/
void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
const u8 *addr, enum nl80211_iftype iftype,
const unsigned int extra_headroom,
- bool has_80211_header);
+ const u8 *ta);
/**
* cfg80211_classify8021d - determine the 802.1p/1d tag for a data frame
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9dce3b1..fbf99b8 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2090,7 +2090,8 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx, bool *port_control)
sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta)
return -1;
- ret = ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
+ ret = ieee80211_data_to_8023(rx->skb, NULL, sdata->vif.addr,
+ sdata->vif.type);
if (ret < 0)
return ret;
@@ -2243,6 +2244,7 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
__le16 fc = hdr->frame_control;
struct sk_buff_head frame_list;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
+ struct ethhdr eth_80211;
if (unlikely(!ieee80211_is_data(fc)))
return RX_CONTINUE;
@@ -2268,9 +2270,14 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
skb->dev = dev;
__skb_queue_head_init(&frame_list);
+ if (ieee80211_data_to_8023(skb, ð_80211, dev->dev_addr,
+ rx->sdata->vif.type) < 0)
+ return RX_DROP_UNUSABLE;
+
ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,
rx->sdata->vif.type,
- rx->local->hw.extra_tx_headroom, true);
+ rx->local->hw.extra_tx_headroom,
+ eth_80211.h_source);
while (!skb_queue_empty(&frame_list)) {
rx->skb = __skb_dequeue(&frame_list);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index b7d1592..efa4f5f 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -414,8 +414,8 @@ unsigned int ieee80211_get_mesh_hdrlen(struct ieee80211s_hdr *meshhdr)
}
EXPORT_SYMBOL(ieee80211_get_mesh_hdrlen);
-static int __ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
- const u8 *addr, enum nl80211_iftype iftype)
+int ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
+ const u8 *addr, enum nl80211_iftype iftype)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct {
@@ -519,12 +519,6 @@ static int __ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
return 0;
}
-
-int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
- enum nl80211_iftype iftype)
-{
- return __ieee80211_data_to_8023(skb, NULL, addr, iftype);
-}
EXPORT_SYMBOL(ieee80211_data_to_8023);
int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
@@ -740,24 +734,18 @@ __ieee80211_amsdu_copy(struct sk_buff *skb, unsigned int hlen,
void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
const u8 *addr, enum nl80211_iftype iftype,
const unsigned int extra_headroom,
- bool has_80211_header)
+ const u8 *ta)
{
unsigned int hlen = ALIGN(extra_headroom, 4);
struct sk_buff *frame = NULL;
u16 ethertype;
u8 *payload;
- int offset = 0, remaining, err;
+ int offset = 0, remaining;
struct ethhdr eth;
bool reuse_frag = skb->head_frag && !skb_has_frag_list(skb);
bool reuse_skb = false;
bool last = false;
- if (has_80211_header) {
- err = __ieee80211_data_to_8023(skb, ð, addr, iftype);
- if (err)
- goto out;
- }
-
while (!last) {
unsigned int subframe_len;
int len;
@@ -768,6 +756,11 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
subframe_len = sizeof(struct ethhdr) + len;
padding = (4 - subframe_len) & 0x3;
+ if (unlikely(ta && !ether_addr_equal(ta, eth.h_source) &&
+ (iftype == NL80211_IFTYPE_AP ||
+ iftype == NL80211_IFTYPE_AP_VLAN)))
+ goto purge;
+
/* the last MSDU has no padding */
remaining = skb->len - offset;
if (subframe_len > remaining)
@@ -813,7 +806,6 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
purge:
__skb_queue_purge(list);
- out:
dev_kfree_skb(skb);
}
EXPORT_SYMBOL(ieee80211_amsdu_to_8023s);
--
2.1.4
^ permalink raw reply related
* [PATCHv2 1/3] mac80211: fix CMD_FRAME for AP_VLAN
From: Michael Braun @ 2016-10-03 11:14 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
When using IEEE 802.11r FT OVER-DS roaming with AP_VLAN, hostapd needs to
send out a frame using CMD_FRAME for a station assigned to an AP_VLAN
interface.
Right now, the userspace needs to give the exact AP_VLAN interface index
for CMD_FRAME; hostapd does not do this. Additionally, userspace cannot
use GET_STATION to query the AP_VLAN ifidx, as while GET_STATION finds
stations assigned to AP_VLAN even if the AP iface is queried, it does not
return AP_VLAN ifidx (it returns the queried one).
This breaks IEEE 802.11r over_ds with vlans, as the reply frame does not
get out. This patch fixes this by using get_sta_bss for CMD_FRAME.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Cc: projekt-wlan@fem.tu-ilmenau.de
---
net/mac80211/offchannel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index 55a9c5b..688744c 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -819,7 +819,7 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
mgmt->u.action.category == WLAN_CATEGORY_SPECTRUM_MGMT)
break;
rcu_read_lock();
- sta = sta_info_get(sdata, mgmt->da);
+ sta = sta_info_get_bss(sdata, mgmt->da);
rcu_read_unlock();
if (!sta)
return -ENOLINK;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] mac80211: fix CMD_FRAME for AP_VLAN
From: M. Braun @ 2016-10-03 11:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1475235707.17481.44.camel@sipsolutions.net>
Am 30.09.2016 um 13:41 schrieb Johannes Berg:
>> - sta = sta_info_get(sdata, mgmt->da);
>> + if (ieee80211_vif_is_mesh(&sdata->vif))
>> + sta = sta_info_get(sdata, mgmt->da);
>> + else
>> + sta = sta_info_get_bss(sdata, mgmt->da);
>>
> I don't see why you need to distinguish between mesh and non-mesh
> here?
> get_bss() will ignore the BSS pointer if it's NULL, and that will
> always be the case when the type is mesh, so ... why?
because the in ieee80211_mgmt_tx the
> case NL80211_IFTYPE_AP:
> case NL80211_IFTYPE_AP_VLAN:
> case NL80211_IFTYPE_P2P_GO:
> ...
> rcu_read_lock();
> if (ieee80211_vif_is_mesh(&sdata->vif))
> sta = sta_info_get(sdata, mgmt->da);
> else
> sta = sta_info_get_bss(sdata, mgmt->da);
> rcu_read_unlock();
>
does it the same way and I wanted to go safe and not change the mesh path.
michael
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-10-03 10:44 UTC (permalink / raw)
To: Johannes Berg
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <1475229714.17481.18.camel@sipsolutions.net>
Am 30.09.2016 um 12:01 schrieb Johannes Berg:
> A few more things:
>
> First of all - there's nothing specific to "AP interfaces", which you
> say in the subject, as far as I can tell? That should be removed?
>> if (unlikely(ta &&
>>+ (iftype == NL80211_IFTYPE_AP ||
>>+ iftype == NL80211_IFTYPE_AP_VLAN) &&
>>+ !ether_addr_equal(ta, eth.h_source)
>>+ ))
>>+ goto purge;
So the A-MSDU packets are only dropped if received by an interface in AP
or AP_VLAN mode, not on client side, as my original issue was about
arp/ip filters being circumvented on AP side.
>> IEEE 802.11-2012 mandates that the outer source mac address should
>> match the inner source address (section 8.3.2.2). For the
>> destination mac address, matching is not required (section 10.23.15).
>
> I think this is wrong. As we do not support DMS (yet), we should adhere
> to 8.3.2.2 and only accept matching TA/SA and DA/RA.
IEEE 802.11-2012 8.3.2.2 contains the note "NOTE—It is possible to have
different DA and SA parameter values in A-MSDU subframe headers of the
same A-MSDU as long as they all map to the same Address 1 and Address 2
parameter values."
I conclude that embedding multicast in unicast A-MSDU frames is
generally allowed, because "mapping" does not mean "be identical".
Regards,
M. Braun
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-09-30
From: Johannes Berg @ 2016-10-03 10:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <20161003.015401.1915647209236695770.davem@davemloft.net>
On Mon, 2016-10-03 at 01:54 -0400, David Miller wrote:
>
> Could you please look into this and send me a new pull request with
> the conflicts resolved?
>
Sure, will do (tomorrow, we have a holiday today).
Would you prefer I send you the merge resolution for your tree, or just
pull in net for a new pull request?
johannes
^ permalink raw reply
* [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Vittorio Gambaletta (VittGam) @ 2016-10-03 10:00 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
If generic entries are positioned above specific ones, then the
former will be matched first and used instead of the latter.
Cc: <linux-wireless@vger.kernel.org>
Cc: <ath9k-devel@qca.qualcomm.com>
Cc: <ath9k-devel@lists.ath9k.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
---
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -26,7 +26,6 @@
{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
- { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
#ifdef CONFIG_ATH9K_PCOEM
/* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
@@ -37,7 +36,7 @@
.driver_data = ATH9K_PCI_LED_ACT_HI },
#endif
- { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+ { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
#ifdef CONFIG_ATH9K_PCOEM
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
@@ -85,7 +84,11 @@
0x10CF, /* Fujitsu */
0x1536),
.driver_data = ATH9K_PCI_D3_L1_WAR },
+#endif
+ { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+
+#ifdef CONFIG_ATH9K_PCOEM
/* AR9285 card for Asus */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
0x002B,
^ permalink raw reply
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