Re: ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
On Wed, Feb 17, 2016 at 1:23 AM, Krishna Chaitanya wrote: > From a quick glance of symptoms, i think the below patch is worth a > try, even though > i don't see you are doing any background scans for which this applies. > > https://patchwork.kernel.org/patch/8015321/ Thanks, Krishna. We are in fact doing background scans occasionally, however, none was in progress around the time of the glitch, and the problem was still reproducible with background scans disabled. We also aren't combining AP and STA on the same radio (in this particular use case). -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
On Wed, Feb 17, 2016 at 10:02 AM, Avery Pennarun wrote: > > On Tue, Feb 16, 2016 at 5:05 PM, Johannes Berg > wrote: > > On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote: > >> Changing default_agg_timeout to zero (as it is on most non-ath9k > >> drivers) makes the problem pretty much go away. However, I think > >> it's because I'm just dodging the code path that triggers a race > >> condition. > > > > That does seem likely. Perhaps you could reproduce it while running > > mac80211 tracing? There should be a fair amount of information about > > aggregation and queue stops in there, though as you note queue stops > > aren't really happening, only aggregation related things. Perhaps the > > tracepoints for that aren't quite sufficient. > > So far that hasn't seemed to help, although maybe you can read traces > better than I can. The big problem is that the actual queue doesn't > seem to have stopped; it might be an ath9k bug. > > >> Notes: > >> > >> - I'm using exactly the same ath9k driver (currently 20150525, but > >> we've tried newer ones with no difference) on two totally different > >> platforms: a dual-core mindspeed c2k host CPU (ARMv7) with separate > >> ath9k, and a single-core QCA9531 (MIPS) with on-chip ath9k. > >> > >> - I've been unable to trigger the problem on the QCA9531, but I have > >> on MIPS. > > > > That's ... not what I would have expected, especially since the MIPS is > > single core. That makes the races stranger than expected. > > Oops, typo. The QCA9531 *is* MIPS. The one where it triggers is the > dual-core ARM. > > >> The aggregation code is... a little hairy. Does anyone have any > >> guesses where I might look for the race condition? Or better still, > >> a patch I can try? > > > > I'm not aware of any race conditions in the code right now :) > > Aw. That would have made it a lot easier! >From a quick glance of symptoms, i think the below patch is worth a try, even though i don't see you are doing any background scans for which this applies. https://patchwork.kernel.org/patch/8015321/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wlcore: Fix regression in wlcore_set_partition()
Appreciate your efforts!
Just trying to make sure it does not get lost.
Introduced in rc1, not fixed by ... rc4.
Anyway, I will continue to test, lots of other things still to chase
even in rc4!
Regards,
Ross Green
On Wed, Feb 17, 2016 at 2:24 AM, Kalle Valo wrote:
> Ross Green writes:
>
>> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote:
>>>
The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a
regression causing the wlcore to time out and go into recovery. Reverting
the
changes regarding write of the last partition size brings the module back
to
it's functional state.
Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
Reported-by: Ross Green
Signed-off-by: Emil Goode
[kv...@codeaurora.org: improved commit log]
>>>
>>> Thanks, applied to wireless-drivers.git.
>>>
>>> Kalle Valo
>>
>> I just tested linux-4.5-rc4 it appears the above fix missed the release for
>> rc4!
>> So the behaviour of firmware reset being called after the access of
>> the last partition timesout.
>>
>> Again tested patch with the new release - 4.5-rc4 and found everything
>> to work as expected again.
>>
>> So Hopefully for rc5 - Please!
>
> It takes some time to get patches into Linus' tree. And being in a
> conference and then getting sick is not really helping. I'm not sure if
> this patch makes to rc5 on time, but I'll try.
>
> --
> Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
On Tue, Feb 16, 2016 at 5:05 PM, Johannes Berg wrote: > On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote: >> Changing default_agg_timeout to zero (as it is on most non-ath9k >> drivers) makes the problem pretty much go away. However, I think >> it's because I'm just dodging the code path that triggers a race >> condition. > > That does seem likely. Perhaps you could reproduce it while running > mac80211 tracing? There should be a fair amount of information about > aggregation and queue stops in there, though as you note queue stops > aren't really happening, only aggregation related things. Perhaps the > tracepoints for that aren't quite sufficient. So far that hasn't seemed to help, although maybe you can read traces better than I can. The big problem is that the actual queue doesn't seem to have stopped; it might be an ath9k bug. >> Notes: >> >> - I'm using exactly the same ath9k driver (currently 20150525, but >> we've tried newer ones with no difference) on two totally different >> platforms: a dual-core mindspeed c2k host CPU (ARMv7) with separate >> ath9k, and a single-core QCA9531 (MIPS) with on-chip ath9k. >> >> - I've been unable to trigger the problem on the QCA9531, but I have >> on MIPS. > > That's ... not what I would have expected, especially since the MIPS is > single core. That makes the races stranger than expected. Oops, typo. The QCA9531 *is* MIPS. The one where it triggers is the dual-core ARM. >> The aggregation code is... a little hairy. Does anyone have any >> guesses where I might look for the race condition? Or better still, >> a patch I can try? > > I'm not aware of any race conditions in the code right now :) Aw. That would have made it a lot easier! -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
wpa_supplicant bridging problems
Hello everyone
I am having a very difficult time with a wireless bridging problem.
My objective is to use a Debian GNU/Linux host as a wireless ethernet
bridge between itself, some hosts connected through a switch on it's
eth0 port, and an OpenWRT router.
I have a test setup consisting of a laptop, a small PC (802.11 client),
and the OpenWRT AP/router.
The wifi client system is an amd64(intel) with one 802.11 interface and
a 1000BASE-T interface. The 802.11 hardware here is an Intel 3160. The
OS is Debian GNU/Linux unstable with kernel 4.3.0-1-amd64 and
wpasupplicant package version 2.3-2.3.
The 802.11 AP is a TP-Link TL-WR710N which is based off the Atheros ar9331.
My problem is the moment I bridge the wlan0 interface on the 802.11 PC
client, wpa_supplicant stops doing it's job. It stops responding to any
EAPOL frames from the AP, even though it seems to be receiving them.
It is noteworthy that the bridging works. I am able to get a DHCP lease
on the laptop from the OpenWRT AP/router via bridging though the PC.
Traffic passes both way and everything works great until the next WPA
rekey event comes along (every 10 minutes by default for OpenWRT), and
then the client gets deauth'ed from the AP because it fails to respond.
The only way I can get this to work is to first bring up my wlan0
interface on the PC so that wpa_supplicant authenticates itself
correctly. Once the 802.11 layer 2 is up, I manually use brctl to bridge
in the eth0 and wlan0 ports on the PC. Everything works fine until the
AP wants to rekey or the client needs to re-auth for some reason.
Here is what my setup looks like:
The OpenWRT device setup is pretty standard. The only thing required for
the bridging is the addition of the "option wds 1" parameter under the
wifi-iface in the "wireless" config file. The wds parameter enables
4-address frames to allow the bridging. In case it's relevant, I'm doing
WPA2 PSK AES/CCMP.
My PC/client /etc/network/interfaces file looks kind of like this:
allow-hotplug eth0
iface eth0 inet manual
auto wlan0
iface wlan0 inet manual
wpa-debug-level 2
wpa-ssid POTATONET
wpa-psk X
pre-up iw dev wlan0 set 4addr on
pre-up iw dev wlan0 set power_save off
allow-auto br0
# iface br0 inet dhcp
iface br0 inet manual
# bridge_ports wlan0
bridge_ports none
bridge_stp off
bridge_waitport 0
bridge_fd 0
# wpa-iface wlan0
# wpa-bridge br0
I bring up wlan0 and br0:
sudo ifup wlan0
sudo ifup br0
At this point, the wlan0 port should be associated to the AP, even
though I don't have any layer 3 interfaces on the PC yet. If I force a
re-authentication from the AP it works fine. WPA rekey works fine.
I do this to bridge up the interfaces:
sudo brctl addif br0 eth0
sudo brctl addif br0 wlan0
From this point on, wpa_supplicant stops working correctly. However,
the bridge works and ethernet frames are being passed between the laptop
off of PC port eth0 and the OpenWRT AP. Everything is fine until the WPA
rekey happens and then the wlan0 interface goes down and stops working.
I did a tcpdump to find out what was going on and discovered that once
the AP asked for re-authentication from the client, no traffic was going
out of the wlan0 interface on the client PC. This was supported by
ifconfig TX counters. wpa_supplicant stops replying to the AP on the
wlan0 interface.
It should be noted at this point that I am aware wpa_supplicant is
supposed to need the "-b" argument in this kind of setup, which is what
the commented-out "wpa-bridge" parameter in the "interfaces" file above
is for, but it didn't work. I verified the arguments given to
wpa_supplicant were correct via ps:
/sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -b
br0 -D nl80211,wext -C /run/wpa_supplicant
Additional notes and observations:
Just to be clear, I have inspected the macaddr and arp tables on both
the OpenWRT AP and the laptop and the MACs are correct. The wireless
bridging is definitely working as expected. Let me know if you want
output from these commands, but I don't think they are relevant.
The default WPA rekey timer is every 10 minutes on OpenWRT, but I can
force the AP to re-authenticate the client by doing this:
ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz",
"reason":1, "deauth":true, "ban_time":0}'
Finally, here is some debugging output (wpa_supplicant -ddd) from the
client PC during a failed re-auth with the AP.
http://jmomo.net/files/wpa_probs.txt
What do?
If additional debugging is needed, let me know what to do. If this is a
Debian package problem, let me know and I'll go open a bug there.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: debugfs var for the default aggregation timeout.
Avery Pennarun wrote: > Since around the beginning of time, ath9k aggregates have timed out after > 5000 TU (around 5000ms) of inactivity, but nobody seems to be quite sure > why, and this magic number seems to have migrated around from one place to > another. An openbsd mailing list recently had a patch to disable the > timeout completely, which they say matches some commercial routers: > https://www.mail-archive.com/tech@openbsd.org/msg29456.html We actually did this for ath9k: https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git/commit/?id=bd2ce6e43f65127bc723e7fcc044758cf8113260 Almost all APs set the timeout to zero, only mac80211 differs and uses 5000 TUs. I guess ath9k lost this fix when the old RC was removed and switched to minstrel. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull-request: wireless-drivers-next 2016-02-12
From: Kalle Valo Date: Fri, 12 Feb 2016 16:40:23 +0200 > here's first pull request for 4.6. We have a new kconfig option > CONFIG_IWLWIFI_PCIE_RTPM for iwlwifi runtime power management. wl12xxx > got device tree support for the spi bus and added a bindings document > for it. More info in the tag below. > > Please let me know if you have any problems. Pulled, thanks Kalle. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/staging/wilc1000/wilc_spi.c won't compile ?
Hi David, Please check the latest update from the https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/?h=staging-testing. The tree is not updated yet with the latest. Thanks, Tony. On 2016년 02월 16일 20:33, David Binderman wrote: Hello there, You're had old wilc1000 source. Remove the wilc1000_ops structure. (Branch) staging-testing (SHA) ce7b516f3f9e11fe4ee06fad0d7e853bb6e8f160 Please receive the latest source. I checked the Torvalds source for 4.5-rc4 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/wilc1000/wilc_spi.c?id=refs/tags/v4.5-rc4 and the problem still seems to exist. Maybe your recent changes aren't getting from staging into the Torvalds tree ? Regards David Binderman Thanks, BR Leo -Original Message- From: David Binderman [mailto:dcb...@hotmail.com] Sent: Monday, February 08, 2016 9:18 PM To: Kim, Johnny ; Shin, Austin ; Park, Chris ; Cho, Tony ; Lee, Glen ; Kim, Leo ; linux-wireless@vger.kernel.org Subject: drivers/staging/wilc1000/wilc_spi.c won't compile ? Hello there, drivers/staging/wilc1000/wilc_spi.c:123:34: error: storage size of 'wilc1000_spi_ops' isn't known static const struct wilc1000_ops wilc1000_spi_ops; ^~~~ drivers/staging/wilc1000/wilc_spi.c:123:34: warning: 'wilc1000_spi_ops' defined but not used [-Wunused-const-variable] Suggest remove. Regards David Binderman -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rt2x00: unterminated strlen of user data
Hi All,
On Tue, Feb 16, 2016 at 6:04 AM, Alan wrote:
> The buffer needs to be zero terminated in case the user data is not.
> Otherwise we run off the end of the buffer.
>
> Signed-off-by: Alan Cox
This looks right to me.
Reviewed-by: Julian Calaby
> ---
> drivers/net/wireless/ralink/rt2x00/rt2x00debug.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
> b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
> index 25ee3cb..72ae530 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
> @@ -478,7 +478,7 @@ static ssize_t rt2x00debug_write_##__name(struct file
> *file,\
> { \
> struct rt2x00debug_intf *intf = file->private_data; \
> const struct rt2x00debug *debug = intf->debug; \
> - char line[16]; \
> + char line[17]; \
> size_t size;\
> unsigned int index = intf->offset_##__name; \
> __type value; \
> @@ -494,7 +494,8 @@ static ssize_t rt2x00debug_write_##__name(struct file
> *file,\
> \
> if (copy_from_user(line, buf, length)) \
> return -EFAULT; \
> - \
> + line[16] = 0; \
> + \
> size = strlen(line);\
> value = simple_strtoul(line, NULL, 0); \
> \
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rt2x00: unterminated strlen of user data
Hi Souptick,
On Tue, Feb 16, 2016 at 5:36 PM, Souptick Joarder wrote:
> On Tue, Feb 16, 2016 at 12:34 AM, Alan wrote:
>> The buffer needs to be zero terminated in case the user data is not.
>> Otherwise we run off the end of the buffer.
>>
>> Signed-off-by: Alan Cox
>> ---
>> drivers/net/wireless/ralink/rt2x00/rt2x00debug.c |5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
>> b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
>> index 25ee3cb..72ae530 100644
>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
>> @@ -478,7 +478,7 @@ static ssize_t rt2x00debug_write_##__name(struct file
>> *file,\
>> { \
>> struct rt2x00debug_intf *intf = file->private_data; \
>> const struct rt2x00debug *debug = intf->debug; \
>> - char line[16]; \
>> + char line[17]; \
>> size_t size;\
>> unsigned int index = intf->offset_##__name; \
>> __type value; \
>> @@ -494,7 +494,8 @@ static ssize_t rt2x00debug_write_##__name(struct file
>> *file,\
>> \
>> if (copy_from_user(line, buf, length)) \
>> return -EFAULT; \
>> - \
>> + line[16] = 0;
>
> line[length] = '\0';
> correct me if I am wrong. \
I believe that in this case the data in buf will already be null
terminated, so ensuring that line is null terminated is only needed if
there are exactly 16 bytes in buf. IMHO
line[16] = 0;
is dealing with this bug much more explicitly than
line[length] = 0;
however either will work. (BTW '\0' is identical to 0.)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote: > > Changing default_agg_timeout to zero (as it is on most non-ath9k > drivers) makes the problem pretty much go away. However, I think > it's because I'm just dodging the code path that triggers a race > condition. That does seem likely. Perhaps you could reproduce it while running mac80211 tracing? There should be a fair amount of information about aggregation and queue stops in there, though as you note queue stops aren't really happening, only aggregation related things. Perhaps the tracepoints for that aren't quite sufficient. > Notes: > > - I'm using exactly the same ath9k driver (currently 20150525, but > we've tried newer ones with no difference) on two totally different > platforms: a dual-core mindspeed c2k host CPU (ARMv7) with separate > ath9k, and a single-core QCA9531 (MIPS) with on-chip ath9k. > > - I've been unable to trigger the problem on the QCA9531, but I have > on MIPS. That's ... not what I would have expected, especially since the MIPS is single core. That makes the races stranger than expected. > The aggregation code is... a little hairy. Does anyone have any > guesses where I might look for the race condition? Or better still, > a patch I can try? I'm not aware of any race conditions in the code right now :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: debugfs var for the default aggregation timeout.
On Tue, 2016-02-16 at 16:28 -0500, Avery Pennarun wrote: > Since around the beginning of time, ath9k aggregates have timed out > after > 5000 TU (around 5000ms) of inactivity, but nobody seems to be quite > sure > why, and this magic number seems to have migrated around from one > place to > another. An openbsd mailing list recently had a patch to disable the > timeout completely, which they say matches some commercial routers: > https://www.mail-archive.com/tech@openbsd.org/msg29456.html > > Even in Linux, several non-ath9k drivers default to no timeout > already. I > think changing it directly to zero would be safe, but to allow a more > structured investigation, let's make it configurable for now. I believe the original timeout came from some ancient Intel code. Nobody gave it any thought at the time, and it was merged and preserved to this day. The reason for Intel specifically is that every aggregation session (both RX and TX), even idle ones, takes up hardware resources, so there's a limited need to drop completely idle sessions. As a result, I believe that changing the default for every driver other than iwlegacy, iwlwifi/dvm and iwlwifi/mvm would be perfectly fine. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: debugfs var for the default aggregation timeout.
Since around the beginning of time, ath9k aggregates have timed out after
5000 TU (around 5000ms) of inactivity, but nobody seems to be quite sure
why, and this magic number seems to have migrated around from one place to
another. An openbsd mailing list recently had a patch to disable the
timeout completely, which they say matches some commercial routers:
https://www.mail-archive.com/tech@openbsd.org/msg29456.html
Even in Linux, several non-ath9k drivers default to no timeout already. I
think changing it directly to zero would be safe, but to allow a more
structured investigation, let's make it configurable for now.
Signed-off-by: Avery Pennarun
---
net/mac80211/debugfs_netdev.c | 4
net/mac80211/rc80211_minstrel_ht.c | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 37ea30e..5ae160b 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -715,6 +715,8 @@ static void add_mesh_config(struct ieee80211_sub_if_data
*sdata)
}
#endif
+u32 default_agg_timeout = 5000;
+
static void add_files(struct ieee80211_sub_if_data *sdata)
{
if (!sdata->vif.debugfs_dir)
@@ -725,6 +727,8 @@ static void add_files(struct ieee80211_sub_if_data *sdata)
DEBUGFS_ADD(txpower);
DEBUGFS_ADD(user_power_level);
DEBUGFS_ADD(ap_power_level);
+ debugfs_create_u32("default_agg_timeout", 0600, sdata->vif.debugfs_dir,
+ &default_agg_timeout);
if (sdata->vif.type != NL80211_IFTYPE_MONITOR)
add_common_files(sdata);
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 3928dbd..028d9d4 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -671,6 +671,8 @@ minstrel_downgrade_rate(struct minstrel_ht_sta *mi, u16
*idx, bool primary)
}
}
+extern u32 default_agg_timeout;
+
static void
minstrel_aggr_check(struct ieee80211_sta *pubsta, struct sk_buff *skb)
{
@@ -691,7 +693,7 @@ minstrel_aggr_check(struct ieee80211_sta *pubsta, struct
sk_buff *skb)
if (likely(sta->ampdu_mlme.tid_tx[tid]))
return;
- ieee80211_start_tx_ba_session(pubsta, tid, 5000);
+ ieee80211_start_tx_ba_session(pubsta, tid, default_agg_timeout);
}
static void
--
2.7.0.rc3.207.g0ac5344
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
Okay, I've made much more progress on this old thread. I haven't actually fixed the bug, which I suspect is a race condition only on multicore machines, but I at least have better reproduction steps and a workaround. The bug seems to trigger when three things happen at once: 1) Background interference causes retries 2) AP wants to send data to the STA, which has been idle for a while 3) We want to negotiate a new BA session from AP to STA. Sometimes, the background interference will cause the time between ADDBA Request (from AP) and ADDBA Response (from STA) to be longer than usual. In my tests, it's usually <1ms, but in high-interference situations I've seen it be >3ms. Sometimes, when the delay is longer, I see the symptom that the agg_status file for the station in question starts showing TID#0's "pending" column increasing slowly, until it eventually reaches 64. A wifi capture on a separate sniffer indicates that no data is being transmitted to that station, although traffic to other stations (and broadcast/multicast) continues unabated. I guess this means the device's queues are themselves not stopped, but the station's per-TID aggregation queue is stuck. Twiddling the agg_status of a different queue (in this case TID#1) unblocks TID#0: echo "tx start 1" >/sys/kernel/debug/ieee80211/phy0/.../agg_status So does having another aggregation-capable device join the network. Having an 802.11g-only device join the network does *not* unblock the queue. However, trying to stop TID#0 doesn't help (and it also doesn't successfully stop the aggregation): echo "tx stop 0" >/sys/kernel/debug/ieee80211/phy0/.../agg_status The following patch makes the problem easier to reproduce by letting you turn the aggregation timeout way down. For myself, I used a default_agg_timeout of 500ms and just pinged repeatedly once per second from the AP to STA. This causes the aggregation sessions to be repeatedly brought up and torn down, which triggers the problem for me within a few minutes (when run on a channel with fairly high noise). Changing default_agg_timeout to zero (as it is on most non-ath9k drivers) makes the problem pretty much go away. However, I think it's because I'm just dodging the code path that triggers a race condition. Notes: - I'm using exactly the same ath9k driver (currently 20150525, but we've tried newer ones with no difference) on two totally different platforms: a dual-core mindspeed c2k host CPU (ARMv7) with separate ath9k, and a single-core QCA9531 (MIPS) with on-chip ath9k. - I've been unable to trigger the problem on the QCA9531, but I have on MIPS. The aggregation code is... a little hairy. Does anyone have any guesses where I might look for the race condition? Or better still, a patch I can try? Avery Pennarun (1): mac80211: add a debugfs var for the default aggregation timeout. net/mac80211/debugfs_netdev.c | 4 net/mac80211/rc80211_minstrel_ht.c | 4 +++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.7.0.rc3.207.g0ac5344 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: whitespace error in some of commits
On Tue, Feb 16, 2016 at 03:47:00PM +0900, Tony Cho wrote: > Hi Janani, > > I can find the whitespace errors in your commits which is already accepted in > staging-testing branch. Ick, my fault, I should have caught them before they were merged, sorry about that. > The commit number is c611d48e65e25af2dc0176e9ac135116095ed03d and > c611d48e65e25af2dc0176e9ac135116095ed03d. > > I don't know why I couldn't find your patch emails from the community. Please > cc the linux-wireless and devel. That's not how the Outreachy application process works, sorry. > Would you fix these patch or I can make it if you don't mind. They will be fixed later today, sorry about that. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: Change long delays to sleeps
On 02/16/2016 12:17 AM, Souptick Joarder wrote: On Tue, Feb 16, 2016 at 3:42 AM, Larry Finger wrote: --snip-- else if (addr == 0xf9) - udelay(1); + usleep_range(1, 2); why udelay is replaced by usleep_range? I'm not sure of your level of sophistication, but here goes. All delay statements cause a processor to stay in control and make the system wait for that amount of time. A sleep statement allows a context switch, and the processor is able to run some other job. For that reason, sleeps are always preferred over delays as long as the code is not running in atomic context. There used to be a usleep() function, but as the system cannot promise to return from sleep after a specific delay, it was replaced with usleep_range(). It is true that the difference between delaying and sleeping for 1 usec would not be too destructive to the system, but I decided to convert every branch of that if structure to sleep statements. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi-2016-02-16
"Grumbach, Emmanuel" writes: > This is a pull request for 4.5. Apart from my RF-Kill fix, the patches are > really small. My RF-Kill patch needed to move code around to avoid adding > a forward declaration and on the way there were a few very trivial code style > fixes, that were needed to make checkpatch happy. > > Let me know if you have issues, thanks! > > > The following changes since commit 69c7fda40921c125f6a827f6270ac6aa1baa: > > iwlwifi: mvm: rs: fix TPC statistics handling (2016-01-26 16:03:35 +0200) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git > tags/iwlwifi-for-kalle-2016-02-15 Pulled, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wlcore: Fix regression in wlcore_set_partition()
Ross Green writes:
> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote:
>>
>>> The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a
>>> regression causing the wlcore to time out and go into recovery. Reverting
>>> the
>>> changes regarding write of the last partition size brings the module back to
>>> it's functional state.
>>>
>>> Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
>>> Reported-by: Ross Green
>>> Signed-off-by: Emil Goode
>>> [kv...@codeaurora.org: improved commit log]
>>
>> Thanks, applied to wireless-drivers.git.
>>
>> Kalle Valo
>
> I just tested linux-4.5-rc4 it appears the above fix missed the release for
> rc4!
> So the behaviour of firmware reset being called after the access of
> the last partition timesout.
>
> Again tested patch with the new release - 4.5-rc4 and found everything
> to work as expected again.
>
> So Hopefully for rc5 - Please!
It takes some time to get patches into Linus' tree. And being in a
conference and then getting sick is not really helping. I'm not sure if
this patch makes to rc5 on time, but I'll try.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] rfkill: Userspace control for airplane mode
On 10 February 2016 at 12:12, Johannes Berg wrote: > On 2016-02-10 17:53, Dan Williams wrote: >> >> Yeah, I get that now. It's just that to me, something called >> "AIRPLANE_MODE_CHANGE" seems like it should actually change airplane >> mode on/off, which implies killing radios. I wouldn't have had the >> problem if it was named AIRPLANE_MODE_INDICATOR_CHANGE, which makes it >> clear this is simply an indicator and has no actual effect on anything >> other than a LED. > I also agree the AIRPLANE_MODE_INDICATOR_* prefix makes things more clear here. Thanks for the feedback, Dan! > > Yeah, I agree. I'm not even sure that it's a good idea to subsume this into > the regular operations in the API, although that's obviously the easiest > extension. I'll need to think about that a bit more with the code at hand > though. > Initially I have thought about creating and additional RFKill switch for that, but I think it would be a bit hackish since we would have to treat it specially in sysfs attributes and probably other places, and userspace would also need a special case when going through the list of RFKill switches in the system. The proposed solution has equivalent semantics to an RFKill switch, is backward-compatible (users would only ignore the unknown operations and evens -- although gsd has a "default:" case to abort execution on an unknown event) and does not extend the RFKill event struct. One alternative would be to move the control point to a separate device, like /dev/rfkill-airplane-mode, but I'm not sure this is a very elegant approach. Anyway, I'm open to work on changes to the API, but it would be great if you could at least pick or reject the non-polemical patches of the series, so I don't need to carry them anymore. -- João Paulo Rechi Vita http://about.me/jprvita -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: parse VHT info in injected frames
Add VHT radiotap parsing support to ieee80211_parse_tx_radiotap().
That capability has been tested using a d-link dir-860l rev b1 running
OpenWrt trunk and mt76 driver
Signed-off-by: Lorenzo Bianconi
---
Documentation/networking/mac80211-injection.txt | 10
net/mac80211/tx.c | 31 +
2 files changed, 41 insertions(+)
diff --git a/Documentation/networking/mac80211-injection.txt
b/Documentation/networking/mac80211-injection.txt
index ec8f934..ef57cc0 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt
@@ -45,6 +45,16 @@ radiotap headers and used to control injection:
number of retries when either IEEE80211_RADIOTAP_RATE or
IEEE80211_RADIOTAP_MCS was used
+ * IEEE80211_RADIOTAP_VHT
+
+ VHT rate for the transmission (only for devices without own rate control).
+ Also some flags are parsed
+
+ IEEE80211_TX_RC_SHORT_GI: use short guard interval
+ IEEE80211_TX_RC_40_MHZ_WIDTH: send in HT40 mode
+ IEEE80211_TX_RC_80_MHZ_WIDTH: send in HT80 mode
+ IEEE80211_TX_RC_160_MHZ_WIDTH: send in HT160 mode
+
The injection code can also skip all other currently defined radiotap fields
facilitating replay of captured radiotap headers directly.
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 7bb67fa..17db889 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1692,6 +1692,8 @@ static bool ieee80211_parse_tx_radiotap(struct
ieee80211_local *local,
u8 rate_retries = 0;
u16 rate_flags = 0;
u8 mcs_known, mcs_flags;
+ u16 vht_known;
+ u8 vht_mcs = 0, vht_nss = 0;
int i;
info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT |
@@ -1772,6 +1774,32 @@ static bool ieee80211_parse_tx_radiotap(struct
ieee80211_local *local,
rate_flags |= IEEE80211_TX_RC_40_MHZ_WIDTH;
break;
+ case IEEE80211_RADIOTAP_VHT:
+ vht_known = get_unaligned_le16(iterator.this_arg);
+ rate_found = true;
+
+ rate_flags = IEEE80211_TX_RC_VHT_MCS;
+ if ((vht_known & IEEE80211_RADIOTAP_VHT_KNOWN_GI) &&
+ (iterator.this_arg[2] &
+IEEE80211_RADIOTAP_VHT_FLAG_SGI))
+ rate_flags |= IEEE80211_TX_RC_SHORT_GI;
+ if (vht_known &
+ IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH) {
+ if (iterator.this_arg[3] == 1)
+ rate_flags |=
+ IEEE80211_TX_RC_40_MHZ_WIDTH;
+ else if (iterator.this_arg[3] == 4)
+ rate_flags |=
+ IEEE80211_TX_RC_80_MHZ_WIDTH;
+ else if (iterator.this_arg[3] == 11)
+ rate_flags |=
+ IEEE80211_TX_RC_160_MHZ_WIDTH;
+ }
+
+ vht_mcs = iterator.this_arg[4] >> 4;
+ vht_nss = iterator.this_arg[4] & 0xF;
+ break;
+
/*
* Please update the file
* Documentation/networking/mac80211-injection.txt
@@ -1797,6 +1825,9 @@ static bool ieee80211_parse_tx_radiotap(struct
ieee80211_local *local,
if (rate_flags & IEEE80211_TX_RC_MCS) {
info->control.rates[0].idx = rate;
+ } else if (rate_flags & IEEE80211_TX_RC_VHT_MCS) {
+ ieee80211_rate_set_vht(info->control.rates, vht_mcs,
+ vht_nss);
} else {
for (i = 0; i < sband->n_bitrates; i++) {
if (rate * 5 != sband->bitrates[i].bitrate)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mwifiex driver unstable on MS Surface Pro 4
Hi Mikael, > From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] On Behalf Of Mikael Djurfeldt > Sent: Tuesday, February 16, 2016 4:26 AM > To: linux-wireless@vger.kernel.org > Cc: Mikael Djurfeldt > Subject: mwifiex driver unstable on MS Surface Pro 4 > > Dear list, > > I'm experiencing problems with the mwifiex_pcie driver on MS Surface Pro > 4 (with the 88W8897 chip). > > The symtom is that the driver only works for a few minutes during which > various error messages is shown in syslog after which the device becomes > unavailable. > > I've tried a bunch of kernels from 4.3 and upwards. > > I'm attaching an example syslog (filtered for mwifiex) during a run > under the 4.5.0-rc4 kernel. > > I should add that I have power management on the device (as displayed > by, e.g., iwconfig) switched off in an attempt to delimit causes of > failure. > Thanks for reporting the problem. 0x107 command has got timed out in the log. Could you please help get the device dump data when problem occurs? Issue below command for this. cat /sys/class/devcoredump/devcdX/data > data.txt Regards, Amitkumar
[PATCH] staging: wilc1000: Remove trailing whitespace errors
Remove trailing whitespace checkpatch errors.
Signed-off-by: Janani Ravichandran
---
drivers/staging/wilc1000/host_interface.c | 2 +-
drivers/staging/wilc1000/linux_mon.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index d1eedfb..04337c7 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3352,7 +3352,7 @@ static s32 host_int_get_assoc_res_info(struct wilc_vif
*vif,
PRINT_ER("Failed to send association response config packet\n");
return -EINVAL;
}
-
+
*pu32RcvdAssocRespInfoLen = wid.size;
return result;
}
diff --git a/drivers/staging/wilc1000/linux_mon.c
b/drivers/staging/wilc1000/linux_mon.c
index 21f35d7..9fcb497 100644
--- a/drivers/staging/wilc1000/linux_mon.c
+++ b/drivers/staging/wilc1000/linux_mon.c
@@ -302,7 +302,7 @@ struct net_device *WILC_WFI_init_mon_interface(const char
*name, struct net_devi
struct WILC_WFI_mon_priv *priv;
/*If monitor interface is already initialized, return it*/
- if (wilc_wfi_mon)
+ if (wilc_wfi_mon)
return wilc_wfi_mon;
wilc_wfi_mon = alloc_etherdev(sizeof(struct WILC_WFI_mon_priv));
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mac80211: provide interface to driver to set VHT MU-MIMO data
From: Sara Sharon
Provide an interface to the lower level driver to set the VHT
MU-MIMO data. This is needed for example when there is an update
of the group data during low power state, where the management
frame will not be passed to the host at all.
Signed-off-by: Sara Sharon
Signed-off-by: Emmanuel Grumbach
---
include/net/mac80211.h | 15 +++
net/mac80211/vht.c | 16 +++-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 6aad965..6ca23e3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5448,6 +5448,21 @@ ieee80211_vif_type_p2p(struct ieee80211_vif *vif)
return ieee80211_iftype_p2p(vif->type, vif->p2p);
}
+/**
+ * ieee80211_update_mu_groups - set the VHT MU-MIMO groud data
+ *
+ * @vif: the specified virtual interface
+ * @membership: 64 bits array - a bit is set if station is member of the group
+ * @position: 2 bits per group id indicating the position in the group
+ *
+ * Note: This function assumes that the given vif is valid and the position and
+ * membership data is of the correct size and are in the same byte order as the
+ * matching GroupId management frame.
+ * Calls to this function need to be serialized with RX path.
+ */
+void ieee80211_update_mu_groups(struct ieee80211_vif *vif,
+ const u8 *membership, const u8 *position);
+
void ieee80211_enable_rssi_reports(struct ieee80211_vif *vif,
int rssi_min_thold,
int rssi_max_thold);
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index 341d192..f8f1611 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -2,7 +2,7 @@
* VHT handling
*
* Portions of this file
- * Copyright(c) 2015 Intel Deutschland GmbH
+ * Copyright(c) 2015 - 2016 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -469,6 +469,20 @@ void ieee80211_process_mu_groups(struct
ieee80211_sub_if_data *sdata,
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_MU_GROUPS);
}
+void ieee80211_update_mu_groups(struct ieee80211_vif *vif,
+ const u8 *membership, const u8 *position)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct ieee80211_bss_conf *bss_conf = &sdata->vif.bss_conf;
+
+ if (WARN_ON_ONCE(!(sdata->flags & IEEE80211_SDATA_MU_MIMO_OWNER)))
+ return;
+
+ memcpy(bss_conf->mu_group.membership, membership, WLAN_MEMBERSHIP_LEN);
+ memcpy(bss_conf->mu_group.position, position, WLAN_USER_POSITION_LEN);
+}
+EXPORT_SYMBOL_GPL(ieee80211_update_mu_groups);
+
void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta, u8 opmode,
enum ieee80211_band band)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mac80211: move MU_MIMO_OWNER flag to ieee80211_vif
From: Sara Sharon
Drivers may need to track which vif is using VHT MU-MIMO.
Move the flag indicationg the ownership of MU_MIMO to
ieee80211_vif.
Signed-off-by: Sara Sharon
Signed-off-by: Emmanuel Grumbach
---
include/net/mac80211.h | 2 ++
net/mac80211/ieee80211_i.h | 2 --
net/mac80211/mlme.c| 11 ++-
net/mac80211/util.c| 2 +-
net/mac80211/vht.c | 7 +++
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 6ca23e3..9cf92d0 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1385,6 +1385,7 @@ enum ieee80211_vif_flags {
* @csa_active: marks whether a channel switch is going on. Internally it is
* write-protected by sdata_lock and local->mtx so holding either is fine
* for read access.
+ * @mu_mimo_owner: indicates interface owns MU-MIMO capability
* @driver_flags: flags/capabilities the driver has for this interface,
* these need to be set (or cleared) when the interface is added
* or, if supported by the driver, the interface type is changed
@@ -1411,6 +1412,7 @@ struct ieee80211_vif {
u8 addr[ETH_ALEN];
bool p2p;
bool csa_active;
+ bool mu_mimo_owner;
u8 cab_queue;
u8 hw_queue[IEEE80211_NUM_ACS];
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index a49c103..1630975 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -716,7 +716,6 @@ struct ieee80211_if_mesh {
* back to wireless media and to the local net stack.
* @IEEE80211_SDATA_DISCONNECT_RESUME: Disconnect after resume.
* @IEEE80211_SDATA_IN_DRIVER: indicates interface was added to driver
- * @IEEE80211_SDATA_MU_MIMO_OWNER: indicates interface owns MU-MIMO capability
*/
enum ieee80211_sub_if_data_flags {
IEEE80211_SDATA_ALLMULTI= BIT(0),
@@ -724,7 +723,6 @@ enum ieee80211_sub_if_data_flags {
IEEE80211_SDATA_DONT_BRIDGE_PACKETS = BIT(3),
IEEE80211_SDATA_DISCONNECT_RESUME = BIT(4),
IEEE80211_SDATA_IN_DRIVER = BIT(5),
- IEEE80211_SDATA_MU_MIMO_OWNER = BIT(6),
};
/**
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 857089d..f41625b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -6,7 +6,7 @@
* Copyright 2006-2007 Jiri Benc
* Copyright 2007, Michael Wu
* Copyright 2013-2014 Intel Mobile Communications GmbH
- * Copyright (C) 2015 Intel Deutschland GmbH
+ * Copyright (C) 2015 - 2016 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -559,7 +559,7 @@ static void ieee80211_add_vht_ie(struct
ieee80211_sub_if_data *sdata,
struct ieee80211_sub_if_data *other;
list_for_each_entry_rcu(other, &local->interfaces, list) {
- if (other->flags & IEEE80211_SDATA_MU_MIMO_OWNER) {
+ if (other->vif.mu_mimo_owner) {
disable_mu_mimo = true;
break;
}
@@ -567,7 +567,7 @@ static void ieee80211_add_vht_ie(struct
ieee80211_sub_if_data *sdata,
if (disable_mu_mimo)
cap &= ~IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE;
else
- sdata->flags |= IEEE80211_SDATA_MU_MIMO_OWNER;
+ sdata->vif.mu_mimo_owner = true;
}
mask = IEEE80211_VHT_CAP_BEAMFORMEE_STS_MASK;
@@ -2052,7 +2052,7 @@ static void ieee80211_set_disassoc(struct
ieee80211_sub_if_data *sdata,
memset(sdata->vif.bss_conf.mu_group.position, 0,
sizeof(sdata->vif.bss_conf.mu_group.position));
changed |= BSS_CHANGED_MU_GROUPS;
- sdata->flags &= ~IEEE80211_SDATA_MU_MIMO_OWNER;
+ sdata->vif.mu_mimo_owner = false;
sdata->ap_power_level = IEEE80211_UNSET_POWER_LEVEL;
@@ -2509,7 +2509,8 @@ static void ieee80211_destroy_assoc_data(struct
ieee80211_sub_if_data *sdata,
eth_zero_addr(sdata->u.mgd.bssid);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BSSID);
sdata->u.mgd.flags = 0;
- sdata->flags &= ~IEEE80211_SDATA_MU_MIMO_OWNER;
+ sdata->vif.mu_mimo_owner = false;
+
mutex_lock(&sdata->local->mtx);
ieee80211_vif_release_channel(sdata);
mutex_unlock(&sdata->local->mtx);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 52766f7..743265a 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1928,7 +1928,7 @@ int ieee80211_reconfig(struct ieee80211_local *local)
BSS_CHANGED_IDLE |
BSS_CHANGED_TXPOWER;
- if (sdata->flags & IEEE80211_SDATA_MU_MIMO_OWNER)
+ if (sdata->vif.mu_mimo_owner)
Re: [PATCH] mac80211: allow not sending MIC up from driver for HW crypto
On Tue, 2016-02-16 at 11:18 +0200, Emmanuel Grumbach wrote:
>
> @@ -1084,13 +1086,12 @@ enum mac80211_rx_flags {
> RX_FLAG_MACTIME_END = BIT(21),
> RX_FLAG_VHT = BIT(22),
> RX_FLAG_LDPC= BIT(23),
> - RX_FLAG_ONLY_MONITOR= BIT(24),
> - RX_FLAG_SKIP_MONITOR= BIT(25),
what?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: allow not sending MIC up from driver for HW crypto
From: Sara Sharon
When HW crypto is used, there's no need for the CCMP/GCMP MIC to
be available to mac80211, and the hardware might have removed it
already after checking. The MIC is also useless to have when the
frame is already decrypted, so allow indicating that it's not
present.
Since we are running out of bits in mac80211_rx_flags, make
the flags field a u64.
Signed-off-by: Sara Sharon
Signed-off-by: Emmanuel Grumbach
---
include/net/mac80211.h | 7 ---
net/mac80211/util.c| 5 +++--
net/mac80211/wpa.c | 26 ++
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 66155d3..e765171 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1034,6 +1034,8 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info
*info)
* on this subframe
* @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
* is stored in the @ampdu_delimiter_crc field)
+ * @RX_FLAG_MIC_STRIPPED: The mic was stripped of this packet. Decryption was
+ * done by the hardware
* @RX_FLAG_LDPC: LDPC was used
* @RX_FLAG_ONLY_MONITOR: Report frame only to monitor interfaces without
* processing it in any regular way.
@@ -1084,13 +1086,12 @@ enum mac80211_rx_flags {
RX_FLAG_MACTIME_END = BIT(21),
RX_FLAG_VHT = BIT(22),
RX_FLAG_LDPC= BIT(23),
- RX_FLAG_ONLY_MONITOR= BIT(24),
- RX_FLAG_SKIP_MONITOR= BIT(25),
RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
RX_FLAG_10MHZ = BIT(28),
RX_FLAG_5MHZ= BIT(29),
RX_FLAG_AMSDU_MORE = BIT(30),
RX_FLAG_RADIOTAP_VENDOR_DATA= BIT(31),
+ RX_FLAG_MIC_STRIPPED= BIT_ULL(32),
};
#define RX_FLAG_STBC_SHIFT 26
@@ -1148,7 +1149,7 @@ struct ieee80211_rx_status {
u64 mactime;
u32 device_timestamp;
u32 ampdu_reference;
- u32 flag;
+ u64 flag;
u16 freq;
u8 vht_flag;
u8 rate_idx;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index f1e5b76..52766f7 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2714,8 +2714,9 @@ u64 ieee80211_calculate_rx_timestamp(struct
ieee80211_local *local,
rate = cfg80211_calculate_bitrate(&ri);
if (WARN_ONCE(!rate,
- "Invalid bitrate: flags=0x%x, idx=%d, vht_nss=%d\n",
- status->flag, status->rate_idx, status->vht_nss))
+ "Invalid bitrate: flags=0x%llx, idx=%d, vht_nss=%d\n",
+ (unsigned long long)status->flag, status->rate_idx,
+ status->vht_nss))
return 0;
/* rewind from end of MPDU */
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 1884825..7e4f265 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -504,18 +504,20 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data
*rx,
!ieee80211_is_robust_mgmt_frame(skb))
return RX_CONTINUE;
- data_len = skb->len - hdrlen - IEEE80211_CCMP_HDR_LEN - mic_len;
- if (!rx->sta || data_len < 0)
- return RX_DROP_UNUSABLE;
-
if (status->flag & RX_FLAG_DECRYPTED) {
if (!pskb_may_pull(rx->skb, hdrlen + IEEE80211_CCMP_HDR_LEN))
return RX_DROP_UNUSABLE;
+ if (status->flag & RX_FLAG_MIC_STRIPPED)
+ mic_len = 0;
} else {
if (skb_linearize(rx->skb))
return RX_DROP_UNUSABLE;
}
+ data_len = skb->len - hdrlen - IEEE80211_CCMP_HDR_LEN - mic_len;
+ if (!rx->sta || data_len < 0)
+ return RX_DROP_UNUSABLE;
+
if (!(status->flag & RX_FLAG_PN_VALIDATED)) {
ccmp_hdr2pn(pn, skb->data + hdrlen);
@@ -720,8 +722,7 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data *rx)
struct sk_buff *skb = rx->skb;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
u8 pn[IEEE80211_GCMP_PN_LEN];
- int data_len;
- int queue;
+ int data_len, queue, mic_len = IEEE80211_GCMP_MIC_LEN;
hdrlen = ieee80211_hdrlen(hdr->frame_control);
@@ -729,19 +730,20 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data
*rx)
!ieee80211_is_robust_mgmt_frame(skb))
return RX_CONTINUE;
- data_len = skb->len - hdrlen - IEEE80211_GCMP_HDR_LEN -
- IEEE80211_GCMP_MIC_LEN;
- if (!rx->sta || data_len < 0)
- return RX_DROP_UNUSABLE;
-
if (status->flag & RX_FLAG_DECRYPTED) {
if (!pskb_may_pull(rx->skb, hdrlen + IEEE80211_GCMP_HDR_LEN))
return RX_DROP_UNUSABLE;
+ if (status->flag & RX_FLAG_MIC_STRIPPED)
+ mic_
[PATCH 7/7] staging: wilc1000: handle_set_mac_address: use netdev_err
This patch uses netdev_err instead of PRINT_ER that is a custom debug
print.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/host_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index bfca0b4..d5859c5 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -442,7 +442,7 @@ static void handle_set_mac_address(struct wilc_vif *vif,
ret = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
wilc_get_vif_idx(vif));
if (ret)
- PRINT_ER("Failed to set mac address\n");
+ netdev_err(vif->ndev, "Failed to set mac address\n");
kfree(mac_buf);
}
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] staging: wilc1000: handle_set_mac_address: rename result
This patch renames result to ret that is used to get return value from
wilc_send_config_pkt. It will be changed until all handle_*() function
has same variable name as ret.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/host_interface.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 90321a3..bfca0b4 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -427,7 +427,7 @@ static s32 handle_get_ip_address(struct wilc_vif *vif, u8
idx)
static void handle_set_mac_address(struct wilc_vif *vif,
struct set_mac_addr *set_mac_addr)
{
- int result = 0;
+ int ret = 0;
struct wid wid;
u8 *mac_buf = kmemdup(set_mac_addr->mac_addr, ETH_ALEN, GFP_KERNEL);
@@ -439,9 +439,9 @@ static void handle_set_mac_address(struct wilc_vif *vif,
wid.val = mac_buf;
wid.size = ETH_ALEN;
- result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
- wilc_get_vif_idx(vif));
- if (result)
+ ret = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
+ wilc_get_vif_idx(vif));
+ if (ret)
PRINT_ER("Failed to set mac address\n");
kfree(mac_buf);
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] staging: wilc1000: handle_set_mac_address: change data type of result
result variable gets value from wilc_send_config_pkt that has return
value of int. This patch changes data type of result variable to int.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/host_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index c671f05..90321a3 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -427,7 +427,7 @@ static s32 handle_get_ip_address(struct wilc_vif *vif, u8
idx)
static void handle_set_mac_address(struct wilc_vif *vif,
struct set_mac_addr *set_mac_addr)
{
- s32 result = 0;
+ int result = 0;
struct wid wid;
u8 *mac_buf = kmemdup(set_mac_addr->mac_addr, ETH_ALEN, GFP_KERNEL);
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] staging: wilc1000: handle_set_mac_address: change return type to void
When handle_set_mac_address is called in hostIFthread that is a kernel
thread, it is not checked return type of this function. This patch
changes return type to void and removes a brace of if statement due to
have a single statement.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/host_interface.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 65d2393..c671f05 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -424,15 +424,15 @@ static s32 handle_get_ip_address(struct wilc_vif *vif, u8
idx)
return result;
}
-static s32 handle_set_mac_address(struct wilc_vif *vif,
- struct set_mac_addr *set_mac_addr)
+static void handle_set_mac_address(struct wilc_vif *vif,
+ struct set_mac_addr *set_mac_addr)
{
s32 result = 0;
struct wid wid;
u8 *mac_buf = kmemdup(set_mac_addr->mac_addr, ETH_ALEN, GFP_KERNEL);
if (!mac_buf)
- return -ENOMEM;
+ return;
wid.id = (u16)WID_MAC_ADDR;
wid.type = WID_STR;
@@ -441,13 +441,10 @@ static s32 handle_set_mac_address(struct wilc_vif *vif,
result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
wilc_get_vif_idx(vif));
- if (result) {
+ if (result)
PRINT_ER("Failed to set mac address\n");
- result = -EFAULT;
- }
kfree(mac_buf);
- return result;
}
static s32 handle_get_mac_address(struct wilc_vif *vif,
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] staging: wilc1000: handle_set_mac_address: use kmemdup
This patch replaces kmalloc followed by memcpy with kmemdup.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/host_interface.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 4d50b38..65d2393 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -429,13 +429,11 @@ static s32 handle_set_mac_address(struct wilc_vif *vif,
{
s32 result = 0;
struct wid wid;
- u8 *mac_buf = kmalloc(ETH_ALEN, GFP_KERNEL);
+ u8 *mac_buf = kmemdup(set_mac_addr->mac_addr, ETH_ALEN, GFP_KERNEL);
if (!mac_buf)
return -ENOMEM;
- memcpy(mac_buf, set_mac_addr->mac_addr, ETH_ALEN);
-
wid.id = (u16)WID_MAC_ADDR;
wid.type = WID_STR;
wid.val = mac_buf;
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] staging: wilc1000: handle_set_mac_address: remove debug message of kmalloc failure
There is no need to print debug message when kmalloc is failed. This
message is redundant. The code already show us that kmalloc is failed.
The brace of if statement is remove as well due to have a single
statement.
Signed-off-by: Chaehyun Lim
---
drivers/staging/wilc1000/host_interface.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index d1eedfb..579b90a 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -431,10 +431,9 @@ static s32 handle_set_mac_address(struct wilc_vif *vif,
struct wid wid;
u8 *mac_buf = kmalloc(ETH_ALEN, GFP_KERNEL);
- if (!mac_buf) {
- PRINT_ER("No buffer to send mac address\n");
+ if (!mac_buf)
return -EFAULT;
- }
+
memcpy(mac_buf, set_mac_addr->mac_addr, ETH_ALEN);
wid.id = (u16)WID_MAC_ADDR;
--
2.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] staging: wilc1000: handle_set_mac_address: fix kmalloc return error code
This patch fix return error code of kmalloc as -ENOMEM instead of -EFAULT. Signed-off-by: Chaehyun Lim --- drivers/staging/wilc1000/host_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index 579b90a..4d50b38 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -432,7 +432,7 @@ static s32 handle_set_mac_address(struct wilc_vif *vif, u8 *mac_buf = kmalloc(ETH_ALEN, GFP_KERNEL); if (!mac_buf) - return -EFAULT; + return -ENOMEM; memcpy(mac_buf, set_mac_addr->mac_addr, ETH_ALEN); -- 2.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
