* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Jamie Kitson @ 2011-01-24 13:08 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless@vger.kernel.org, Brett Rudley
In-Reply-To: <AANLkTinwPrar6ZBhSALBif8__4mHHsKuDYKsgr4FDqtu@mail.gmail.com>
>> This may not be supported by this driver.
>
> Ok, how would I find out for sure?
I got this from the irc channel:
[12:55] <johill> JamieKitson: it doesn't, at least arend said that a
couple of days ago
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Jamie Kitson @ 2011-01-24 12:45 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless@vger.kernel.org, Brett Rudley
In-Reply-To: <4D3B0390.5070108@broadcom.com>
> Rereading the whole thread I noticed the PREEMPT in your uname message. Does
> this mean you are running with CONFIG_PREEMPT (Preemptible Kernel)?
Apparently so. I'm using the stock Arch kernel.
> This may not be supported by this driver.
Ok, how would I find out for sure?
^ permalink raw reply
* Re: [RFC][PATCH] cfg80211: report monitor interface channel via wext when possible
From: Johannes Berg @ 2011-01-24 11:47 UTC (permalink / raw)
To: Paul Fertser; +Cc: linux-wireless, Thomas d'Otreppe, Richard Farina
In-Reply-To: <20110123094101.GB25136@home.lan>
On Sun, 2011-01-23 at 12:41 +0300, Paul Fertser wrote:
> On Sun, Jan 23, 2011 at 10:06:39AM +0100, Johannes Berg wrote:
> > On Sat, 2011-01-22 at 03:11 +0300, Paul Fertser wrote:
> > > This makes it possible to retrieve the channel for the monitor interface
> > > in cases when it can be determined unambigously. Tested with ath5k.
> >
> > NAK.
> >
> > http://article.gmane.org/gmane.linux.kernel.wireless.general/61860
>
> If i understood your correctly, "somehow query oper_channel" means one
> needs to extend cfg80211 API a little and add necessary code to
> mac80211. And the result would be higher-level API depending on
> mac80211 implementation details (which are going to be soon changed
> anyway after introduction of the real multi-channel feature).
Not necessarily -- that's exactly why you'd want such a callback: in the
case that mac80211 does get a multi-channel feature (and the feature is
currently in use) this callback would either return both/all channels
(which probably isn't very useful) or NULL to indicate that it doesn't
have a single fixed channel. In that case, the monitor interface would
still report an unknown channel -- which is really what's happening
anyway since other interfaces will be hopping around.
> What i propose should work with any cfg80211 driver where
> set_channel() is properly implemented for monitor interfaces, and
> mac80211 is certainly one of them. When in the first place one
> requests set_channel() for a monitor that's not compatible with the
> current configuration, it'll return an error, and so wdev->channel
> would not be set at all. If it succeeded and then someone later wants
> to verify the monitor channel, set_channel() is still the best
> opportunity because it is this function that has all the checks to
> verify the channel is still valid.
>
> To sum up, i see no drawbacks in using set_channel() for that, it
> doesn't add any implicit requirements, doesn't change semantics,
> non-intrusive, doesn't break anything and works correctly every time.
Yes, in some ways this makes sense, but I'm not convinced that
semantically we really want it. It really relies on returning an error
when the given channel cannot be assigned, which I guess we could, but
it just feels wrong. I can't really give a good reason for it other than
that.
However, also consider this case: If you have a monitor and IBSS
interface, the IBSS might -- rather infrequently -- hop channels. In
this case, it might make sense to still return the channel when the
monitor is queried, but you wouldn't be able to set it?
Also, say you did this:
- add monitor, set to channel 5
- add IBSS, create network on channel 1
- observe packets on monitor iface received on channel 1
- remove IBSS interface
- query monitor channel -- now suddenly with your approach
the channel is reset to 5, when it was quite obviously 1
in the time between
I think that'd be kinda confusing too.
johannes
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Johannes Berg @ 2011-01-24 11:41 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> Support passing SSID and probe-response template to drivers.
> This data can be used to offload the beacon -> probe-req -> probe-resp
> process to HW.
I still think you should add a wiphy flag and advertise it in nl80211 to
advertise and request this behaviour. That will allow hostapd (and
mac80211 in IBSS mode) to not reply to probe requests when they aren't
filtered out by the device, and will allow hostapd/wpa_s to also
restrict its operation to non-P2P etc. as Jouni pointed out. For P2P
then that will have to be extended more I guess, and the firmware
functionality be improved -- or even disabled.
johannes
^ permalink raw reply
* Re: [PATCH v2 4/6] mac80211: Save probe response data for BSS
From: Johannes Berg @ 2011-01-24 11:38 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295816579-28925-5-git-send-email-arik@wizery.com>
On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> +static int ieee80211_set_probe_resp(struct wiphy *wiphy,
> + struct net_device *dev, u8 *resp,
> + size_t resp_len)
> +{
> + struct ieee80211_sub_if_data *sdata;
> + struct sk_buff *new, *old;
> +
> + sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + old = sdata->u.ap.probe_resp;
> +
> + if (!resp || !resp_len)
> + return -EINVAL;
> +
> + new = dev_alloc_skb(resp_len);
> + if (!new) {
> + printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
> + "response template\n", sdata->name);
> + return -ENOMEM;
I'd remove that message -- userspace already knows, and it's the only
thing that really needs to?
> + }
> +
> + memcpy(skb_put(new, resp_len), resp, resp_len);
> +
> + rcu_assign_pointer(sdata->u.ap.probe_resp, new);
> + synchronize_rcu();
> +
> + if (old)
> + dev_kfree_skb(old);
Just a note -- I don't really expect you to implement this -- but I
think since the skb's CB is not used otherwise, we could easily use
call_rcu() to free it.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/6] nl80211: Pass probe response data to drivers
From: Johannes Berg @ 2011-01-24 11:35 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295816579-28925-3-git-send-email-arik@wizery.com>
On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> Allow usermode to pass probe-response data. This data can be used as a
> template probe-response offloading.
Why use a separate command for this, and not do it like the SSID? I also
was under the impression you wanted both (which is somewhat redundant
since you can parse the SSID out of the probe response), so shouldn't
they both be required (or none, for compatibility)?
Also, should cfg80211 pretend it knows the SSID/probe response when
userspace didn't set it (from the beacon) so that mac80211 or the
low-level drivers don't need to worry?
johannes
^ permalink raw reply
* Survey data inconsistencies between drivers
From: Helmut Schaa @ 2011-01-24 11:29 UTC (permalink / raw)
To: linux-wireless
Hi,
currently there are at least three different survey types implemented in
different mac80211 drivers.
- ath9k always lists the survey data for all channels and always provides
accumulated busy time data. This has the advantage that a simple scan
followed by a suvrey dump will give a nice overview of the different
channel utilization.
- ath5k only lists the active channel but also accumlates the busy time
statistics.
- rt2800 only lists the active channel and only returns relative busy time
values since the last read.
>From a hw perspective all three drivers appear similar, there are some
registers that are cleared on read and contain the busy times since the
last read.
I really like the ath9k approach but implementing it in every driver
sounds like a lot of redundancy.
In order to have consistent survey data between drivers I'd propose the
following approach:
- The driver's get_survey callback only returns relative survey data for the
currently active channel. That means reading the current busy time statistics
from the hw and clearing the appropriate counters.
- mac80211 would keep track of accumulating the gathered survey data.
- mac80211 would read the survey data before each channel change and update
the approriate channel's survey data just as ath9k does right now.
Any arguments against such a unification?
Thanks,
Helmut
^ permalink raw reply
* Re: [PATCH 1/1] CHROMIUM: config: bluetooth: rfkill driver
From: Johannes Berg @ 2011-01-24 11:27 UTC (permalink / raw)
To: aidapalapati; +Cc: olofj, linville, uraval, krakesh, linux-wireless
In-Reply-To: <1295867209-6156-1-git-send-email-aidapalapati@nvidia.com>
On Mon, 2011-01-24 at 16:36 +0530, aidapalapati@nvidia.com wrote:
> A new "rfkill" driver is added to control BT radio.
> A new kernel config variable CONFIG_BT_RFKILL needs to
> be configured to include this driver in the kernel.
>
> Three resources are expected by the driver.
> One Shutdown GPIO, One Reset Gpio and One reference Clock.
> if any/all of the resources can be defined by a platform.
If that's a generic driver, why can it use
> + tegra_gpio_enable(bt_rfkill->gpio_reset);
tegra_* functions?
johannes
^ permalink raw reply
* Re: [PATCH] RFC: ath: Fix WEP hardware encryption
From: Vasanthakumar Thiagarajan @ 2011-01-24 11:21 UTC (permalink / raw)
To: Bruno Randolf
Cc: Vasanth Thiagarajan, ath5k-devel@lists.ath5k.org, nbd@openwrt.org,
Sujith Manoharan, Luis Rodriguez, linux-wireless
In-Reply-To: <201101221130.25322.br1@einfach.org>
Adding linux-wireless in CC
On Sat, Jan 22, 2011 at 08:00:25AM +0530, Bruno Randolf wrote:
> On Saturday 22 January 2011 00:10:23 Vasanthakumar Thiagarajan wrote:
> > On Fri, Jan 21, 2011 at 03:46:08PM +0530, Bruno Randolf wrote:
> > > I need this to enable HW encryption for WEP.
> > > Otherwise we fall back to software decryption - i only checked the
> > > decryption case.
> >
> > Encryption/Decryption is done in hw by default. In which case are you
> > seeing it done in sw?.
>
> Sorry i was not very verbose in my description yesterday.
>
> I'm seeing the problem when i have an AP configured with WEP.
>
> The reason is that the index returned by the "reserve_keycache_entry" function
> (sorry i dont have the code here right now) is >= 4 (hw_key_index) while the
> key index in the packet header is 0-3. This is ok for transmit but received
> packets are not decrypted and therefore mac80211 has to decrypt it in SW -
> this can be easily seen by adding some debug prints in mac80211/wep.c. I have
> noticed it by watching the system CPU load under high traffic.
>
> bruno
>
> > > Any comments?
> > >
> > > bruno
> > > ---
> > >
> > > drivers/net/wireless/ath/key.c | 14 +++++++++++---
> > > 1 files changed, 11 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/key.c
> > > b/drivers/net/wireless/ath/key.c index 5d465e5..5748dae 100644
> > > --- a/drivers/net/wireless/ath/key.c
> > > +++ b/drivers/net/wireless/ath/key.c
> > > @@ -465,6 +465,16 @@ int ath_key_config(struct ath_common *common,
> > >
> > > hk.kv_len = key->keylen;
> > > memcpy(hk.kv_val, key->key, key->keylen);
> > >
> > > + /* set WEP keys directly to index */
> > > + if ((key->cipher == WLAN_CIPHER_SUITE_WEP40 ||
> > > + key->cipher == WLAN_CIPHER_SUITE_WEP104) && key->keyidx < 4) {
> > > + ret = ath_hw_set_keycache_entry(common, key->keyidx, &hk,
> NULL);
> > > + if (!ret)
> > > + return -EIO;
> > > + set_bit(key->keyidx, common->keymap);
> > > + return key->keyidx;
> > > + }
> > > +
> > >
> > > if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE)) {
> > >
> > > switch (vif->type) {
> > >
> > > case NL80211_IFTYPE_AP:
> > > @@ -541,10 +551,8 @@ EXPORT_SYMBOL(ath_key_config);
> > >
> > > void ath_key_delete(struct ath_common *common, struct ieee80211_key_conf
> > > *key) {
> > >
> > > ath_hw_keyreset(common, key->hw_key_idx);
> > >
> > > - if (key->hw_key_idx < IEEE80211_WEP_NKID)
> > > - return;
> > > -
> > >
> > > clear_bit(key->hw_key_idx, common->keymap);
> > >
> > > +
> > >
> > > if (key->cipher != WLAN_CIPHER_SUITE_TKIP)
> > >
> > > return;
^ permalink raw reply
* [PATCH 1/1] CHROMIUM: config: bluetooth: rfkill driver
From: aidapalapati @ 2011-01-24 11:06 UTC (permalink / raw)
To: olofj, linville, uraval, krakesh; +Cc: linux-wireless, Anantha Idapalapati
From: Anantha Idapalapati <aidapalapati@nvidia.com>
A new "rfkill" driver is added to control BT radio.
A new kernel config variable CONFIG_BT_RFKILL needs to
be configured to include this driver in the kernel.
Three resources are expected by the driver.
One Shutdown GPIO, One Reset Gpio and One reference Clock.
if any/all of the resources can be defined by a platform.
BUG=none
TEST= tested on board that used BCM4329 (ventana)
Change-Id: Ie893e2ba204197b82ec2c5339b830b05cb180170
Signed-off-by: Anantha Idapalapati <aidapalapati@nvidia.com>
Review URL:http://codereview.chromium.org/6295009/
---
drivers/misc/Kconfig | 8 ++
drivers/misc/Makefile | 1 +
drivers/misc/bt_rfkill.c | 194 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100755 drivers/misc/bt_rfkill.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b743312..c84ec51 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -390,6 +390,14 @@ config BMP085
To compile this driver as a module, choose M here: the
module will be called bmp085.
+config BT_RFKILL
+ bool "Bluetooth RFKILL driver"
+ depends on BT && RFKILL
+ help
+ If you say yes here you get support of a generic bluetooth RFKILL
+ driver for BT chipset. Platform needs to define the resources
+ required.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 42eab95..2621dff 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -34,4 +34,5 @@ obj-$(CONFIG_HMC6352) += hmc6352.o
obj-y += eeprom/
obj-y += cb710/
obj-$(CONFIG_VMWARE_BALLOON) += vmw_balloon.o
+obj-$(CONFIG_BT_RFKILL) += bt_rfkill.o
obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
diff --git a/drivers/misc/bt_rfkill.c b/drivers/misc/bt_rfkill.c
new file mode 100755
index 0000000..2d62882
--- /dev/null
+++ b/drivers/misc/bt_rfkill.c
@@ -0,0 +1,194 @@
+/*
+ * Copyright (c) 2010, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#include <linux/err.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
+#include <linux/fs.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/rfkill.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/slab.h>
+
+struct bt_rfkill_data {
+ int gpio_reset;
+ int gpio_shutdown;
+ int delay;
+ struct clk *bt_clk;
+};
+
+static struct bt_rfkill_data *bt_rfkill;
+
+static int bt_rfkill_set_power(void *data, bool blocked)
+{
+ if (blocked) {
+ if (bt_rfkill->gpio_shutdown)
+ gpio_direction_output(bt_rfkill->gpio_shutdown, 0);
+ if (bt_rfkill->gpio_reset)
+ gpio_direction_output(bt_rfkill->gpio_reset, 0);
+ if (bt_rfkill->bt_clk)
+ clk_disable(bt_rfkill->bt_clk);
+ } else {
+ if (bt_rfkill->bt_clk)
+ clk_enable(bt_rfkill->bt_clk);
+ if (bt_rfkill->gpio_shutdown)
+ gpio_direction_output(bt_rfkill->gpio_shutdown, 1);
+ if (bt_rfkill->gpio_reset)
+ gpio_direction_output(bt_rfkill->gpio_reset, 1);
+ }
+
+ return 0;
+}
+
+static const struct rfkill_ops bt_rfkill_ops = {
+ .set_block = bt_rfkill_set_power,
+};
+
+static int bt_rfkill_probe(struct platform_device *pdev)
+{
+ struct rfkill *bt_rfkill_dev;
+ struct resource *res;
+ int ret;
+ bool enable = false; /* off */
+ bool default_sw_block_state;
+
+ bt_rfkill = kzalloc(sizeof(*bt_rfkill), GFP_KERNEL);
+ if (!bt_rfkill)
+ return -ENOMEM;
+
+ bt_rfkill->bt_clk = clk_get(&pdev->dev, "bt_clk");
+ if (IS_ERR(bt_rfkill->bt_clk)) {
+ pr_warn("%s: can't find bt_clk.\
+ assuming clock to chip\n", __func__);
+ bt_rfkill->bt_clk = NULL;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_IO,
+ "bt_nreset_gpio");
+ if (res) {
+ bt_rfkill->gpio_reset = res->start;
+ tegra_gpio_enable(bt_rfkill->gpio_reset);
+ ret = gpio_request(bt_rfkill->gpio_reset,
+ "bt_nreset_gpio");
+ } else {
+ pr_warn("%s : can't find reset gpio.\n", __func__);
+ bt_rfkill->gpio_reset = 0;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_IO,
+ "bt_nshutdown_gpio");
+ if (res) {
+ bt_rfkill->gpio_shutdown = res->start;
+ tegra_gpio_enable(bt_rfkill->gpio_shutdown);
+ ret = gpio_request(bt_rfkill->gpio_shutdown,
+ "bt_nshutdown_gpio");
+ } else {
+ pr_warn("%s : can't find shutdown gpio.\n", __func__);
+ bt_rfkill->gpio_shutdown = 0;
+ }
+
+ /* make sure at-least one of the GPIO is defined */
+ if (!bt_rfkill->gpio_reset && !bt_rfkill->gpio_shutdown)
+ goto free_bcm_res;
+
+ if (bt_rfkill->bt_clk && enable)
+ clk_enable(bt_rfkill->bt_clk);
+ if (bt_rfkill->gpio_shutdown)
+ gpio_direction_output(bt_rfkill->gpio_shutdown, enable);
+ if (bt_rfkill->gpio_reset)
+ gpio_direction_output(bt_rfkill->gpio_reset, enable);
+
+ bt_rfkill_dev = rfkill_alloc("bt dev rfkill", &pdev->dev,
+ RFKILL_TYPE_BLUETOOTH, &bt_rfkill_ops,
+ NULL);
+
+ if (unlikely(!bt_rfkill_dev))
+ goto free_bcm_res;
+
+ default_sw_block_state = !enable;
+ rfkill_set_states(bt_rfkill_dev, default_sw_block_state, false);
+
+ ret = rfkill_register(bt_rfkill_dev);
+
+ if (unlikely(ret)) {
+ rfkill_destroy(bt_rfkill_dev);
+ goto free_bcm_res;
+ }
+
+ return 0;
+
+free_bcm_res:
+ if (bt_rfkill->gpio_shutdown)
+ gpio_free(bt_rfkill->gpio_shutdown);
+ if (bt_rfkill->gpio_reset)
+ gpio_free(bt_rfkill->gpio_reset);
+ if (bt_rfkill->bt_clk && enable)
+ clk_disable(bt_rfkill->bt_clk);
+ if (bt_rfkill->bt_clk)
+ clk_put(bt_rfkill->bt_clk);
+ kfree(bt_rfkill);
+ return -ENODEV;
+}
+
+static int bt_rfkill_remove(struct platform_device *pdev)
+{
+ struct rfkill *bt_rfkill_dev = platform_get_drvdata(pdev);
+
+ rfkill_unregister(bt_rfkill_dev);
+ rfkill_destroy(bt_rfkill_dev);
+ if (bt_rfkill->bt_clk)
+ clk_put(bt_rfkill->bt_clk);
+ if (bt_rfkill->gpio_shutdown)
+ gpio_free(bt_rfkill->gpio_shutdown);
+ if (bt_rfkill->gpio_reset)
+ gpio_free(bt_rfkill->gpio_reset);
+ kfree(bt_rfkill);
+
+ return 0;
+}
+
+static struct platform_driver bt_rfkill_driver = {
+ .probe = bt_rfkill_probe,
+ .remove = bt_rfkill_remove,
+ .driver = {
+ .name = "bt_rfkill",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init bt_rfkill_init(void)
+{
+ return platform_driver_register(&bt_rfkill_driver);
+}
+
+static void __exit bt_rfkill_exit(void)
+{
+ platform_driver_unregister(&bt_rfkill_driver);
+}
+
+module_init(bt_rfkill_init);
+module_exit(bt_rfkill_exit);
+
+MODULE_DESCRIPTION("bt rfkill");
+MODULE_AUTHOR("NVIDIA");
+MODULE_LICENSE("GPL");
--
1.7.3.5
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Jouni Malinen @ 2011-01-24 9:44 UTC (permalink / raw)
To: Arik Nemtsov
Cc: linux-wireless, Luciano Coelho, Johannes Berg, John W. Linville
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
On Sun, Jan 23, 2011 at 11:02:53PM +0200, Arik Nemtsov wrote:
> Support passing SSID and probe-response template to drivers.
> This data can be used to offload the beacon -> probe-req -> probe-resp
> process to HW.
What is the expected driver behavior for passing the SSID as a separate
attribute vs. passing the SSID as an IE within the Probe Response
template? Is the SSID-as-attr ever used to fill in a Probe Response by
the driver/firmware? Or is the driver/firmware only allowed to use the
full Probe Response template (with DA and timestamp updated)? It would
be useful to get this documented so that it is clear for people working
with both a driver and user space applications that could use the new
interface.
We should also document the need for special Probe Request processing
for WPS and P2P and have capability flags indicating whether the driver
needs the SSID and/or Probe Response template and whether it supports
various special rules for Probe Request processing (remove P2P IE from
Probe Response template if Probe Request does not include it, do not
reply to Probe Request if there is no match for Requested Device Type,
do not reply if there is no match for P2P Device Address). hostapd (or
wpa_supplicant AP mode) would then automatically disable use of P2P
and/or WPS if the driver/firmware does not have necessary capabilities
to implement this correctly.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Failed to stop TX DMA! is new
From: Mohammed Shafi @ 2011-01-24 8:39 UTC (permalink / raw)
To: James; +Cc: linux-wireless Mailing List
In-Reply-To: <4D3D3870.2090408@lockie.ca>
On Mon, Jan 24, 2011 at 1:59 PM, James <bjlockie@lockie.ca> wrote:
> I get few or no results when I do
> iwlist wlan1 scan with kernel 2.6.37
>
> I tried kernel-2.6.38-rc2
>
> ieee80211 phy0: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81
> mem=0xffffc900017a0000, irq=18
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA!
>
> I noticed those Failed to stop are new messages.
I think it was there for some time.
>
> kernel-2.6.36-2 works fine.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Failed to stop TX DMA! is new
From: James @ 2011-01-24 8:29 UTC (permalink / raw)
To: linux-wireless Mailing List
I get few or no results when I do
iwlist wlan1 scan with kernel 2.6.37
I tried kernel-2.6.38-rc2
ieee80211 phy0: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81
mem=0xffffc900017a0000, irq=18
ath: Failed to stop TX DMA in 100 msec after killing last frame
ath: Failed to stop TX DMA!
I noticed those Failed to stop are new messages.
kernel-2.6.36-2 works fine.
^ permalink raw reply
* Re: [RFC][PATCH] cfg80211: report monitor interface channel via wext when possible
From: Paul Fertser @ 2011-01-24 7:46 UTC (permalink / raw)
To: Bruno Randolf
Cc: Johannes Berg, linux-wireless, Thomas d'Otreppe,
Richard Farina, Maxim Levitsky
In-Reply-To: <201101241010.38393.br1@einfach.org>
On Mon, Jan 24, 2011 at 10:10:38AM +0900, Bruno Randolf wrote:
> On Sun January 23 2011 18:06:39 Johannes Berg wrote:
> > On Sat, 2011-01-22 at 03:11 +0300, Paul Fertser wrote:
> > > This makes it possible to retrieve the channel for the monitor interface
> > > in cases when it can be determined unambigously. Tested with ath5k.
> >
> > NAK.
> >
> > http://article.gmane.org/gmane.linux.kernel.wireless.general/61860
>
> > I don't think so -- I don't recall anyone ever asking before ;-)
>
> I definetly want this functionality for my WLAN monitoring tool ("horst" -
> http://br1.einfach.org/horst).
You took the quote out of the context :), Johannes meant that nobody
has asked him how exactly he would like to see this functionality
implemented, and the in the linked mail he outlines his proposal.
Johannes, i know you're a busy man (no kidding, i understand you're
doing serious work) and users should trust maintainers on their
technical decisions, but i hope you can still spare a minute to
explain me why my proposed way to use set_channel is wrong (as i'm yet
to see any drawbacks). Working with real professionals like you is a
great opportunity for me to learn and i appreciate it a lot.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
^ permalink raw reply
* [PATCHv4] wl12xx: Increase scan channel dwell time for passive scans
From: juuso.oikarinen @ 2011-01-24 6:01 UTC (permalink / raw)
To: coelho; +Cc: linux-wireless
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Below, mTU is milli-TU (TU/1000).
The passive scan channel dwell time currently used is 30-60mTU. A typical
beacon interval for AP's is 100TU. This leads to a ~30% worst-case probability
of finding an AP via passive scanning.
For 5GHz bands for DFS frequencies passive scanning is the only scanning
option. Hence for these, the probability of finding an AP is very low.
To fix this, increase the passive channel scan dwell times (also the early
leave value, as 5GHz channels are still typically very silent.) Use a value
of 100TU, because that covers most typical AP configurations.
Based on testing the probability of finding an AP (100TU beacon interval) on
a single scan round are as follows (based on 100 iterations):
dwell min/max (TU) | probability
---------------------+------------
30/60 | 35%
60/60 | 56%
80/80 | 77%
100/100 | 100%
Total scan times now and after the change:
Region | Before (s) | After (s)
-------+------------+----------
00 | 0.77 | 1.48
FI | 0.95 | 2.01
US | 0.91 | 1.76
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
v4: Whoops, wrong maintainer e-mail address :o
v3: In the commit log, changed references to "ms" to "TU"
v2: Minor comment change "maximum" => "minimum"
drivers/net/wireless/wl12xx/conf.h | 18 +++++++++---------
drivers/net/wireless/wl12xx/main.c | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/conf.h b/drivers/net/wireless/wl12xx/conf.h
index f5c048c..7aecbb5 100644
--- a/drivers/net/wireless/wl12xx/conf.h
+++ b/drivers/net/wireless/wl12xx/conf.h
@@ -1084,30 +1084,30 @@ struct conf_scan_settings {
/*
* The minimum time to wait on each channel for active scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 min_dwell_time_active;
+ u32 min_dwell_time_active;
/*
* The maximum time to wait on each channel for active scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 max_dwell_time_active;
+ u32 max_dwell_time_active;
/*
- * The maximum time to wait on each channel for passive scans
+ * The minimum time to wait on each channel for passive scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 min_dwell_time_passive;
+ u32 min_dwell_time_passive;
/*
* The maximum time to wait on each channel for passive scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 max_dwell_time_passive;
+ u32 max_dwell_time_passive;
/*
* Number of probe requests to transmit on each active scan channel
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 863e660..c1814f2 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -279,8 +279,8 @@ static struct conf_drv_settings default_conf = {
.scan = {
.min_dwell_time_active = 7500,
.max_dwell_time_active = 30000,
- .min_dwell_time_passive = 30000,
- .max_dwell_time_passive = 60000,
+ .min_dwell_time_passive = 100000,
+ .max_dwell_time_passive = 100000,
.num_probe_reqs = 2,
},
.rf = {
--
1.7.1
^ permalink raw reply related
* [PATCHv3] wl12xx: Increase scan channel dwell time for passive scans
From: juuso.oikarinen @ 2011-01-24 5:59 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Below, mTU is milli-TU (TU/1000).
The passive scan channel dwell time currently used is 30-60mTU. A typical
beacon interval for AP's is 100TU. This leads to a ~30% worst-case probability
of finding an AP via passive scanning.
For 5GHz bands for DFS frequencies passive scanning is the only scanning
option. Hence for these, the probability of finding an AP is very low.
To fix this, increase the passive channel scan dwell times (also the early
leave value, as 5GHz channels are still typically very silent.) Use a value
of 100TU, because that covers most typical AP configurations.
Based on testing the probability of finding an AP (100TU beacon interval) on
a single scan round are as follows (based on 100 iterations):
dwell min/max (TU) | probability
---------------------+------------
30/60 | 35%
60/60 | 56%
80/80 | 77%
100/100 | 100%
Total scan times now and after the change:
Region | Before (s) | After (s)
-------+------------+----------
00 | 0.77 | 1.48
FI | 0.95 | 2.01
US | 0.91 | 1.76
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
v3: In the commit log, changed references to "ms" to "TU"
v2: Minor comment change "maximum" => "minimum"
drivers/net/wireless/wl12xx/conf.h | 18 +++++++++---------
drivers/net/wireless/wl12xx/main.c | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/conf.h b/drivers/net/wireless/wl12xx/conf.h
index f5c048c..7aecbb5 100644
--- a/drivers/net/wireless/wl12xx/conf.h
+++ b/drivers/net/wireless/wl12xx/conf.h
@@ -1084,30 +1084,30 @@ struct conf_scan_settings {
/*
* The minimum time to wait on each channel for active scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 min_dwell_time_active;
+ u32 min_dwell_time_active;
/*
* The maximum time to wait on each channel for active scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 max_dwell_time_active;
+ u32 max_dwell_time_active;
/*
- * The maximum time to wait on each channel for passive scans
+ * The minimum time to wait on each channel for passive scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 min_dwell_time_passive;
+ u32 min_dwell_time_passive;
/*
* The maximum time to wait on each channel for passive scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 max_dwell_time_passive;
+ u32 max_dwell_time_passive;
/*
* Number of probe requests to transmit on each active scan channel
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 863e660..c1814f2 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -279,8 +279,8 @@ static struct conf_drv_settings default_conf = {
.scan = {
.min_dwell_time_active = 7500,
.max_dwell_time_active = 30000,
- .min_dwell_time_passive = 30000,
- .max_dwell_time_passive = 60000,
+ .min_dwell_time_passive = 100000,
+ .max_dwell_time_passive = 100000,
.num_probe_reqs = 2,
},
.rf = {
--
1.7.1
^ permalink raw reply related
* Re: [PATCHv2] wl12xx: Increase scan channel dwell time for passive scans
From: Juuso Oikarinen @ 2011-01-24 5:53 UTC (permalink / raw)
To: ext Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295616949.1925.118.camel@pimenta>
On Fri, 2011-01-21 at 15:35 +0200, ext Luciano Coelho wrote:
> Hi Juuso,
>
> Just a quick comment/question:
>
>
> On Tue, 2011-01-18 at 07:32 +0100, juuso.oikarinen@nokia.com wrote:
> > From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> >
> > The passive scan channel dwell time currently used is 30ms-60ms. A typical
> > beacon interval for AP's is 100ms. This leads to a ~30% worst-case probability
> > of finding an AP via passive scanning.
>
> The beacon intervals are defined in TUs.
>
>
> > For 5GHz bands for DFS frequencies passive scanning is the only scanning
> > option. Hence for these, the probability of finding an AP is very low.
> >
> > To fix this, increase the passive channel scan dwell times (also the early
> > leave value, as 5GHz channels are still typically very silent.) Use a value
> > of 100ms, because that covers most typical AP configurations.
>
> In the firmware API, the dwell times are expressed in milli-TUs. So I
> guess here you mean "use a value of 100 TUs", isn't it?
> > Based on testing the probability of finding an AP (102.4ms beacon interval) on
> > a single scan round are as follows (based on 100 iterations):
>
> Here you use milliseconds for the AP beacon interval. 102.4ms is 100
> TUs, so that's correct.
>
> It's just a bit confusing because of the slight difference between TUs
> and msecs. Gery was wondering why you were using 100ms if the most
> common beacon interval is 102.4ms (100 TUs). Of course, you're actually
> using 100 TUs, so it's fine.
>
> I just think it's easier to follow if you forget msecs and use only TUs
> in your explanation.
>
You're right. I'll convert the ms to mTU's in the description in v2.
This is a bit unclear to me too, though, because I don't know exactly
what the unit is we give the firmware. It's either TU/1024 or TU/1000.
Some reference I saw way back claimed it was plain TU's, which obviously
is not a possibility.
-Juuso
^ permalink raw reply
* Re: Question about rate control
From: Larry Finger @ 2011-01-24 5:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: wireless, chaoming_li
In-Reply-To: <4D3CF5E3.4060507@lwfinger.net>
On 01/23/2011 09:45 PM, Larry Finger wrote:
> I'm trying to use a special rate-control algorithm. ATM, this is necessary
> because I don't know how to get the retry info from the firmware. This setup
> worked fine with rtl8192ce using a fixed name compiled in the rate_control_ops
> struct. The problem is that this code is also used by a new USB driver named
> rtl8192cu that shares the rtlwifi module with the PCIe driver. When both are
> loaded, the second gets a duplicate name warhing. To fix this, I have set up
> code that generates a unique name, but it doesn't work. To help debug, I added a
> printk to dump the name used in every call to ieee80211_rate_control_register().
> The result of that printk is shown below. The 3rd value listed is my new one and
> all looks OK; however, the selected rate control is "minstrel_ht", not my
> special one.
>
> ops->name: minstrel
> ops->name: minstrel_ht
> --snip--
> ops->name: rtl-rc-0
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>
> Any thoughts on what might be wrong, or what values should be dumped for debugging?
I figured out my problem - I was not setting the rate_control_algorithm entry in
struct ieee80211_hw correctly. All is fine now.
Larry
^ permalink raw reply
* Question about rate control
From: Larry Finger @ 2011-01-24 3:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: wireless
I'm trying to use a special rate-control algorithm. ATM, this is necessary
because I don't know how to get the retry info from the firmware. This setup
worked fine with rtl8192ce using a fixed name compiled in the rate_control_ops
struct. The problem is that this code is also used by a new USB driver named
rtl8192cu that shares the rtlwifi module with the PCIe driver. When both are
loaded, the second gets a duplicate name warhing. To fix this, I have set up
code that generates a unique name, but it doesn't work. To help debug, I added a
printk to dump the name used in every call to ieee80211_rate_control_register().
The result of that printk is shown below. The 3rd value listed is my new one and
all looks OK; however, the selected rate control is "minstrel_ht", not my
special one.
ops->name: minstrel
ops->name: minstrel_ht
--snip--
ops->name: rtl-rc-0
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Any thoughts on what might be wrong, or what values should be dumped for debugging?
Thanks,
Larry
^ permalink raw reply
* Re: [RFC][PATCH] cfg80211: report monitor interface channel via wext when possible
From: Bruno Randolf @ 2011-01-24 1:10 UTC (permalink / raw)
To: Johannes Berg
Cc: Paul Fertser, linux-wireless, Thomas d'Otreppe,
Richard Farina, Maxim Levitsky
In-Reply-To: <1295773599.3639.4.camel@jlt3.sipsolutions.net>
On Sun January 23 2011 18:06:39 Johannes Berg wrote:
> On Sat, 2011-01-22 at 03:11 +0300, Paul Fertser wrote:
> > This makes it possible to retrieve the channel for the monitor interface
> > in cases when it can be determined unambigously. Tested with ath5k.
>
> NAK.
>
> http://article.gmane.org/gmane.linux.kernel.wireless.general/61860
> I don't think so -- I don't recall anyone ever asking before ;-)
I definetly want this functionality for my WLAN monitoring tool ("horst" -
http://br1.einfach.org/horst). A similar patch has also been discussed for
aircrack-ng in June 2010 (https://patchwork.kernel.org/patch/103589/).
I understand your point of not wanting to report wrong information, esp when
we have multiple interfaces on different channels - but in most situations for
sniffers etc this is not the case, we just have one monitor interface or one
interface + one monitor interface, in which cases I believe we should be able
to report a channel.
So just for the record: I want it, pretty please! :)
bruno
^ permalink raw reply
* [PATCH v2 6/6] wl12xx: configure probe-resp template according to notification
From: Arik Nemtsov @ 2011-01-23 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
When operating in AP-mode, replace probe-response template when a
notification is recieved from mac80211. We preserve the "legacy" way of
configuring a probe-response according to beacon for IBSS mode and for
versions of hostapd that do not support this feature.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/main.c | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 9076555..49d6160 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2041,6 +2041,25 @@ static int wl1271_ssid_set(struct wl1271 *wl, struct sk_buff *skb,
return -ENOENT;
}
+static int wl1271_ap_set_probe_resp_tmpl(struct wl1271 *wl, u32 rates)
+{
+ struct sk_buff *skb;
+ int ret;
+
+ skb = ieee80211_proberesp_get(wl->hw, wl->vif);
+ if (!skb)
+ return -EINVAL;
+
+ ret = wl1271_cmd_template_set(wl,
+ CMD_TEMPL_AP_PROBE_RESPONSE,
+ skb->data,
+ skb->len, 0,
+ rates);
+
+ dev_kfree_skb(skb);
+ return ret;
+}
+
static int wl1271_bss_erp_info_changed(struct wl1271 *wl,
struct ieee80211_bss_conf *bss_conf,
u32 changed)
@@ -2102,8 +2121,10 @@ static int wl1271_bss_beacon_info_changed(struct wl1271 *wl,
struct sk_buff *beacon = ieee80211_beacon_get(wl->hw, vif);
u16 tmpl_id;
- if (!beacon)
+ if (!beacon) {
+ ret = -EINVAL;
goto out;
+ }
wl1271_debug(DEBUG_MASTER, "beacon updated");
@@ -2139,7 +2160,16 @@ static int wl1271_bss_beacon_info_changed(struct wl1271 *wl,
goto out;
}
+ if ((changed & BSS_CHANGED_AP_PROBE_RESP) && is_ap) {
+ ret = wl1271_ap_set_probe_resp_tmpl(wl,
+ wl1271_tx_min_rate_get(wl));
+ if (ret < 0)
+ goto out;
+ }
+
out:
+ if (ret != 0)
+ wl1271_error("beacon info change failed: %d", ret);
return ret;
}
--
1.7.1
^ permalink raw reply related
* [PATCH v2 5/6] wl12xx: AP mode - support hidden SSID
From: Arik Nemtsov @ 2011-01-23 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
Detect whether our SSID is hidden by comparing beacon data with
the SSID in bss_conf.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/cmd.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index e28d9ca..7a6f39e 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -966,16 +966,6 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
wl1271_debug(DEBUG_CMD, "cmd start bss");
- /*
- * FIXME: We currently do not support hidden SSID. The real SSID
- * should be fetched from mac80211 first.
- */
- if (wl->ssid_len == 0) {
- wl1271_warning("Hidden SSID currently not supported for AP");
- ret = -EINVAL;
- goto out;
- }
-
cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
if (!cmd) {
ret = -ENOMEM;
@@ -993,9 +983,16 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
cmd->dtim_interval = bss_conf->dtim_period;
cmd->beacon_expiry = WL1271_AP_DEF_BEACON_EXP;
cmd->channel = wl->channel;
- cmd->ssid_len = wl->ssid_len;
- cmd->ssid_type = SSID_TYPE_PUBLIC;
- memcpy(cmd->ssid, wl->ssid, wl->ssid_len);
+
+ /* We use a visible SSID if the beacon SSID matches bss_conf */
+ if (wl->ssid_len > 0 && wl->ssid_len == bss_conf->ssid_len &&
+ !memcmp(wl->ssid, bss_conf->ssid, wl->ssid_len))
+ cmd->ssid_type = SSID_TYPE_PUBLIC;
+ else
+ cmd->ssid_type = SSID_TYPE_HIDDEN;
+
+ cmd->ssid_len = bss_conf->ssid_len;
+ memcpy(cmd->ssid, bss_conf->ssid, bss_conf->ssid_len);
switch (wl->band) {
case IEEE80211_BAND_2GHZ:
--
1.7.1
^ permalink raw reply related
* [PATCH v2 4/6] mac80211: Save probe response data for BSS
From: Arik Nemtsov @ 2011-01-23 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
Allow setting a probe response template for an interface operating in
AP mode. Low level drivers are notified about changes in the probe
response template and are able to retrieve a copy of the current probe
response. This data can, for example, be uploaded to hardware as a
template.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
include/net/mac80211.h | 15 +++++++++++++++
net/mac80211/cfg.c | 33 +++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/iface.c | 5 ++++-
net/mac80211/tx.c | 31 +++++++++++++++++++++++++++++++
net/mac80211/util.c | 3 ++-
6 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ff3bad1..55c48a1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -165,6 +165,7 @@ struct ieee80211_low_level_stats {
* that it is only ever disabled for station mode.
* @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
* @BSS_CHANGED_SSID: SSID changed for this BSS (AP mode)
+ * @BSS_CHANGED_AP_PROBE_RESP: Probe Response changed for this BSS (AP mode)
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -183,6 +184,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_QOS = 1<<13,
BSS_CHANGED_IDLE = 1<<14,
BSS_CHANGED_SSID = 1<<15,
+ BSS_CHANGED_AP_PROBE_RESP = 1<<16,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -2220,6 +2222,19 @@ static inline struct sk_buff *ieee80211_beacon_get(struct ieee80211_hw *hw,
}
/**
+ * ieee80211_proberesp_get - retrieve a Probe Response template
+ * @hw: pointer obtained from ieee80211_alloc_hw().
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ *
+ * Creates a Probe Response template which can, for example, be uploaded to
+ * hardware. The destination address should be set by the caller.
+ *
+ * Can only be called in AP mode.
+ */
+struct sk_buff *ieee80211_proberesp_get(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif);
+
+/**
* ieee80211_pspoll_get - retrieve a PS Poll template
* @hw: pointer obtained from ieee80211_alloc_hw().
* @vif: &struct ieee80211_vif pointer from the add_interface callback.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a2a75e9..834de52 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1944,6 +1944,38 @@ static int ieee80211_get_antenna(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant)
return drv_get_antenna(local, tx_ant, rx_ant);
}
+static int ieee80211_set_probe_resp(struct wiphy *wiphy,
+ struct net_device *dev, u8 *resp,
+ size_t resp_len)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct sk_buff *new, *old;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ old = sdata->u.ap.probe_resp;
+
+ if (!resp || !resp_len)
+ return -EINVAL;
+
+ new = dev_alloc_skb(resp_len);
+ if (!new) {
+ printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
+ "response template\n", sdata->name);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(new, resp_len), resp, resp_len);
+
+ rcu_assign_pointer(sdata->u.ap.probe_resp, new);
+ synchronize_rcu();
+
+ if (old)
+ dev_kfree_skb(old);
+
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_AP_PROBE_RESP);
+ return 0;
+}
+
struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -2001,4 +2033,5 @@ struct cfg80211_ops mac80211_config_ops = {
.mgmt_frame_register = ieee80211_mgmt_frame_register,
.set_antenna = ieee80211_set_antenna,
.get_antenna = ieee80211_get_antenna,
+ .set_probe_resp = ieee80211_set_probe_resp,
};
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..4513cc5 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -215,6 +215,7 @@ struct beacon_data {
struct ieee80211_if_ap {
struct beacon_data *beacon;
+ struct sk_buff *probe_resp;
struct list_head vlans;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 8acba45..7795778 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -449,15 +449,18 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
if (sdata->vif.type == NL80211_IFTYPE_AP) {
struct ieee80211_sub_if_data *vlan, *tmpsdata;
struct beacon_data *old_beacon = sdata->u.ap.beacon;
+ struct sk_buff *old_probe_resp = sdata->u.ap.probe_resp;
/* sdata_running will return false, so this will disable */
ieee80211_bss_info_change_notify(sdata,
BSS_CHANGED_BEACON_ENABLED);
- /* remove beacon */
+ /* remove beacon and probe response */
rcu_assign_pointer(sdata->u.ap.beacon, NULL);
+ rcu_assign_pointer(sdata->u.ap.probe_resp, NULL);
synchronize_rcu();
kfree(old_beacon);
+ kfree(old_probe_resp);
/* free all potentially still buffered bcast frames */
while ((skb = skb_dequeue(&sdata->u.ap.ps_bc_buf))) {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5950e3a..ef182c9 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2359,6 +2359,37 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_beacon_get_tim);
+struct sk_buff *ieee80211_proberesp_get(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif)
+{
+ struct ieee80211_if_ap *ap = NULL;
+ struct sk_buff *presp = NULL, *skb = NULL;
+ struct ieee80211_hdr *hdr;
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ return NULL;
+
+ rcu_read_lock();
+
+ ap = &sdata->u.ap;
+ presp = rcu_dereference(ap->probe_resp);
+ if (!presp)
+ goto out;
+
+ skb = skb_copy(presp, GFP_ATOMIC);
+ if (!skb)
+ goto out;
+
+ hdr = (struct ieee80211_hdr *) skb->data;
+ memset(hdr->addr1, 0, sizeof(hdr->addr1));
+
+out:
+ rcu_read_unlock();
+ return skb;
+}
+EXPORT_SYMBOL(ieee80211_proberesp_get);
+
struct sk_buff *ieee80211_pspoll_get(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index a2d2f73..59a7b61 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1213,7 +1213,8 @@ int ieee80211_reconfig(struct ieee80211_local *local)
ieee80211_bss_info_change_notify(sdata, changed);
break;
case NL80211_IFTYPE_AP:
- changed |= BSS_CHANGED_SSID |
+ changed |= BSS_CHANGED_AP_PROBE_RESP |
+ BSS_CHANGED_SSID |
BSS_CHANGED_BEACON |
BSS_CHANGED_BEACON_ENABLED;
ieee80211_bss_info_change_notify(sdata, changed);
--
1.7.1
^ permalink raw reply related
* [PATCH v2 3/6] mac80211: add SSID for AP mode with change notification
From: Arik Nemtsov @ 2011-01-23 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
When operating as AP, save SSID data as part of the ieee80211_bss_conf
struct. Allow low level drivers to receive notifications about SSID
changes.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
include/net/mac80211.h | 6 ++++++
net/mac80211/cfg.c | 7 +++++++
net/mac80211/util.c | 7 ++++++-
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 62c0ce2..ff3bad1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -164,6 +164,7 @@ struct ieee80211_low_level_stats {
* @BSS_CHANGED_QOS: QoS for this association was enabled/disabled. Note
* that it is only ever disabled for station mode.
* @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
+ * @BSS_CHANGED_SSID: SSID changed for this BSS (AP mode)
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -181,6 +182,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_ARP_FILTER = 1<<12,
BSS_CHANGED_QOS = 1<<13,
BSS_CHANGED_IDLE = 1<<14,
+ BSS_CHANGED_SSID = 1<<15,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -243,6 +245,8 @@ enum ieee80211_bss_change {
* @idle: This interface is idle. There's also a global idle flag in the
* hardware config which may be more appropriate depending on what
* your driver/device needs to do.
+ * @ssid_len: Length of @ssid in octets (in AP mode)
+ * @ssid: SSID for this BSS (in AP mode)
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -269,6 +273,8 @@ struct ieee80211_bss_conf {
bool arp_filter_enabled;
bool qos;
bool idle;
+ u8 ssid_len;
+ u8 ssid[IEEE80211_MAX_SSID_LEN];
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 4bc8a92..a2a75e9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1172,6 +1172,13 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_HT;
}
+ if (params->ssid_len > 0) {
+ memcpy(sdata->vif.bss_conf.ssid, params->ssid,
+ params->ssid_len);
+ sdata->vif.bss_conf.ssid_len = params->ssid_len;
+ changed |= BSS_CHANGED_SSID;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index cf68700..a2d2f73 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1212,10 +1212,15 @@ int ieee80211_reconfig(struct ieee80211_local *local)
changed |= BSS_CHANGED_ASSOC;
ieee80211_bss_info_change_notify(sdata, changed);
break;
+ case NL80211_IFTYPE_AP:
+ changed |= BSS_CHANGED_SSID |
+ BSS_CHANGED_BEACON |
+ BSS_CHANGED_BEACON_ENABLED;
+ ieee80211_bss_info_change_notify(sdata, changed);
+ break;
case NL80211_IFTYPE_ADHOC:
changed |= BSS_CHANGED_IBSS;
/* fall through */
- case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_MESH_POINT:
changed |= BSS_CHANGED_BEACON |
BSS_CHANGED_BEACON_ENABLED;
--
1.7.1
^ permalink raw reply related
* [PATCH v2 2/6] nl80211: Pass probe response data to drivers
From: Arik Nemtsov @ 2011-01-23 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295816579-28925-1-git-send-email-arik@wizery.com>
Allow usermode to pass probe-response data. This data can be used as a
template probe-response offloading.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
include/linux/nl80211.h | 9 +++++++++
include/net/cfg80211.h | 3 +++
net/wireless/nl80211.c | 32 ++++++++++++++++++++++++++++++++
3 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 821ffb9..ba19c4b 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -410,6 +410,9 @@
* notification. This event is used to indicate that an unprotected
* disassociation frame was dropped when MFP is in use.
*
+ * @NL80211_CMD_SET_PROBE_RESP: Set a Probe Response template to an access
+ * point interface
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -522,6 +525,8 @@ enum nl80211_commands {
NL80211_CMD_UNPROT_DEAUTHENTICATE,
NL80211_CMD_UNPROT_DISASSOCIATE,
+ NL80211_CMD_SET_PROBE_RESP,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -887,6 +892,8 @@ enum nl80211_commands {
* @NL80211_ATTR_MESH_CONFIG: Mesh configuration parameters, a nested attribute
* containing attributes from &enum nl80211_meshconf_params.
*
+ * @NL80211_ATTR_PROBE_RESP: Probe Response template data
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1074,6 +1081,8 @@ enum nl80211_attrs {
NL80211_ATTR_WIPHY_ANTENNA_AVAIL_TX,
NL80211_ATTR_WIPHY_ANTENNA_AVAIL_RX,
+ NL80211_ATTR_PROBE_RESP,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 03b1b0c..8b3f427 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1366,6 +1366,9 @@ struct cfg80211_ops {
int (*set_antenna)(struct wiphy *wiphy, u32 tx_ant, u32 rx_ant);
int (*get_antenna)(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant);
+
+ int (*set_probe_resp)(struct wiphy *wiphy, struct net_device *dev,
+ u8 *resp, size_t resp_len);
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ce5453d..50151a2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -172,6 +172,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_MCAST_RATE] = { .type = NLA_U32 },
[NL80211_ATTR_OFFCHANNEL_TX_OK] = { .type = NLA_FLAG },
[NL80211_ATTR_KEY_DEFAULT_TYPES] = { .type = NLA_NESTED },
+ [NL80211_ATTR_PROBE_RESP] = { .type = NLA_BINARY,
+ .len = IEEE80211_MAX_DATA_LEN },
};
/* policy for the key attributes */
@@ -1917,6 +1919,28 @@ static int nl80211_del_beacon(struct sk_buff *skb, struct genl_info *info)
return rdev->ops->del_beacon(&rdev->wiphy, dev);
}
+static int nl80211_set_probe_resp(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ u8 *resp;
+ size_t resp_len;
+
+ if (!rdev->ops->set_probe_resp)
+ return -EOPNOTSUPP;
+
+ if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP)
+ return -EOPNOTSUPP;
+
+ if (!info->attrs[NL80211_ATTR_PROBE_RESP])
+ return -EINVAL;
+
+ resp = nla_data(info->attrs[NL80211_ATTR_PROBE_RESP]);
+ resp_len = nla_len(info->attrs[NL80211_ATTR_PROBE_RESP]);
+
+ return rdev->ops->set_probe_resp(&rdev->wiphy, dev, resp, resp_len);
+}
+
static const struct nla_policy sta_flags_policy[NL80211_STA_FLAG_MAX + 1] = {
[NL80211_STA_FLAG_AUTHORIZED] = { .type = NLA_FLAG },
[NL80211_STA_FLAG_SHORT_PREAMBLE] = { .type = NLA_FLAG },
@@ -5266,6 +5290,14 @@ static struct genl_ops nl80211_ops[] = {
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
+ {
+ .cmd = NL80211_CMD_SET_PROBE_RESP,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .doit = nl80211_set_probe_resp,
+ .internal_flags = NL80211_FLAG_NEED_NETDEV |
+ NL80211_FLAG_NEED_RTNL,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox