* [PATCH mac80211-next] brcm80211: fix null pointer access
From: Antonio Quartulli @ 2013-06-19 11:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
From: Antonio Quartulli <antonio@open-mesh.com>
Do not unconditionally access the chan variable in
brcmf_cfg80211_mgmt_tx() as it may be NULL.
Use freq instead.
Introduced by c2ff8cad64233b539c71a27e2a6e324001143ef0
("brcm80211: make mgmt_tx in brcmfmac accept a NULL channel")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 8bd256b..d316d62 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -3985,8 +3985,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
le16_to_cpu(action_frame->len));
brcmf_dbg(TRACE, "Action frame, cookie=%lld, len=%d, freq=%d\n",
- *cookie, le16_to_cpu(action_frame->len),
- chan->center_freq);
+ *cookie, le16_to_cpu(action_frame->len), freq);
ack = brcmf_p2p_send_action_frame(cfg, cfg_to_ndev(cfg),
af_params);
--
1.8.1.5
^ permalink raw reply related
* Re: mac80211: impact of netif_carrier_off during roaming
From: Dan Williams @ 2013-06-19 13:06 UTC (permalink / raw)
To: m.fitzjohn; +Cc: linux-wireless
In-Reply-To: <004401ce6ccf$5b69e620$123db260$%fitzjohn@samsung.com>
On Wed, 2013-06-19 at 10:28 +0100, Mark Fitzjohn wrote:
> Hi
>
> I've noticed that during roaming triggered by detection of a significantly
> better AP in wpa_supplicant that mac80211 calls netif_carrier_off and then
> netif_carrier_on when associated with the new AP.
>
> Does this have any detrimental impact on applications using the wifi
> connection or is the assumption that as long as the roam happens in a
> reasonable time then applications should tolerate it?
>
> Just wondering if signalling the netif_carrier_off only when the current AP
> is lost and there is no immediate alternative AP for the network available
> was considered?
Carrier is more "can I send data the other side is expected to receive",
and that's what it's doing in mac80211. If you're roaming but not yet
associated to the new AP, you can't send any data, thus carrier is down.
Carrier for Wi-Fi is simply more complicated than ethernet because Wi-Fi
is more complicated. The current approach provides a good notification
of L2 connectivity, which maps well to the existing Ethernet semantics
and how stuff like DHCP works if it wants to renew addresses. Something
needs to provide this and carrier does that in a consistent way.
What you're probably looking for is indications of
connection/disconnection from an SSID, which is provided by
mac80211/cfg80211 and wpa_supplicant.
Dan
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Stanislaw Gruszka @ 2013-06-19 13:09 UTC (permalink / raw)
To: Johannes Berg
Cc: Eric Dumazet, Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1371575087.22256.2.camel@jlt4.sipsolutions.net>
On Tue, Jun 18, 2013 at 07:04:47PM +0200, Johannes Berg wrote:
> On Tue, 2013-06-18 at 09:52 -0700, Eric Dumazet wrote:
>
> > > We'll be submitting a patch to make single pages default.
> >
> > Do you think the same change would be possible for
> > drivers/net/wireless/iwlegacy/4965-mac.c ?
>
> Yes, Stanislaw?
Yes, I'll post 4965 patch.
Thanks
Stanislaw
^ permalink raw reply
* RE: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Berg, Johannes @ 2013-06-19 13:08 UTC (permalink / raw)
To: Oleksij Rempel, Ignacy Gawedzki, ath9k-devel@lists.ath9k.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <51C1ACEC.2020703@rempel-privat.de>
IA0KPiAgICAgIG1hYzgwMjExOiBmaXggaWRsZSBoYW5kbGluZyBzZXF1ZW5jZQ0KPiANCj4gICAg
ICBDb3JleSBSaWNoYXJkc29uIHJlcG9ydGVkIHRoYXQgbXkgaWRsZSBoYW5kbGluZyBjbGVhbnVw
DQo+ICAgICAgKGNvbW1pdCBmZDBmOTc5YTFiLCAibWFjODAyMTE6IHNpbXBsaWZ5IGlkbGUgaGFu
ZGxpbmciKQ0KPiAgICAgIGJyb2tlIGF0aDlrX2h0Yy4gVGhlIHJlYXNvbiBhcHBlYXJzIHRvIGJl
IHRoYXQgaXQgd2FudHMNCj4gICAgICB0byBnbyBvdXQgb2YgaWRsZSBiZWZvcmUgc3dpdGNoaW5n
IGNoYW5uZWxzLiBUbyBmaXggaXQsDQo+ICAgICAgcmVpbXBsZW1lbnQgdGhhdCBzZXF1ZW5jZS4N
Cj4gDQo+ICAgICAgUmVwb3J0ZWQtYnk6IENvcmV5IFJpY2hhcmRzb24gPGNvcmV5QG9jdGF5bi5u
ZXQ+DQo+ICAgICAgU2lnbmVkLW9mZi1ieTogSm9oYW5uZXMgQmVyZyA8am9oYW5uZXMuYmVyZ0Bp
bnRlbC5jb20+DQo+IA0KPiBKb2hhbm5lcywgY2FuIHlvdSBwbGVhc2UgdGFrZSBhIGxvb2sgb24g
aXQuDQoNCk5vdCB2ZXJ5IHdlbGwsIEkgZG9uJ3Qga25vdyBhbnl0aGluZyBhYm91dCBhdGg5ay4g
SSdtIHdpbGxpbmcgdG8gaGVscCBvdXQsIGJ1dCBJIGNhbid0IHJlYWxseSBzYXkgd2hhdCBicm9r
ZSBpdC4NCg0Kam9oYW5uZXMNCg0KSW50ZWwgR21iSApEb3JuYWNoZXIgU3RyYXNzZSAxCjg1NjIy
IEZlbGRraXJjaGVuL011ZW5jaGVuLCBEZXV0c2NobGFuZApTaXR6IGRlciBHZXNlbGxzY2hhZnQ6
IEZlbGRraXJjaGVuIGJlaSBNdWVuY2hlbgpHZXNjaGFlZnRzZnVlaHJlcjogQ2hyaXN0aWFuIExh
bXByZWNodGVyLCBIYW5uZXMgU2Nod2FkZXJlciwgRG91Z2xhcyBMdXNrClJlZ2lzdGVyZ2VyaWNo
dDogTXVlbmNoZW4gSFJCIDQ3NDU2ClVzdC4tSWROci4vVkFUIFJlZ2lzdHJhdGlvbiBOby46IERF
MTI5Mzg1ODk1CkNpdGliYW5rIEZyYW5rZnVydCBhLk0uIChCTFogNTAyIDEwOSAwMCkgNjAwMTE5
MDUyCg==
^ permalink raw reply
* Re: bug-report: Ralink corp. Device [1814:539a] - Kernel 3.8 +
From: Stanislaw Gruszka @ 2013-06-19 13:12 UTC (permalink / raw)
To: Lars Zastrow; +Cc: backports, linux-wireless
In-Reply-To: <51BE8008.20302@gmx.de>
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
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 13:38 UTC (permalink / raw)
To: Berg, Johannes
Cc: Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1DC40B07CD6EC041A66726C271A73AE61AA312F5@IRSMSX102.ger.corp.intel.com>
Am 19.06.2013 15:08, schrieb Berg, Johannes:
>
>> mac80211: fix idle handling sequence
>>
>> Corey Richardson reported that my idle handling cleanup
>> (commit fd0f979a1b, "mac80211: simplify idle handling")
>> broke ath9k_htc. The reason appears to be that it wants
>> to go out of idle before switching channels. To fix it,
>> reimplement that sequence.
>>
>> Reported-by: Corey Richardson <corey@octayn.net>
>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>>
>> Johannes, can you please take a look on it.
>
> Not very well, I don't know anything about ath9k. I'm willing to help out, but I can't really say what broke it.
hm.. looks like this code depends on power_save. is it correct?
Ignacy,
can you please take a look if power_save mode is enabled by you.
iw dev wlan0 get power_save
if yes. Try to disable it.
I think last week power_save was set to disabled by default. There are
too many bugs right now.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: Sergei Shtylyov @ 2013-06-19 13:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Torvalds, David Miller, John Linville, Linux Wireless List,
Network Development
In-Reply-To: <1371630238.8349.6.camel@jlt4.sipsolutions.net>
Hello.
On 19-06-2013 12:23, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
> Since my commit 3713b4e364, nl80211_dump_wiphy() uses the global
Please also specify that commit's summary line in parens.
> 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.
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
WBR, Sergei
^ permalink raw reply
* [PATCH 2/2] cfg80211: hold BSS over association process
From: Johannes Berg @ 2013-06-19 13:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1371650017-14293-1-git-send-email-johannes@sipsolutions.net>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/mlme.c | 4 ++++
net/wireless/sme.c | 15 ++++++++++-----
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index dd6f79d..bfac5e1 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -38,6 +38,7 @@ void cfg80211_rx_assoc_resp(struct net_device *dev, struct cfg80211_bss *bss,
* frame instead of reassoc.
*/
if (cfg80211_sme_rx_assoc_resp(wdev, status_code)) {
+ cfg80211_unhold_bss(bss_from_pub(bss));
cfg80211_put_bss(wiphy, bss);
return;
}
@@ -142,6 +143,7 @@ void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss)
nl80211_send_assoc_timeout(rdev, dev, bss->bssid, GFP_KERNEL);
cfg80211_sme_assoc_timeout(wdev);
+ cfg80211_unhold_bss(bss_from_pub(bss));
cfg80211_put_bss(wiphy, bss);
}
EXPORT_SYMBOL(cfg80211_assoc_timeout);
@@ -309,6 +311,8 @@ int cfg80211_mlme_assoc(struct cfg80211_registered_device *rdev,
goto out;
err = rdev_assoc(rdev, dev, req);
+ if (!err)
+ cfg80211_hold_bss(bss_from_pub(req->bss));
out:
if (err)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index ae7e2cb..c0bf781 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -615,19 +615,24 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
kfree(wdev->connect_keys);
wdev->connect_keys = NULL;
wdev->ssid_len = 0;
- cfg80211_put_bss(wdev->wiphy, bss);
+ if (bss) {
+ cfg80211_unhold_bss(bss_from_pub(bss));
+ cfg80211_put_bss(wdev->wiphy, bss);
+ }
return;
}
- if (!bss)
+ if (!bss) {
+ WARN_ON_ONCE(!wiphy_to_dev(wdev->wiphy)->ops->connect);
bss = cfg80211_get_bss(wdev->wiphy, NULL, bssid,
wdev->ssid, wdev->ssid_len,
WLAN_CAPABILITY_ESS,
WLAN_CAPABILITY_ESS);
- if (WARN_ON(!bss))
- return;
+ if (WARN_ON(!bss))
+ return;
+ cfg80211_hold_bss(bss_from_pub(bss));
+ }
- cfg80211_hold_bss(bss_from_pub(bss));
wdev->current_bss = bss_from_pub(bss);
cfg80211_upload_connect_keys(wdev);
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] cfg80211: require passing BSS struct back to cfg80211_assoc_timeout
From: Johannes Berg @ 2013-06-19 13:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 16 ++++++++--------
net/mac80211/mlme.c | 15 +++++++--------
net/wireless/mlme.c | 8 +++++---
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e3a39fc..7b0730a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1459,7 +1459,8 @@ const u8 *ieee80211_bss_get_ie(struct cfg80211_bss *bss, u8 ie);
* This structure provides information needed to complete IEEE 802.11
* authentication.
*
- * @bss: The BSS to authenticate with.
+ * @bss: The BSS to authenticate with, the callee must obtain a reference
+ * to it if it needs to keep it.
* @auth_type: Authentication type (algorithm)
* @ie: Extra IEs to add to Authentication frame or %NULL
* @ie_len: Length of ie buffer in octets
@@ -1497,11 +1498,10 @@ enum cfg80211_assoc_req_flags {
*
* This structure provides information needed to complete IEEE 802.11
* (re)association.
- * @bss: The BSS to associate with. If the call is successful the driver
- * is given a reference that it must release, normally via a call to
- * cfg80211_send_rx_assoc(), or, if association timed out, with a
- * call to cfg80211_put_bss() (in addition to calling
- * cfg80211_send_assoc_timeout())
+ * @bss: The BSS to associate with. If the call is successful the driver is
+ * given a reference that it must give back to cfg80211_send_rx_assoc()
+ * or to cfg80211_assoc_timeout(). To ensure proper refcounting, new
+ * association requests while already associating must be rejected.
* @ie: Extra IEs to add to (Re)Association Request frame or %NULL
* @ie_len: Length of ie buffer in octets
* @use_mfp: Use management frame protection (IEEE 802.11w) in this association
@@ -3522,11 +3522,11 @@ void cfg80211_rx_assoc_resp(struct net_device *dev,
/**
* cfg80211_assoc_timeout - notification of timed out association
* @dev: network device
- * @addr: The MAC address of the device with which the association timed out
+ * @bss: The BSS entry with which association timed out.
*
* This function may sleep. The caller must hold the corresponding wdev's mutex.
*/
-void cfg80211_assoc_timeout(struct net_device *dev, const u8 *addr);
+void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss);
/**
* cfg80211_tx_mlme_mgmt - notification of transmitted deauth/disassoc frame
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index e0939eb..08b3e71 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2722,8 +2722,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
if (!ieee80211_assoc_success(sdata, bss, mgmt, len)) {
/* oops -- internal error -- send timeout for now */
ieee80211_destroy_assoc_data(sdata, false);
- cfg80211_put_bss(sdata->local->hw.wiphy, bss);
- cfg80211_assoc_timeout(sdata->dev, mgmt->bssid);
+ cfg80211_assoc_timeout(sdata->dev, bss);
return;
}
sdata_info(sdata, "associated\n");
@@ -3440,13 +3439,10 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
time_after(jiffies, ifmgd->assoc_data->timeout)) {
if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
ieee80211_do_assoc(sdata)) {
- u8 bssid[ETH_ALEN];
-
- memcpy(bssid, ifmgd->assoc_data->bss->bssid, ETH_ALEN);
+ struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
ieee80211_destroy_assoc_data(sdata, false);
-
- cfg80211_assoc_timeout(sdata->dev, bssid);
+ cfg80211_assoc_timeout(sdata->dev, bss);
}
} else if (ifmgd->assoc_data && ifmgd->assoc_data->timeout_started)
run_again(sdata, ifmgd->assoc_data->timeout);
@@ -4372,8 +4368,11 @@ void ieee80211_mgd_stop(struct ieee80211_sub_if_data *sdata)
cancel_work_sync(&ifmgd->chswitch_work);
sdata_lock(sdata);
- if (ifmgd->assoc_data)
+ if (ifmgd->assoc_data) {
+ struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
ieee80211_destroy_assoc_data(sdata, false);
+ cfg80211_assoc_timeout(sdata->dev, bss);
+ }
if (ifmgd->auth_data)
ieee80211_destroy_auth_data(sdata, false);
del_timer_sync(&ifmgd->timer);
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index a61a44b..dd6f79d 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -131,16 +131,18 @@ void cfg80211_auth_timeout(struct net_device *dev, const u8 *addr)
}
EXPORT_SYMBOL(cfg80211_auth_timeout);
-void cfg80211_assoc_timeout(struct net_device *dev, const u8 *addr)
+void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct wiphy *wiphy = wdev->wiphy;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
- trace_cfg80211_send_assoc_timeout(dev, addr);
+ trace_cfg80211_send_assoc_timeout(dev, bss->bssid);
- nl80211_send_assoc_timeout(rdev, dev, addr, GFP_KERNEL);
+ nl80211_send_assoc_timeout(rdev, dev, bss->bssid, GFP_KERNEL);
cfg80211_sme_assoc_timeout(wdev);
+
+ cfg80211_put_bss(wiphy, bss);
}
EXPORT_SYMBOL(cfg80211_assoc_timeout);
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] nl80211: fix attrbuf access race by allocating a separate one
From: John W. Linville @ 2013-06-19 13:51 UTC (permalink / raw)
To: David Miller; +Cc: johannes, torvalds, linux-wireless, netdev
In-Reply-To: <20130619.013900.786603036908799505.davem@davemloft.net>
On Wed, Jun 19, 2013 at 01:39:00AM -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 19 Jun 2013 10:23:58 +0200
>
> > 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.
> >
> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>
> Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: John W. Linville <linville@tuxdriver.com>
--
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: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 14:09 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Berg, Johannes, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <51C1B467.1030509@rempel-privat.de>
On Wed, Jun 19, 2013 at 03:38:47PM +0200, thus spake Oleksij Rempel:
> hm.. looks like this code depends on power_save. is it correct?
>
> Ignacy,
>
> can you please take a look if power_save mode is enabled by you.
>
> iw dev wlan0 get power_save
>
> if yes. Try to disable it.
Although I have been building with CFG80211_DEFAULT_PS=y, the iw get
power_save command tells me it's off.
> I think last week power_save was set to disabled by default. There
> are too many bugs right now.
I'll test without CFG80211_DEFAULT_PS, just to be sure.
Thanks for the hint.
--
NO CARRIER
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Johannes Berg @ 2013-06-19 14:11 UTC (permalink / raw)
To: Ignacy Gawedzki
Cc: Oleksij Rempel, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20130619140905.GA14079@zenon.in.qult.net>
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
^ permalink raw reply
* Re: [RFC 2/2] mac80211: Fix bss ref leak.
From: Johannes Berg @ 2013-06-19 14:13 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <51C08BF3.7050706@candelatech.com>
On Tue, 2013-06-18 at 09:33 -0700, Ben Greear wrote:
> On 06/18/2013 08:26 AM, Johannes Berg wrote:
> > On Mon, 2013-06-17 at 14:32 -0700, greearb@candelatech.com wrote:
> >
> >> static void ieee80211_destroy_assoc_data(struct ieee80211_sub_if_data *sdata,
> >> - bool assoc)
> >> + bool assoc, bool put_bss)
> >
> > Do we _really_ need another argument? Shouldn't it always be put in the
> > non-assoc case anyway, at least if non-NULL?
>
> I don't think so. Check out the ieee80211_rx_mgmt_assoc_resp method.
>
> if (status_code != WLAN_STATUS_SUCCESS) {
> sdata_info(sdata, "%pM denied association (code=%d)\n",
> mgmt->sa, status_code);
> ieee80211_destroy_assoc_data(sdata, false, false);
>
> This passes in false as 'assoc', but we should not free bss here because
> it is being passed back to the calling method, and the return
> code of RX_MGMT_CFG80211_RX_ASSOC means bss should eventually
> be consumed by the cfg80211 logic.
>
> Of course, this is all 'as far as I can tell'.
>
> I sort of like the second boolean because it forces the caller to
> think about whether bss should be freed or not...
I just posted a patch to hand it back and never free it in mac80211 at
all, that also allows cfg80211_hold_bss() it across the assoc process
which fixes a (possibly more theoretical) expiry issue.
johannes
^ 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
* 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 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 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: [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: [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
* [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: [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
* 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
* [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 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
* 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
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