* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 18:03 UTC (permalink / raw)
To: Oleksij Rempel, Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <20130619175939.GA19405@zenon.in.qult.net>
On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
> > Ignacy, Is it RPi + TL-WN722NC?
>
> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
--
Everything is more fun naked except cooking with grease.
^ permalink raw reply
* Howto remove rfkill from kernel
From: rlwkayaker @ 2013-06-19 17:36 UTC (permalink / raw)
To: linux-wireless
The rfkill "feature" has rendered the internal wireless of my
Averatec 3260 laptop unusable. It works fine with earlier
kernels without this "feature". How do I remove the rfkill
"feature" from a custom built kernel?
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 17:59 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Johannes Berg, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1C95C.8030301@rempel-privat.de>
On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
> Ignacy wrote:
> >The station is unable to authenticate with WPA2 to the AP. Interestingly
> >enough, if a monitor vif is created and upped beforehand, the authentication
> >succeeds.
>
> which looks more like power management issue. If monitore mode is
> enabled, no power sawing is done. But i use CFG80211_DEFAULT_PS=y on
> my system too and didn't had this issue. Even power_save=on is
> working. What else is different?
>
> Ignacy, Is it RPi + TL-WN722NC?
Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
--
P.S. All information contained in the above letter is false,
for reasons of military security.
^ permalink raw reply
* Re: Re: bug-report: Ralink corp. Device [1814:539a] - Kernel 3.8 +
From: Lars Zastrow @ 2013-06-19 17:59 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: backports, linux-wireless
In-Reply-To: <20130619131234.GB2580@redhat.com>
Am 19.06.2013 15:12, schrieb Stanislaw Gruszka:
> On Mon, Jun 17, 2013 at 05:18:32AM +0200, Lars Zastrow wrote:
>> Dear Team,
>>
>> I'am using the following wireless-network-device:
>>
>> Network controller [0280]: Ralink corp. Device [1814:539a]
>> Subsystem: Hewlett-Packard Company Device [103c:1839]
>> Kernel driver in use: rt2800pci
>>
>> I had problems with it since I bought my laptop... The driver was
>> unstable with the kernel I used back in autumn 2012. Howeverer, one
>> kernel-update fixed it. Must be something about 3.4x?
>>
>> It was defenetly working with the Kernels from 3.5 till 3.7 on
>> multible distros. 3.8 was bringing back the old Problems:
>>
>> - extremly low signal
>> - hard to establish a connection to any acess-point.
>>
>> The last "problematic" kernel I have testet was 3.9.5-1 on
>> Arch-Linux. Compiling the compat-drivers manually did not bring any
>> fix.
>>
>> I am currently using 3.7.4-1 wich is working.
> This most likely is a RT5390 TX power problem I made on 3.8.
>
> This patch should help:
> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=8c8d2017ba25c510ddf093419048460db1109bc4
>
> Stanislaw
Yes, indeed! It helps.
Now it was possible to upgrade my kernel, without losing my
wireless-device to be usable. Thank you very much.
I'm afraid it is not a "flawless" experience.
On the git-page you mentioned:
> Once we implement proper TSSI tuning on 5390/3290 we can restore back
setting TX power by BBP_R1 register for those chips.
Is there any hope, that the driver will increase its performance one day?
...there are better chips on the market, that is for sure.
Regards
Lars Zastrow
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Ben Greear @ 2013-06-19 17:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Wireless List
In-Reply-To: <1371661217.8349.26.camel@jlt4.sipsolutions.net>
On 06/19/2013 10:00 AM, Johannes Berg wrote:
> On Wed, 2013-06-19 at 09:57 -0700, Ben Greear wrote:
>> On 06/19/2013 01:23 AM, Johannes Berg wrote:
>>> From: Johannes Berg <johannes.berg@intel.com>
>>>
>>> Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
>
>> The commit mentioned above (3713b4e364) is in 3.9.6,
>
> It isn't according to my git. :-)
Ahh, I was thinking that if 'git show foo' showed it, it was in that branch,
but I suppose that is not actually the case.
Sorry about that.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Chris Adams @ 2013-06-19 16:42 UTC (permalink / raw)
To: Larry Finger; +Cc: b43-dev, linux-wireless
In-Reply-To: <51C1DDEB.3090701@lwfinger.net>
Once upon a time, Larry Finger <Larry.Finger@lwfinger.net> said:
> What type of encryption are you using? If it is a re-keying type
> such as TKIP, what is the interval? You should find that on the
> setup page of the access point.
I don't have access to the management of this particular AP (work
environment), but "iw dev wlan0 scan dump" says CCMP.
> BTW, your mailer is set up strangely. I get your address when I do a
> plain Reply, but a Reply All from Thunderbird only got the b43-dev
> mailing list. I had to add your address manually.
I'm using Mutt, which sets "Mail-Followup-To: <listaddr>" for configured
mailing lists. If you were just replying to the b43-dev list, a CC to
me isn't really needed (I subscribed before sending; didn't know if
non-subscribers were allowed to send messages).
--
Chris Adams <cmadams@cmadams.net>
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Johannes Berg @ 2013-06-19 17:00 UTC (permalink / raw)
To: Ben Greear; +Cc: Linux Wireless List
In-Reply-To: <51C1E2FF.3030309@candelatech.com>
On Wed, 2013-06-19 at 09:57 -0700, Ben Greear wrote:
> On 06/19/2013 01:23 AM, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
> The commit mentioned above (3713b4e364) is in 3.9.6,
It isn't according to my git. :-)
johannes
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Rafał Miłecki @ 2013-06-19 16:57 UTC (permalink / raw)
To: Larry Finger, b43-dev, linux-wireless
In-Reply-To: <20130619164227.GC4784@cmadams.net>
2013/6/19 Chris Adams <cmadams@cmadams.net>:
> Once upon a time, Larry Finger <Larry.Finger@lwfinger.net> said:
>> What type of encryption are you using? If it is a re-keying type
>> such as TKIP, what is the interval? You should find that on the
>> setup page of the access point.
>
> I don't have access to the management of this particular AP (work
> environment), but "iw dev wlan0 scan dump" says CCMP.
I think some key interval applies not only to the TKIP, but also other
keys. For example GTK (which is part of WPA2 with it's 4-way
handshake). GTK is Group Temporal Key, and Broadcom's router have a
setting called "GTK rotation interval". I guess PMK/PTK also can have
some intervals.
I don't know how/if driver can be responsible for such reconnects.
Over all it just TX and RX packets, right? Loosing a signal is
something different, that can be related to the driver's bug. But as
this happens every 5 minutes... I don't know.
Did you try connecting to this AP with any other card and using
similar kernel? I wonder if this can be some supplicant / mac80211
stack issue...
--
Rafał
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Ben Greear @ 2013-06-19 16:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Wireless List
In-Reply-To: <1371630238.8349.6.camel@jlt4.sipsolutions.net>
On 06/19/2013 01:23 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
> nl80211_fam.attrbuf for parsing the incoming data. This wouldn't
> be a problem if it only did so on the first dump iteration which
> is locked against other commands in generic netlink, but due to
> space constraints in cb->args (the needed state doesn't fit) I
> decided to always parse the original message. That's racy though
> since nl80211_fam.attrbuf could be used by some other parsing in
> generic netlink concurrently.
>
> For now, fix this by allocating a separate parse buffer (it's a
> bit too big for the stack, currently 1448 bytes on 64-bit). For
> -next, I'll change the code to parse into the global buffer in
> the first round only and then allocate a smaller buffer to keep
> the state in cb->args.
The commit mentioned above (3713b4e364) is in 3.9.6, but this patch
doesn't come close to applying on my 3.9.6.
Do you happen to know if this should be backported to 3.9 stable or not?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] brcmfmac: Turn off ARP offloading when configured for AP.
From: Greg KH @ 2013-06-19 16:52 UTC (permalink / raw)
To: Arend van Spriel; +Cc: stable, linux-wireless, Hante Meuleman, John W. Linville
In-Reply-To: <51C1D392.8060705@broadcom.com>
On Wed, Jun 19, 2013 at 05:51:46PM +0200, Arend van Spriel wrote:
> On 06/19/2013 04:19 PM, Greg KH wrote:
> >On Wed, Jun 19, 2013 at 09:27:09AM +0200, Arend van Spriel wrote:
> >>On 06/06/2013 10:55 AM, Arend van Spriel wrote:
> >>>From: Hante Meuleman <meuleman@broadcom.com>
> >>
> >>Hi Greg,
> >>
> >>I noticed your review announcement for v3.9.7 and did not see the
> >>change below. I sent it to stable because the original upstream
> >>commit did not apply. Did I miss some step in the process?
> >
> >Ah, somehow I missed your patch, sorry about that, I do have it in my
> >mbox. What kernel tree(s) do you want it to be applied to? I'll pick
> >it up in my next round of releases.
>
> Thanks, Greg
>
> I backported it for the 3.9 tree. It does not apply to 3.8 so I will
> have to create another backport if I need it there.
3.8 is long dead and not maintained by me anymore, but thanks.
Next time you submit stable patches, please let us know somewhere in the
patch/subject what tree it applies to, that makes our lives much easier,
otherwise I just guess and ususally get it wrong :)
thanks,
greg k-h
^ permalink raw reply
* Re: BCM4331 deauthenticates every five minutes
From: Larry Finger @ 2013-06-19 16:35 UTC (permalink / raw)
To: Chris Adams; +Cc: b43-dev, linux-wireless
In-Reply-To: <20130619160911.GB4784@cmadams.net>
On 06/19/2013 11:09 AM, Chris Adams wrote:
> I have a MacBook Pro 8,2 with the BCM4331 wireless chip. I pulled the
> firmware (666.2, 2011-02-23 01:15:07) using b43-fwcutter, and am running
> Fedora 18 (tried up to kernel 3.9.6-200.fc18.x86_64 from updates/testing
> with the same results).
>
> My problem is that it deauthenticates from the AP every 5 minutes (it
> then immediately reconnects). From what I've read, it looks like this
> chip is a little "different"; any ideas/suggestions to help get this
> working better?
>
> Example dmesg chunk:
>
> [ 948.115374] wlan0: associated
> [ 1249.636655] wlan0: deauthenticated from 00:a0:c8:xx:xx:xx (Reason: 1)
My table shows that a "Reason 1" deauthentication is for "unspecified reasons".
Does anyone know why these might occur?
What type of encryption are you using? If it is a re-keying type such as TKIP,
what is the interval? You should find that on the setup page of the access point.
BTW, your mailer is set up strangely. I get your address when I do a plain
Reply, but a Reply All from Thunderbird only got the b43-dev mailing list. I had
to add your address manually.
I also added the linux-wireless ML to the reply as some of my questions are more
likely to be answered there.
Larry
^ permalink raw reply
* pull-request: mac80211 2013-06-19
From: Johannes Berg @ 2013-06-19 16:34 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
Hi John,
One more ...
This is just the fix for the nl80211_fam.attrbuf race Linus ran into and
analysed.
johannes
The following changes since commit 795d855d56c6d172f50a974f603ba923ac93ee76:
mac80211: Fix rate control mask matching call (2013-06-12 09:12:43 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to 3a5a423bb958ad22eeccca66c533e85bf69ba10e:
nl80211: fix attrbuf access race by allocating a separate one (2013-06-19 18:31:20 +0200)
----------------------------------------------------------------
Johannes Berg (1):
nl80211: fix attrbuf access race by allocating a separate one
net/wireless/nl80211.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Linus Torvalds @ 2013-06-19 16:26 UTC (permalink / raw)
To: Johannes Berg
Cc: David Miller, John Linville, Linux Wireless List,
Network Development
In-Reply-To: <1371630238.8349.6.camel@jlt4.sipsolutions.net>
On Tue, Jun 18, 2013 at 10:23 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> Let me know if you want to apply this directly, otherwise I'll send it
> on its way to John.
The problem doesn't happen often enough to make this an acute issue
for me, so this patch might as well go through the normal channels.
Thanks,
Linus
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: hold BSS over association process
From: Ben Greear @ 2013-06-19 16:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1371650017-14293-2-git-send-email-johannes@sipsolutions.net>
On 06/19/2013 06:53 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This fixes the potential issue that the BSS struct that we use
> and later assign to wdev->current_bss is removed from the scan
> list while associating.
>
> Also warn when we don't have a BSS struct in connect_result
> unless it's from a driver that only has the connect() API.
This also looks OK to me, but I have not tested it.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: require passing BSS struct back to cfg80211_assoc_timeout
From: Ben Greear @ 2013-06-19 15:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1371650017-14293-1-git-send-email-johannes@sipsolutions.net>
On 06/19/2013 06:53 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Doing so will allow us to hold the BSS (not just ref it) over the
> association process, thus ensuring that it doesn't time out and
> gets invisible to the user (e.g. in 'iw wlan0 link'.)
>
> This also fixes a leak in mac80211 where it doesn't always release
> the BSS struct properly in all cases where calling this function.
> This leak was reported by Ben Greear.
I have not yet tested this, but I read it closely and
it appears to fix the same problem I tried to fix in
the 2/6 "Fix bss leak." patch.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH 2/3 v2] mwifiex: add basic 11h support for station
From: Bing Zhao @ 2013-06-19 15:49 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Paul Stewart
From: Amitkumar Karwar <akarwar@marvell.com>
This patch adds code to parse requested AP's 11h capabilities
and add 11h information in association request.
Also, deauth is sent to the AP after receiving channel switch
announcement event from firmware. This happens when AP advertises
WLAN_EID_CHANNEL_SWITCH IE in it's beacon.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
---
v2: fix missing 'break' statement (John W. Linville)
drivers/net/wireless/mwifiex/11h.c | 101 +++++++++++++++++++++++++++++++
drivers/net/wireless/mwifiex/Makefile | 1 +
drivers/net/wireless/mwifiex/fw.h | 14 +++++
drivers/net/wireless/mwifiex/join.c | 2 +
drivers/net/wireless/mwifiex/main.h | 7 +++
drivers/net/wireless/mwifiex/scan.c | 19 ++++++
drivers/net/wireless/mwifiex/sta_event.c | 8 +++
drivers/net/wireless/mwifiex/sta_ioctl.c | 3 +
8 files changed, 155 insertions(+)
create mode 100644 drivers/net/wireless/mwifiex/11h.c
diff --git a/drivers/net/wireless/mwifiex/11h.c b/drivers/net/wireless/mwifiex/11h.c
new file mode 100644
index 0000000..8d68307
--- /dev/null
+++ b/drivers/net/wireless/mwifiex/11h.c
@@ -0,0 +1,101 @@
+/*
+ * Marvell Wireless LAN device driver: 802.11h
+ *
+ * Copyright (C) 2013, Marvell International Ltd.
+ *
+ * This software file (the "File") is distributed by Marvell International
+ * Ltd. under the terms of the GNU General Public License Version 2, June 1991
+ * (the "License"). You may use, redistribute and/or modify this File in
+ * accordance with the terms and conditions of the License, a copy of which
+ * is available by writing to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA or on the
+ * worldwide web at http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
+ *
+ * THE FILE IS DISTRIBUTED AS-IS, WITHOUT WARRANTY OF ANY KIND, AND THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
+ * ARE EXPRESSLY DISCLAIMED. The License provides additional details about
+ * this warranty disclaimer.
+ */
+
+#include "main.h"
+#include "fw.h"
+
+
+/* This function appends 11h info to a buffer while joining an
+ * infrastructure BSS
+ */
+static void
+mwifiex_11h_process_infra_join(struct mwifiex_private *priv, u8 **buffer,
+ struct mwifiex_bssdescriptor *bss_desc)
+{
+ struct mwifiex_ie_types_header *ie_header;
+ struct mwifiex_ie_types_pwr_capability *cap;
+ struct mwifiex_ie_types_local_pwr_constraint *constraint;
+ struct ieee80211_supported_band *sband;
+ u8 radio_type;
+ int i;
+
+ if (!buffer || !(*buffer))
+ return;
+
+ radio_type = mwifiex_band_to_radio_type((u8) bss_desc->bss_band);
+ sband = priv->wdev->wiphy->bands[radio_type];
+
+ cap = (struct mwifiex_ie_types_pwr_capability *)*buffer;
+ cap->header.type = cpu_to_le16(WLAN_EID_PWR_CAPABILITY);
+ cap->header.len = cpu_to_le16(2);
+ cap->min_pwr = 0;
+ cap->max_pwr = 0;
+ *buffer += sizeof(*cap);
+
+ constraint = (struct mwifiex_ie_types_local_pwr_constraint *)*buffer;
+ constraint->header.type = cpu_to_le16(WLAN_EID_PWR_CONSTRAINT);
+ constraint->header.len = cpu_to_le16(2);
+ constraint->chan = bss_desc->channel;
+ constraint->constraint = bss_desc->local_constraint;
+ *buffer += sizeof(*constraint);
+
+ ie_header = (struct mwifiex_ie_types_header *)*buffer;
+ ie_header->type = cpu_to_le16(TLV_TYPE_PASSTHROUGH);
+ ie_header->len = cpu_to_le16(2 * sband->n_channels + 2);
+ *buffer += sizeof(*ie_header);
+ *(*buffer)++ = WLAN_EID_SUPPORTED_CHANNELS;
+ *(*buffer)++ = 2 * sband->n_channels;
+ for (i = 0; i < sband->n_channels; i++) {
+ *(*buffer)++ = ieee80211_frequency_to_channel(
+ sband->channels[i].center_freq);
+ *(*buffer)++ = 1; /* one channel in the subband */
+ }
+}
+
+/* Enable or disable the 11h extensions in the firmware */
+static int mwifiex_11h_activate(struct mwifiex_private *priv, bool flag)
+{
+ u32 enable = flag;
+
+ return mwifiex_send_cmd_sync(priv, HostCmd_CMD_802_11_SNMP_MIB,
+ HostCmd_ACT_GEN_SET, DOT11H_I, &enable);
+}
+
+/* This functions processes TLV buffer for a pending BSS Join command.
+ *
+ * Activate 11h functionality in the firmware if the spectrum management
+ * capability bit is found in the network we are joining. Also, necessary
+ * TLVs are set based on requested network's 11h capability.
+ */
+void mwifiex_11h_process_join(struct mwifiex_private *priv, u8 **buffer,
+ struct mwifiex_bssdescriptor *bss_desc)
+{
+ if (bss_desc->sensed_11h) {
+ /* Activate 11h functions in firmware, turns on capability
+ * bit
+ */
+ mwifiex_11h_activate(priv, true);
+ bss_desc->cap_info_bitmap |= WLAN_CAPABILITY_SPECTRUM_MGMT;
+ mwifiex_11h_process_infra_join(priv, buffer, bss_desc);
+ } else {
+ /* Deactivate 11h functions in the firmware */
+ mwifiex_11h_activate(priv, false);
+ bss_desc->cap_info_bitmap &= ~WLAN_CAPABILITY_SPECTRUM_MGMT;
+ }
+}
diff --git a/drivers/net/wireless/mwifiex/Makefile b/drivers/net/wireless/mwifiex/Makefile
index ecf2846..a42a506 100644
--- a/drivers/net/wireless/mwifiex/Makefile
+++ b/drivers/net/wireless/mwifiex/Makefile
@@ -40,6 +40,7 @@ mwifiex-y += sta_rx.o
mwifiex-y += uap_txrx.o
mwifiex-y += cfg80211.o
mwifiex-y += ethtool.o
+mwifiex-y += 11h.o
mwifiex-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_MWIFIEX) += mwifiex.o
diff --git a/drivers/net/wireless/mwifiex/fw.h b/drivers/net/wireless/mwifiex/fw.h
index d6ada73..b6fbbf6 100644
--- a/drivers/net/wireless/mwifiex/fw.h
+++ b/drivers/net/wireless/mwifiex/fw.h
@@ -438,6 +438,7 @@ enum P2P_MODES {
#define EVENT_BW_CHANGE 0x00000048
#define EVENT_UAP_MIC_COUNTERMEASURES 0x0000004c
#define EVENT_HOSTWAKE_STAIE 0x0000004d
+#define EVENT_CHANNEL_SWITCH_ANN 0x00000050
#define EVENT_REMAIN_ON_CHAN_EXPIRED 0x0000005f
#define EVENT_ID_MASK 0xffff
@@ -975,6 +976,7 @@ enum SNMP_MIB_INDEX {
LONG_RETRY_LIM_I = 7,
FRAG_THRESH_I = 8,
DOT11D_I = 9,
+ DOT11H_I = 10,
};
#define MAX_SNMP_BUF_SIZE 128
@@ -1206,6 +1208,18 @@ struct host_cmd_ds_sta_deauth {
__le16 reason;
} __packed;
+struct mwifiex_ie_types_pwr_capability {
+ struct mwifiex_ie_types_header header;
+ s8 min_pwr;
+ s8 max_pwr;
+};
+
+struct mwifiex_ie_types_local_pwr_constraint {
+ struct mwifiex_ie_types_header header;
+ u8 chan;
+ u8 constraint;
+};
+
struct mwifiex_ie_types_wmm_param_set {
struct mwifiex_ie_types_header header;
u8 wmm_ie[1];
diff --git a/drivers/net/wireless/mwifiex/join.c b/drivers/net/wireless/mwifiex/join.c
index 122175a..1c8a771 100644
--- a/drivers/net/wireless/mwifiex/join.c
+++ b/drivers/net/wireless/mwifiex/join.c
@@ -534,6 +534,8 @@ int mwifiex_cmd_802_11_associate(struct mwifiex_private *priv,
mwifiex_cmd_append_tsf_tlv(priv, &pos, bss_desc);
+ mwifiex_11h_process_join(priv, &pos, bss_desc);
+
cmd->size = cpu_to_le16((u16) (pos - (u8 *) assoc) + S_DS_GEN);
/* Set the Capability info at last */
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 0832c24..95a6f52 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -309,6 +309,9 @@ struct mwifiex_bssdescriptor {
u16 wapi_offset;
u8 *beacon_buf;
u32 beacon_buf_size;
+ u8 sensed_11h;
+ u8 local_constraint;
+ u8 chan_sw_ie_present;
};
struct mwifiex_current_bss_params {
@@ -1119,6 +1122,10 @@ u8 *mwifiex_11d_code_2_region(u8 code);
void mwifiex_uap_del_sta_data(struct mwifiex_private *priv,
struct mwifiex_sta_node *node);
+void mwifiex_11h_process_join(struct mwifiex_private *priv, u8 **buffer,
+ struct mwifiex_bssdescriptor *bss_desc);
+int mwifiex_11h_handle_event_chanswann(struct mwifiex_private *priv);
+
extern const struct ethtool_ops mwifiex_ethtool_ops;
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index 801b6b7..284d68b 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -391,6 +391,12 @@ mwifiex_is_network_compatible(struct mwifiex_private *priv,
return 0;
}
+ if (bss_desc->chan_sw_ie_present) {
+ dev_err(adapter->dev,
+ "Don't connect to AP with WLAN_EID_CHANNEL_SWITCH\n");
+ return -1;
+ }
+
if (mwifiex_is_bss_wapi(priv, bss_desc)) {
dev_dbg(adapter->dev, "info: return success for WAPI AP\n");
return 0;
@@ -1169,6 +1175,19 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
bss_entry->erp_flags = *(current_ptr + 2);
break;
+ case WLAN_EID_PWR_CONSTRAINT:
+ bss_entry->local_constraint = *(current_ptr + 2);
+ bss_entry->sensed_11h = true;
+ break;
+
+ case WLAN_EID_CHANNEL_SWITCH:
+ bss_entry->chan_sw_ie_present = true;
+ case WLAN_EID_PWR_CAPABILITY:
+ case WLAN_EID_TPC_REPORT:
+ case WLAN_EID_QUIET:
+ bss_entry->sensed_11h = true;
+ break;
+
case WLAN_EID_EXT_SUPP_RATES:
/*
* Only process extended supported rate
diff --git a/drivers/net/wireless/mwifiex/sta_event.c b/drivers/net/wireless/mwifiex/sta_event.c
index 41aafc7..d28c920 100644
--- a/drivers/net/wireless/mwifiex/sta_event.c
+++ b/drivers/net/wireless/mwifiex/sta_event.c
@@ -427,6 +427,14 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
break;
+ case EVENT_CHANNEL_SWITCH_ANN:
+ dev_dbg(adapter->dev, "event: Channel Switch Announcement\n");
+ ret = mwifiex_send_cmd_async(priv,
+ HostCmd_CMD_802_11_DEAUTHENTICATE,
+ HostCmd_ACT_GEN_SET, 0,
+ priv->curr_bss_params.bss_descriptor.mac_address);
+ break;
+
default:
dev_dbg(adapter->dev, "event: unknown event id: %#x\n",
eventcause);
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 15b5457..498add7 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -178,6 +178,9 @@ int mwifiex_fill_new_bss_desc(struct mwifiex_private *priv,
*/
bss_desc->disable_11ac = true;
+ if (bss_desc->cap_info_bitmap & WLAN_CAPABILITY_SPECTRUM_MGMT)
+ bss_desc->sensed_11h = true;
+
return mwifiex_update_bss_desc_with_ie(priv->adapter, bss_desc);
}
--
1.8.2.3
^ permalink raw reply related
* Re: [PATCH] brcmfmac: Turn off ARP offloading when configured for AP.
From: Arend van Spriel @ 2013-06-19 15:51 UTC (permalink / raw)
To: Greg KH; +Cc: stable, linux-wireless, Hante Meuleman, John W. Linville
In-Reply-To: <20130619141920.GB7395@kroah.com>
On 06/19/2013 04:19 PM, Greg KH wrote:
> On Wed, Jun 19, 2013 at 09:27:09AM +0200, Arend van Spriel wrote:
>> On 06/06/2013 10:55 AM, Arend van Spriel wrote:
>>> From: Hante Meuleman <meuleman@broadcom.com>
>>
>> Hi Greg,
>>
>> I noticed your review announcement for v3.9.7 and did not see the
>> change below. I sent it to stable because the original upstream
>> commit did not apply. Did I miss some step in the process?
>
> Ah, somehow I missed your patch, sorry about that, I do have it in my
> mbox. What kernel tree(s) do you want it to be applied to? I'll pick
> it up in my next round of releases.
Thanks, Greg
I backported it for the 3.9 tree. It does not apply to 3.8 so I will
have to create another backport if I need it there.
Regards,
Arend
^ permalink raw reply
* RE: [PATCH 2/3] mwifiex: add basic 11h support for station
From: Bing Zhao @ 2013-06-19 15:45 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, Amitkumar Karwar, Avinash Patil,
Yogesh Powar, Nishant Sarmukadam, Frank Huang, Paul Stewart
In-Reply-To: <20130619142446.GC12079@tuxdriver.com>
Hi John,
Thanks for your comment.
> > @@ -427,6 +427,13 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
> >
> > break;
> >
> > + case EVENT_CHANNEL_SWITCH_ANN:
> > + dev_dbg(adapter->dev, "event: Channel Switch Announcement\n");
> > + ret = mwifiex_send_cmd_async(priv,
> > + HostCmd_CMD_802_11_DEAUTHENTICATE,
> > + HostCmd_ACT_GEN_SET, 0,
> > + priv->curr_bss_params.bss_descriptor.mac_address);
> > +
> > default:
> > dev_dbg(adapter->dev, "event: unknown event id: %#x\n",
> > eventcause);
>
> Do you mean for this case to fall-through to the default case?
No. I will fix it in v2.
Thanks,
Bing
^ permalink raw reply
* [RFC] P2P find phase offload
From: Vladimir Kondratiev @ 2013-06-19 15:26 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen
In-Reply-To: <1370358191-7103-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
Hi,
In discussion about P2P find phase offload, I see one bit that was not cleared,
and want to discuss it prior to coding: probe replying policy.
option 1: all or nothing. If device indicates NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD, it should
answer all matching probes, and wpa_s should never answer probes. If device don't indicate offload,
it never answer probes and wpa_s do answer all matching probes.
option 2: flexible. If device indicates NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD, it may answer some
matching probes, and wpa_s should answer ones that device missed for some reason. To enable this,
add 'flags' parameter to cfg80211_rx_mgmt() saying whether frame was replied by device/driver.
Real question here is whether there are devices that can answer probes, but not always.
If such devices are real, option 2 is better. I know that for 60g, I'd like to add some more
bits to 'flags' from option 2, so I am biased to this option.
Comments?
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Corey Richardson @ 2013-06-19 15:11 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Johannes Berg, Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <51C1C95C.8030301@rempel-privat.de>
On Wed, Jun 19, 2013 at 11:08 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 19.06.2013 16:11, schrieb Johannes Berg:
>>
>> Btw, I'm a bit confused -- are you using ath9k_htc as per the subject,
>> or ath9k?
>>
>> if it's ath9k_htc then I don't really understand why the patch that
>> *fixed* it for Corey *broke* it for you?
>>
>> johannes
>
>
> It will be interesting to get some more info from Corey, about his wireless
> setup.
>
It seems many of my issues were related to a faulty WAP, once I
replaced it with a different one 90% of my problems went away. What
information do you want?
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 15:08 UTC (permalink / raw)
To: Johannes Berg
Cc: Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <1371651073.8349.19.camel@jlt4.sipsolutions.net>
Am 19.06.2013 16:11, schrieb Johannes Berg:
> Btw, I'm a bit confused -- are you using ath9k_htc as per the subject,
> or ath9k?
>
> if it's ath9k_htc then I don't really understand why the patch that
> *fixed* it for Corey *broke* it for you?
>
> johannes
It will be interesting to get some more info from Corey, about his
wireless setup.
Ignacy wrote:
> The station is unable to authenticate with WPA2 to the AP. Interestingly
> enough, if a monitor vif is created and upped beforehand, the authentication
> succeeds.
which looks more like power management issue. If monitore mode is
enabled, no power sawing is done. But i use CFG80211_DEFAULT_PS=y on my
system too and didn't had this issue. Even power_save=on is working.
What else is different?
Ignacy, Is it RPi + TL-WN722NC?
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH 2/3] mwifiex: add basic 11h support for station
From: John W. Linville @ 2013-06-19 14:24 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Paul Stewart
In-Reply-To: <1371598618-26593-2-git-send-email-bzhao@marvell.com>
On Tue, Jun 18, 2013 at 04:36:57PM -0700, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> This patch adds code to parse requested AP's 11h capabilities
> and add 11h information in association request.
>
> Also, deauth is sent to the AP after receiving channel switch
> announcement event from firmware. This happens when AP advertises
> WLAN_EID_CHANNEL_SWITCH IE in it's beacon.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> Signed-off-by: Paul Stewart <pstew@chromium.org>
> ---
> drivers/net/wireless/mwifiex/sta_event.c | 7 +++
> diff --git a/drivers/net/wireless/mwifiex/sta_event.c b/drivers/net/wireless/mwifiex/sta_event.c
> index 41aafc7..0f7b4cf 100644
> --- a/drivers/net/wireless/mwifiex/sta_event.c
> +++ b/drivers/net/wireless/mwifiex/sta_event.c
> @@ -427,6 +427,13 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
>
> break;
>
> + case EVENT_CHANNEL_SWITCH_ANN:
> + dev_dbg(adapter->dev, "event: Channel Switch Announcement\n");
> + ret = mwifiex_send_cmd_async(priv,
> + HostCmd_CMD_802_11_DEAUTHENTICATE,
> + HostCmd_ACT_GEN_SET, 0,
> + priv->curr_bss_params.bss_descriptor.mac_address);
> +
> default:
> dev_dbg(adapter->dev, "event: unknown event id: %#x\n",
> eventcause);
Do you mean for this case to fall-through to the default case?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 1/6] wireless: Add memory usage debugging.
From: Johannes Berg @ 2013-06-19 14:27 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <51C1BE8D.4020307@candelatech.com>
On Wed, 2013-06-19 at 07:22 -0700, Ben Greear wrote:
> > I'm not really sure this is worth it -- you found the bug with
> > kmemleak() after all. Having very specific things for all of this
> > doesn't really seem worth it.
>
> kmemleak didn't show the bss leaking though, so I spent several days
> thinking ies pointers were being corrupted somehow. I think the code
> is not that intrusive, and since drivers also take bss refs, the problems
> could come back in the future.
Fair enough, I'll think about it some more. I don't think drivers are
really that much of a problem though.
> I didn't actually audit the drivers since I am not using that hardware,
> by the way.
Right.
> I started porting some patches to wireless-next yesterday..think that
> would be a good enough tree to patch against?
Probably OK, I only have few patches right now. I also just posted two
patches to address parts of this problem though, can you review those
too?
johannes
^ permalink raw reply
* Re: [PATCH 1/6] wireless: Add memory usage debugging.
From: Ben Greear @ 2013-06-19 14:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1371635381.8349.9.camel@jlt4.sipsolutions.net>
On 06/19/2013 02:49 AM, Johannes Berg wrote:
> On Tue, 2013-06-18 at 15:03 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> The bss objects are reference counted, and the ies
>> are also tricky to keep track of. Add option to
>> track allocation and freeing of the ies and bss objects,
>> and add debugfs files to show the current objects.
>
> I'm not really sure this is worth it -- you found the bug with
> kmemleak() after all. Having very specific things for all of this
> doesn't really seem worth it.
kmemleak didn't show the bss leaking though, so I spent several days
thinking ies pointers were being corrupted somehow. I think the code
is not that intrusive, and since drivers also take bss refs, the problems
could come back in the future.
I didn't actually audit the drivers since I am not using that hardware,
by the way.
> Either way though, I can't apply the patches since they won't apply. I
> realize that you're working on 3.9, but you're going to have to send me
> patches I can apply to one of my trees (and right now, not really
> mac80211 but mac80211-next)
I started porting some patches to wireless-next yesterday..think that
would be a good enough tree to patch against?
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] brcmfmac: Turn off ARP offloading when configured for AP.
From: Greg KH @ 2013-06-19 14:19 UTC (permalink / raw)
To: Arend van Spriel; +Cc: stable, linux-wireless, Hante Meuleman, John W. Linville
In-Reply-To: <51C15D4D.6040009@broadcom.com>
On Wed, Jun 19, 2013 at 09:27:09AM +0200, Arend van Spriel wrote:
> On 06/06/2013 10:55 AM, Arend van Spriel wrote:
> >From: Hante Meuleman <meuleman@broadcom.com>
>
> Hi Greg,
>
> I noticed your review announcement for v3.9.7 and did not see the
> change below. I sent it to stable because the original upstream
> commit did not apply. Did I miss some step in the process?
Ah, somehow I missed your patch, sorry about that, I do have it in my
mbox. What kernel tree(s) do you want it to be applied to? I'll pick
it up in my next round of releases.
thanks,
greg k-h
^ 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