* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Maxim Levitsky @ 2009-07-31 7:08 UTC (permalink / raw)
To: Reinette Chatre; +Cc: johannes, linville, linux-wireless
In-Reply-To: <1248903159-17024-1-git-send-email-reinette.chatre@intel.com>
On Wed, 2009-07-29 at 14:32 -0700, Reinette Chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> The connection monitor currently relies on probe requests paired
> with probe responses to ensure that a connection is alive. This is
> fragile in some environments where probe responses can get lost.
> When we receive beacons we can also consider the connection to be
> alive, so cancel connection poll instance when we receive a beacon.
>
> The debug message "cancelling probereq poll due to a received beacon"
> is removed as part of this change as this case is hit very often after
> the above change and debug log receives significant number of these messages.
In my opinion this is the correct solution
I did plenty of wireless monitoring, and I see that nobody sends probe
requests at that rate (1 per second it seems). This is ridiculous.
According to the monitor on my iwl3945, (which might though be
incorrect), sometimes AP doesn't respond in time, but then later it
sends a storm (about 5 or so) probe responses at once (after the deauth)
I think that while wireless is fast most AP aren't, (mine is 150 Mhz
mips system for example), thus it can delay the response for more that
200 ms.
I think that the right solution is to send probes every minute or so,
and retry at last few times, before concluding that connection is lost.
(and if beacons are lost for a prolonged period it might make a sense to
send a probe earlier)
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH 1/2] at76c50x-usb: remove unneeded flush_workqueue() at usb disconnect
From: Kalle Valo @ 2009-07-31 6:24 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1248902442-14621-1-git-send-email-lrodriguez@atheros.com>
"Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
> This driver only uses the mac80211 workqueue and mac80211 requires us to
> cancel all work at driver stop. Since we now have the cancels in the right
> places at stop() we really don't need to flush the mac80211 workqueue so
> remove it.
>
> Cc: Kalle Valo <kalle.valo@iki.fi>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: Kalle Valo <kalle.valo@iki.fi>
But I only saw patch 1/2, was there also 2/2?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: remove usage of orig_flags
From: reinette chatre @ 2009-07-31 5:46 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1249004247-20780-1-git-send-email-lrodriguez@atheros.com>
On Thu, 2009-07-30 at 18:37 -0700, Luis R. Rodriguez wrote:
> This is a private flag, internal to cfg80211. cfg80211
> will set orig_* stuff internally upon wiphy registration,
> drivers do not need to muck with it.
>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Thank you
Reinette
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-07-29
From: David Miller @ 2009-07-31 2:30 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090729205423.GC10056@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 29 Jul 2009 16:54:23 -0400
> Here is another batch of wireless bits intended for 2.6.32... Once
> again, there is no particular theme to the bunch. This does cover the
> usual round of driver updates for iwlwifi, ath9k, and others. There are
> also some mac80211 and cfg80211 updates, including the final piece for
> cfg80211 to supplant wireless extensions -- hooray!
...
> P.S. There is a merge-test branch that contains sample merge conflict
> resolutions. They are mostly simple.
Pulled this in after doing a merge. Will push out after some
build checks.
Thanks!
^ permalink raw reply
* [PATCH] dell-laptop: Fix rfkill state queries
From: Matthew Garrett @ 2009-07-31 2:25 UTC (permalink / raw)
To: linux-acpi; +Cc: johannes, linux-wireless, timg, Matthew Garrett
The current code in dell-laptop is confused about the hardware rfkill
state. Fix it up such that it's always reported correctly.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
drivers/platform/x86/dell-laptop.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index 74909c4..9061111 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -197,8 +197,8 @@ static void dell_rfkill_query(struct rfkill *rfkill, void *data)
dell_send_request(&buffer, 17, 11);
status = buffer.output[1];
- if (status & BIT(bit))
- rfkill_set_hw_state(rfkill, !!(status & BIT(16)));
+ rfkill_set_sw_state(rfkill, !!(status & BIT(bit)));
+ rfkill_set_hw_state(rfkill, !(status & BIT(16)));
}
static const struct rfkill_ops dell_rfkill_ops = {
--
1.6.2.5
^ permalink raw reply related
* [PATCH] iwlwifi: remove usage of orig_flags
From: Luis R. Rodriguez @ 2009-07-31 1:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Reinette Chatre
This is a private flag, internal to cfg80211. cfg80211
will set orig_* stuff internally upon wiphy registration,
drivers do not need to muck with it.
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/iwlwifi/iwl-core.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 071c05b..a31bdc1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -548,9 +548,6 @@ int iwlcore_init_geos(struct iwl_priv *priv)
geo_ch->flags |= IEEE80211_CHAN_DISABLED;
}
- /* Save flags for reg domain usage */
- geo_ch->orig_flags = geo_ch->flags;
-
IWL_DEBUG_INFO(priv, "Channel %d Freq=%d[%sGHz] %s flag=0x%X\n",
ch->channel, geo_ch->center_freq,
is_channel_a_band(ch) ? "5.2" : "2.4",
--
1.6.3.3
^ permalink raw reply related
* Re: [Linux Wireless] Update of "en/users/Download" by ReinetteChatre
From: Luis R. Rodriguez @ 2009-07-31 1:31 UTC (permalink / raw)
To: Roman Macko; +Cc: reinette chatre, linux-wireless
In-Reply-To: <4A7246D0.1040200@gmail.com>
On Thu, Jul 30, 2009 at 6:20 PM, Roman Macko<rmacko72@gmail.com> wrote:
> Hi Luis,
>
> I have version 3.6 of module-init-tools and this version reads /etc/depmod.d
> directory too.
>
> But I wanted to understand how depmod reads config files, so I looked into
> source codes (both version 3.6 and 3.10)
> and finally found out how it works.
>
> Assume depmod is run without -C or --config option
>
> Version 3.6 reads firstly /etc/depmod.conf file and then it reads config
> files in directory /etc/depmod.d.
> Files in directory /etc/depmod.d are read and parsed in unpredictable order
> by readdir function (this function uses
> raw directory structures of filesystem)
>
> Version 3.10 reads /etc/depmod.conf firstly as well, but this config file is
> considered as deprecated in this version
> and prints out warning about that. Then it reads config files in directory
> /etc/depmod.d by readdir function as well, but before it starts
> to parse them, it sorts them accord to filename, so you know the order in
> which they are going to be parsed
> and this is very improtant!!! This behavior should be from version 3.7
>
> The same for both versions:
> 1) List of directories to be searched is created from search commands from
> all config files in order how particular
> search commands are found in config files (so order of parsed config files
> is important). If no search command is found,
> updates directory is added before "built-in" directory.
>
> 2) As for override command, the last one found for particular module and
> kernel in all config files wins,
> so again the order of parsed config files is important.
>
> From this is evident, that both versions can work differently which depends
> on the order of parsed config files from
> /etc/depmod.d directory that is different in both versions.
>
> So solution would be:
> 1) if there is no search command in any of config files (in /etc/depmod.conf
> or those in /etc/depmod.d directory), do nothing.
> 2) if there is a search command in any of config files and does not contain
> updates directory before built-in add search command
> "search updates" in
> a) if system has version >=3.7, create config file in /etc/depmod.d
> directory which name is alphabeticaly less than all you will find
> in that directory
> b) if system has version <=3.6 add search command "search updates" at the
> begining of /etc/depmod.conf file
>
> But such adding of "search updates" can break depmod configuration in some
> systems or it is not desirable to make search in
> updates directory at all. So maybe it would be better to use another name
> for directory than updates
>
> Or it would be also interesting to use override command for all modules
> compiled in compat-wireless
> and put it all to configuration file /etc/depmod.d/compat-wireless.conf and
> not bothering with version of depmod nor
> finding the search command in all configuration files, e.g
>
> compat-wireless.conf
> ======================================
> override iwlagn * updates/drivers/net/wireless/iwlwifi
> override iwlcore * updates/drivers/net/wireless/iwlwifi
> ....
> ....
> ....
> ======================================
>
> it can make problem only when some other config file in /etc/depmod.d
> directory contains override command for
> any module from compat-wireless
>
>
> I hope this help you
Thanks, since you have read this and can read code, mind putting
together a patch for the script on compat-wireless?
Luis
^ permalink raw reply
* Re: [Linux Wireless] Update of "en/users/Download" by ReinetteChatre
From: Roman Macko @ 2009-07-31 1:20 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette chatre, linux-wireless
In-Reply-To: <43e72e890907301006p200032e0i11fdb40fc33fa6d0@mail.gmail.com>
Hi Luis,
I have version 3.6 of module-init-tools and this version reads
/etc/depmod.d directory too.
But I wanted to understand how depmod reads config files, so I looked
into source codes (both version 3.6 and 3.10)
and finally found out how it works.
Assume depmod is run without -C or --config option
Version 3.6 reads firstly /etc/depmod.conf file and then it reads config
files in directory /etc/depmod.d.
Files in directory /etc/depmod.d are read and parsed in unpredictable
order by readdir function (this function uses
raw directory structures of filesystem)
Version 3.10 reads /etc/depmod.conf firstly as well, but this config
file is considered as deprecated in this version
and prints out warning about that. Then it reads config files in
directory /etc/depmod.d by readdir function as well, but before it starts
to parse them, it sorts them accord to filename, so you know the order
in which they are going to be parsed
and this is very improtant!!! This behavior should be from version 3.7
The same for both versions:
1) List of directories to be searched is created from search commands
from all config files in order how particular
search commands are found in config files (so order of parsed config
files is important). If no search command is found,
updates directory is added before "built-in" directory.
2) As for override command, the last one found for particular module and
kernel in all config files wins,
so again the order of parsed config files is important.
From this is evident, that both versions can work differently which
depends on the order of parsed config files from
/etc/depmod.d directory that is different in both versions.
So solution would be:
1) if there is no search command in any of config files (in
/etc/depmod.conf or those in /etc/depmod.d directory), do nothing.
2) if there is a search command in any of config files and does not
contain updates directory before built-in add search command
"search updates" in
a) if system has version >=3.7, create config file in /etc/depmod.d
directory which name is alphabeticaly less than all you will find
in that directory
b) if system has version <=3.6 add search command "search updates" at
the begining of /etc/depmod.conf file
But such adding of "search updates" can break depmod configuration in
some systems or it is not desirable to make search in
updates directory at all. So maybe it would be better to use another
name for directory than updates
Or it would be also interesting to use override command for all modules
compiled in compat-wireless
and put it all to configuration file /etc/depmod.d/compat-wireless.conf
and not bothering with version of depmod nor
finding the search command in all configuration files, e.g
compat-wireless.conf
======================================
override iwlagn * updates/drivers/net/wireless/iwlwifi
override iwlcore * updates/drivers/net/wireless/iwlwifi
....
....
....
======================================
it can make problem only when some other config file in /etc/depmod.d
directory contains override command for
any module from compat-wireless
I hope this help you
Regards
Roman
Luis R. Rodriguez wrote:
> On Thu, Jul 30, 2009 at 9:59 AM, Roman Macko<rmacko72@gmail.com> wrote:
>
>> Yes, I tested it. When you place that config file containing "search updates
>> built-in" in /etc/depmod.d
>> directory, it doesn't work.
>>
>
> OK you probably have an old version of depmod. depmod is provided by
> module-init-tools, what version of module-init-tools do you have?
>
> I have 3.10 (as on Ubuntu Karmic)
>
>
>> You have to place it in global config file
>> /etc/depmod.conf.
>>
>
> If this is an old depmod thing we will have to check the version of
> depmod and do this for that case.
>
>
>> How depmod works with config files in /etc/depmod.d directory is a mystery
>> for me.
>>
>
> Its not that tricky, the new version reads /etc/depmod.conf and if
> that is not found then moves on to check /etc/depmod.d/* files.
>
>
>> I wasn't able to learn
>> this from manual pages.
>>
>
> That's probably because your version doesn't use depmod.d dir.
>
>
>> And I tested another thing too. When some of config files (either global
>> /etc/depmod.conf or one of those in /etc/depmod.d directory)
>> doesn't contain search command ,
>> everything works fine, according to manual page for depmod, using builtin
>> search string "updates built-in" what is
>> what you need.
>>
>
> Right, built-in will use /lib/modules/$(uname -r)/kernel/ for modules,
> chances are if no depmod.conf file or depmod.d dir is present default
> may be to use built-in.
>
>
>> As soon as one of them (either global or one of those in
>> /etc/depmod.d directory) contains search command,
>> then depmod uses this one. It seems seach command in global config file
>> (/etc/depmod.conf) has higher priory. But as I say
>> I really don't know how depmod works with all config files.
>>
>
> I believe this is built-in by default, then read depmod.conf first, if
> that is not present read depmod.d dir.
>
> Luis
>
^ permalink raw reply
* [PATCH] cfg80211: fix regression on beacon world roaming feature
From: Luis R. Rodriguez @ 2009-07-31 0:43 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez, Jouni Malinen
A regression was added through patch a4ed90d6:
"cfg80211: respect API on orig_flags on channel for beacon hint"
We did indeed respect _orig flags but the intention was not clearly
stated in the commit log. This patch fixes firmware issues picked
up by iwlwifi when we lift passive scan of beaconing restrictions
on channels its EEPROM has been configured to always enable.
By doing so though we also disallowed beacon hints on devices
registering their wiphy with custom world regulatory domains
enabled, this happens to be currently ath5k, ath9k and ar9170.
The passive scan and beacon restrictions on those devices would
never be lifted even if we did find a beacon and the hardware did
support such enhancements when world roaming.
Since Johannes indicates iwlwifi firmware cannot be changed to
allow beacon hinting we set up a flag now to specifically allow
drivers to disable beacon hints for devices which cannot use them.
We enable the flag on iwlwifi to disable beacon hints and by default
enable it for all other drivers. It should be noted beacon hints lift
passive scan flags and beacon restrictions when we receive a beacon from
an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
band. We don't bother with channels 1-11 as those channels are allowed
world wide.
This should fix world roaming for ath5k, ath9k and ar9170, thereby
improving scan time when we receive the first beacon from any AP,
and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
would otherwise not be allowed to do so. Drivers not using custom
regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
by this as the orig_flags for the channels would have been cleared
upon wiphy registration.
I tested this with a world roaming ath5k card.
Cc: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
This issue affects 2.6.31, that's when the regression was introduced.
drivers/net/wireless/iwlwifi/iwl-core.c | 3 +++
drivers/net/wireless/iwlwifi/iwl3945-base.c | 3 +++
include/net/cfg80211.h | 5 +++++
net/wireless/reg.c | 9 +++++----
net/wireless/reg.h | 3 ++-
5 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 8570d56..071c05b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1600,6 +1600,9 @@ int iwl_setup_mac(struct iwl_priv *priv)
hw->wiphy->custom_regulatory = true;
+ /* Firmware does not support this */
+ hw->wiphy->disable_beacon_hints = true;
+
hw->wiphy->max_scan_ssids = PROBE_OPTION_MAX;
/* we create the 802.11 header and a zero-length SSID element */
hw->wiphy->max_scan_ie_len = IWL_MAX_PROBE_REQUEST - 24 - 2;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 5ded898..ea051b7 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -3905,6 +3905,9 @@ static int iwl3945_setup_mac(struct iwl_priv *priv)
hw->wiphy->custom_regulatory = true;
+ /* Firmware does not support this */
+ hw->wiphy->disable_beacon_hints = true;
+
hw->wiphy->max_scan_ssids = PROBE_OPTION_MAX_3945;
/* we create the 802.11 header and a zero-length SSID element */
hw->wiphy->max_scan_ie_len = IWL_MAX_PROBE_REQUEST - 24 - 2;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fa72997..64df51d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1076,6 +1076,10 @@ struct cfg80211_ops {
* channels at a later time. This can be used for devices which do not
* have calibration information gauranteed for frequencies or settings
* outside of its regulatory domain.
+ * @disable_beacon_hints: enable this if your driver needs to ensure that
+ * passive scan flags and beaconing flags may not be lifted by cfg80211
+ * due to regulatory beacon hints. For more information on beacon
+ * hints read the documenation for regulatory_hint_found_beacon()
* @reg_notifier: the driver's regulatory notification callback
* @regd: the driver's regulatory domain, if one was requested via
* the regulatory_hint() API. This can be used by the driver
@@ -1104,6 +1108,7 @@ struct wiphy {
bool custom_regulatory;
bool strict_regulatory;
+ bool disable_beacon_hints;
bool netnsok;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index b3ac0aa..0f61ae6 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1095,17 +1095,18 @@ static void handle_reg_beacon(struct wiphy *wiphy,
chan->beacon_found = true;
+ if (wiphy->disable_beacon_hints)
+ return;
+
chan_before.center_freq = chan->center_freq;
chan_before.flags = chan->flags;
- if ((chan->flags & IEEE80211_CHAN_PASSIVE_SCAN) &&
- !(chan->orig_flags & IEEE80211_CHAN_PASSIVE_SCAN)) {
+ if (chan->flags & IEEE80211_CHAN_PASSIVE_SCAN) {
chan->flags &= ~IEEE80211_CHAN_PASSIVE_SCAN;
channel_changed = true;
}
- if ((chan->flags & IEEE80211_CHAN_NO_IBSS) &&
- !(chan->orig_flags & IEEE80211_CHAN_NO_IBSS)) {
+ if (chan->flags & IEEE80211_CHAN_NO_IBSS) {
chan->flags &= ~IEEE80211_CHAN_NO_IBSS;
channel_changed = true;
}
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index 662a9da..1471225 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -30,7 +30,8 @@ int set_regdom(const struct ieee80211_regdomain *rd);
* non-radar 5 GHz channels.
*
* Drivers do not need to call this, cfg80211 will do it for after a scan
- * on a newly found BSS.
+ * on a newly found BSS. If you cannot make use of this feature you can
+ * set the wiphy->disable_beacon_hints to true.
*/
int regulatory_hint_found_beacon(struct wiphy *wiphy,
struct ieee80211_channel *beacon_chan,
--
1.6.3.3
^ permalink raw reply related
* [PATCH v4 4/4] cfg80211: enable country IE support to all cfg80211 drivers
From: Luis R. Rodriguez @ 2009-07-31 0:38 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1249000689-14970-1-git-send-email-lrodriguez@atheros.com>
Since the bss is always set now once we are connected, if the
bss has its own information element we refer to it and pass that
instead of relying on mac80211's parsing.
Now all cfg80211 drivers get country IE support, automatically and
we reduce the call overhead that we had on mac80211 which called this
upon every beacon and instead now call this only upon a successfull
connection by a STA on cfg80211.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
include/net/cfg80211.h | 14 --------------
net/mac80211/mlme.c | 6 +-----
net/wireless/reg.c | 6 +-----
net/wireless/reg.h | 15 +++++++++++++++
net/wireless/sme.c | 16 ++++++++++++++++
5 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e1b9235..fa72997 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1514,20 +1514,6 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb);
extern int regulatory_hint(struct wiphy *wiphy, const char *alpha2);
/**
- * regulatory_hint_11d - hints a country IE as a regulatory domain
- * @wiphy: the wireless device giving the hint (used only for reporting
- * conflicts)
- * @country_ie: pointer to the country IE
- * @country_ie_len: length of the country IE
- *
- * We will intersect the rd with the what CRDA tells us should apply
- * for the alpha2 this country IE belongs to, this prevents APs from
- * sending us incorrect or outdated information against a country.
- */
-extern void regulatory_hint_11d(struct wiphy *wiphy,
- u8 *country_ie,
- u8 country_ie_len);
-/**
* wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
* @wiphy: the wireless device we want to process the regulatory domain on
* @regd: the custom regulatory domain to use for this wiphy
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0779ba1..5ff1496 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1846,12 +1846,8 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
bssid, ap_ht_cap_flags);
}
+ /* Note: country IE parsing is done for us by cfg80211 */
if (elems.country_elem) {
- /* Note we are only reviewing this on beacons
- * for the BSSID we are associated to */
- regulatory_hint_11d(local->hw.wiphy,
- elems.country_elem, elems.country_elem_len);
-
/* TODO: IBSS also needs this */
if (elems.pwr_constr_elem)
ieee80211_handle_pwr_constr(sdata,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 6ab56f0..b3ac0aa 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1822,10 +1822,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
env = ENVIRON_OUTDOOR;
/*
- * We will run this for *every* beacon processed for the BSSID, so
- * we optimize an early check to exit out early if we don't have to
- * do anything
- *
+ * We will run this only upon a successful connection on cfg80211.
* We leave conflict resolution to the workqueue, where can hold
* cfg80211_mutex.
*/
@@ -1878,7 +1875,6 @@ free_rd_out:
out:
mutex_unlock(®_mutex);
}
-EXPORT_SYMBOL(regulatory_hint_11d);
static bool freq_is_chan_12_13_14(u16 freq)
{
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index e37829a..662a9da 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -36,4 +36,19 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
struct ieee80211_channel *beacon_chan,
gfp_t gfp);
+/**
+ * regulatory_hint_11d - hints a country IE as a regulatory domain
+ * @wiphy: the wireless device giving the hint (used only for reporting
+ * conflicts)
+ * @country_ie: pointer to the country IE
+ * @country_ie_len: length of the country IE
+ *
+ * We will intersect the rd with the what CRDA tells us should apply
+ * for the alpha2 this country IE belongs to, this prevents APs from
+ * sending us incorrect or outdated information against a country.
+ */
+void regulatory_hint_11d(struct wiphy *wiphy,
+ u8 *country_ie,
+ u8 country_ie_len);
+
#endif /* __NET_WIRELESS_REG_H */
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 3728d2b..af91192 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -13,6 +13,7 @@
#include <net/cfg80211.h>
#include <net/rtnetlink.h>
#include "nl80211.h"
+#include "reg.h"
struct cfg80211_conn {
struct cfg80211_connect_params params;
@@ -320,6 +321,7 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
struct cfg80211_bss *bss)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
+ u8 *country_ie;
#ifdef CONFIG_WIRELESS_EXT
union iwreq_data wrqu;
#endif
@@ -401,6 +403,20 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
wdev->sme_state = CFG80211_SME_CONNECTED;
cfg80211_upload_connect_keys(wdev);
+
+ country_ie = (u8 *) ieee80211_bss_get_ie(bss, WLAN_EID_COUNTRY);
+
+ if (!country_ie)
+ return;
+
+ /*
+ * ieee80211_bss_get_ie() ensures we can access:
+ * - country_ie + 2, the start of the country ie data, and
+ * - and country_ie[1] which is the IE length
+ */
+ regulatory_hint_11d(wdev->wiphy,
+ country_ie + 2,
+ country_ie[1]);
}
void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
--
1.6.3.3
^ permalink raw reply related
* [PATCH v4 3/4] cfg80211: decouple regulatory variables from cfg80211_mutex
From: Luis R. Rodriguez @ 2009-07-31 0:38 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1249000689-14970-1-git-send-email-lrodriguez@atheros.com>
We change regulatory code to be protected by its own regulatory
mutex and alleviate cfg80211_mutex to only be used to protect
cfg80211_rdev_list, the registered device list.
By doing this we will be able to work on regulatory core components
without having to have hog up the cfg80211_mutex. An example here is
we no longer need to use the cfg80211_mutex during driver specific
wiphy_apply_custom_regulatory(). We also no longer need it for the
the country IE regulatory hint; by doing so we end up curing this
new lockdep warning:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-rc4-wl #12
-------------------------------------------------------
phy1/1709 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211]
but task is already holding lock:
(&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&ifmgd->mtx){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
[<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211]
[<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211]
[<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211]
[<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211]
[<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211]
[<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
[<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
[<ffffffff814169d9>] genl_rcv+0x29/0x40
[<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
[<ffffffff81416514>] netlink_sendmsg+0x214/0x300
[<ffffffff813e4407>] sock_sendmsg+0x107/0x130
[<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #2 (&wdev->mtx){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
[<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211]
[<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80
[<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20
[<ffffffff813f665a>] dev_open+0x10a/0x120
[<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0
[<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760
[<ffffffff81450204>] inet_ioctl+0x94/0xc0
[<ffffffff813e25fa>] sock_ioctl+0x6a/0x290
[<ffffffff8111e911>] vfs_ioctl+0x31/0xa0
[<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0
[<ffffffff8111f069>] sys_ioctl+0x99/0xa0
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #1 (&rdev->mtx){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
[<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211]
[<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211]
[<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211]
[<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
[<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
[<ffffffff814169d9>] genl_rcv+0x29/0x40
[<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
[<ffffffff81416514>] netlink_sendmsg+0x214/0x300
[<ffffffff813e4407>] sock_sendmsg+0x107/0x130
[<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
3 locks held by phy1/1709:
#0: ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
#1: (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
#2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/wireless/core.c | 4 +---
net/wireless/reg.c | 46 +++++++++++++++++++++++++++++++++++++---------
2 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 755cdf1..d8dbd7f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -34,9 +34,7 @@ MODULE_DESCRIPTION("wireless configuration support");
LIST_HEAD(cfg80211_rdev_list);
/*
- * This is used to protect the cfg80211_rdev_list, cfg80211_regdomain,
- * country_ie_regdomain, the reg_beacon_list and the the last regulatory
- * request receipt (last_request).
+ * This is used to protect the cfg80211_rdev_list
*/
DEFINE_MUTEX(cfg80211_mutex);
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index f386981..6ab56f0 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -62,6 +62,16 @@ const struct ieee80211_regdomain *cfg80211_regdomain;
*/
static const struct ieee80211_regdomain *country_ie_regdomain;
+/*
+ * Protects static reg.c components:
+ * - cfg80211_world_regdom
+ * - cfg80211_regdom
+ * - country_ie_regdomain
+ * - last_request
+ */
+DEFINE_MUTEX(reg_mutex);
+#define assert_reg_lock() WARN_ON(!mutex_is_locked(®_mutex))
+
/* Used to queue up regulatory hints */
static LIST_HEAD(reg_requests_list);
static spinlock_t reg_requests_lock;
@@ -1293,7 +1303,7 @@ static void handle_channel_custom(struct wiphy *wiphy,
struct ieee80211_supported_band *sband;
struct ieee80211_channel *chan;
- assert_cfg80211_lock();
+ assert_reg_lock();
sband = wiphy->bands[band];
BUG_ON(chan_idx >= sband->n_channels);
@@ -1342,14 +1352,14 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
enum ieee80211_band band;
unsigned int bands_set = 0;
- mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
if (!wiphy->bands[band])
continue;
handle_band_custom(wiphy, band, regd);
bands_set++;
}
- mutex_unlock(&cfg80211_mutex);
+ mutex_unlock(®_mutex);
/*
* no point in calling this if it won't have any effect
@@ -1495,7 +1505,7 @@ static int ignore_request(struct wiphy *wiphy,
* Returns zero if all went fine, %-EALREADY if a regulatory domain had
* already been set or other standard error codes.
*
- * Caller must hold &cfg80211_mutex
+ * Caller must hold &cfg80211_mutex and ®_mutex
*/
static int __regulatory_hint(struct wiphy *wiphy,
struct regulatory_request *pending_request)
@@ -1570,6 +1580,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
BUG_ON(!reg_request->alpha2);
mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
if (wiphy_idx_valid(reg_request->wiphy_idx))
wiphy = wiphy_idx_to_wiphy(reg_request->wiphy_idx);
@@ -1585,6 +1596,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
if (r == -EALREADY && wiphy && wiphy->strict_regulatory)
wiphy_update_regulatory(wiphy, reg_request->initiator);
out:
+ mutex_unlock(®_mutex);
mutex_unlock(&cfg80211_mutex);
}
@@ -1613,6 +1625,10 @@ static void reg_process_pending_beacon_hints(void)
struct cfg80211_registered_device *rdev;
struct reg_beacon *pending_beacon, *tmp;
+ /*
+ * No need to hold the reg_mutex here as we just touch wiphys
+ * and do not read or access regulatory variables.
+ */
mutex_lock(&cfg80211_mutex);
/* This goes through the _pending_ beacon list */
@@ -1734,12 +1750,13 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
}
EXPORT_SYMBOL(regulatory_hint);
+/* Caller must hold reg_mutex */
static bool reg_same_country_ie_hint(struct wiphy *wiphy,
u32 country_ie_checksum)
{
struct wiphy *request_wiphy;
- assert_cfg80211_lock();
+ assert_reg_lock();
if (unlikely(last_request->initiator !=
NL80211_REGDOM_SET_BY_COUNTRY_IE))
@@ -1776,7 +1793,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
enum environment_cap env = ENVIRON_ANY;
struct regulatory_request *request;
- mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
if (unlikely(!last_request))
goto out;
@@ -1850,7 +1867,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
request->country_ie_checksum = checksum;
request->country_ie_env = env;
- mutex_unlock(&cfg80211_mutex);
+ mutex_unlock(®_mutex);
queue_regulatory_request(request);
@@ -1859,7 +1876,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
free_rd_out:
kfree(rd);
out:
- mutex_unlock(&cfg80211_mutex);
+ mutex_unlock(®_mutex);
}
EXPORT_SYMBOL(regulatory_hint_11d);
@@ -2192,10 +2209,13 @@ int set_regdom(const struct ieee80211_regdomain *rd)
assert_cfg80211_lock();
+ mutex_lock(®_mutex);
+
/* Note that this doesn't update the wiphys, this is done below */
r = __set_regdom(rd);
if (r) {
kfree(rd);
+ mutex_unlock(®_mutex);
return r;
}
@@ -2210,6 +2230,8 @@ int set_regdom(const struct ieee80211_regdomain *rd)
nl80211_send_reg_change_event(last_request);
+ mutex_unlock(®_mutex);
+
return r;
}
@@ -2220,16 +2242,20 @@ void reg_device_remove(struct wiphy *wiphy)
assert_cfg80211_lock();
+ mutex_lock(®_mutex);
+
kfree(wiphy->regd);
if (last_request)
request_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx);
if (!request_wiphy || request_wiphy != wiphy)
- return;
+ goto out;
last_request->wiphy_idx = WIPHY_IDX_STALE;
last_request->country_ie_env = ENVIRON_ANY;
+out:
+ mutex_unlock(®_mutex);
}
int regulatory_init(void)
@@ -2290,6 +2316,7 @@ void regulatory_exit(void)
cancel_work_sync(®_work);
mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
reset_regdomains();
@@ -2328,5 +2355,6 @@ void regulatory_exit(void)
}
spin_unlock(®_requests_lock);
+ mutex_unlock(®_mutex);
mutex_unlock(&cfg80211_mutex);
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH v4 2/4] cfg80211: do not iterate over rdev list on country IE hint
From: Luis R. Rodriguez @ 2009-07-31 0:38 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1249000689-14970-1-git-send-email-lrodriguez@atheros.com>
Simplify the country IE hint code by just bailing out if
a previous country IE has been issued. We currently just trust
the first AP we connect to on any card. The idea was to perform
conflict resolution within this routine but since we can no longer
iterate over the registered device list here we leave conflict
resolution to be dealt with at a later time on the workqueue.
This code has no functional changes other than saving us an
interation over the registered device list when a second card
is connected, or you unplug and connect the same one, and a
country IE is received. This would have been done upon every
beacon received.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/wireless/reg.c | 51 +++++++++------------------------------------------
1 files changed, 9 insertions(+), 42 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2d1d183..f386981 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1762,6 +1762,10 @@ static bool reg_same_country_ie_hint(struct wiphy *wiphy,
return false;
}
+/*
+ * We hold wdev_lock() here so we cannot hold cfg80211_mutex() and
+ * therefore cannot iterate over the rdev list here.
+ */
void regulatory_hint_11d(struct wiphy *wiphy,
u8 *country_ie,
u8 country_ie_len)
@@ -1804,51 +1808,14 @@ void regulatory_hint_11d(struct wiphy *wiphy,
* We will run this for *every* beacon processed for the BSSID, so
* we optimize an early check to exit out early if we don't have to
* do anything
+ *
+ * We leave conflict resolution to the workqueue, where can hold
+ * cfg80211_mutex.
*/
if (likely(last_request->initiator ==
NL80211_REGDOM_SET_BY_COUNTRY_IE &&
- wiphy_idx_valid(last_request->wiphy_idx))) {
- struct cfg80211_registered_device *rdev_last_ie;
-
- rdev_last_ie =
- cfg80211_rdev_by_wiphy_idx(last_request->wiphy_idx);
-
- /*
- * Lets keep this simple -- we trust the first AP
- * after we intersect with CRDA
- */
- if (likely(&rdev_last_ie->wiphy == wiphy)) {
- /*
- * Ignore IEs coming in on this wiphy with
- * the same alpha2 and environment cap
- */
- if (likely(alpha2_equal(rdev_last_ie->country_ie_alpha2,
- alpha2) &&
- env == rdev_last_ie->env)) {
- goto out;
- }
- /*
- * the wiphy moved on to another BSSID or the AP
- * was reconfigured. XXX: We need to deal with the
- * case where the user suspends and goes to goes
- * to another country, and then gets IEs from an
- * AP with different settings
- */
- goto out;
- } else {
- /*
- * Ignore IEs coming in on two separate wiphys with
- * the same alpha2 and environment cap
- */
- if (likely(alpha2_equal(rdev_last_ie->country_ie_alpha2,
- alpha2) &&
- env == rdev_last_ie->env)) {
- goto out;
- }
- /* We could potentially intersect though */
- goto out;
- }
- }
+ wiphy_idx_valid(last_request->wiphy_idx)))
+ goto out;
rd = country_ie_2_rd(country_ie, country_ie_len, &checksum);
if (!rd)
--
1.6.3.3
^ permalink raw reply related
* [PATCH v4 1/4] cfg80211: use goto out on country IE reg hint failure
From: Luis R. Rodriguez @ 2009-07-31 0:38 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1249000689-14970-1-git-send-email-lrodriguez@atheros.com>
This has no functional changes.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/wireless/reg.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index fb40428..2d1d183 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1774,10 +1774,8 @@ void regulatory_hint_11d(struct wiphy *wiphy,
mutex_lock(&cfg80211_mutex);
- if (unlikely(!last_request)) {
- mutex_unlock(&cfg80211_mutex);
- return;
- }
+ if (unlikely(!last_request))
+ goto out;
/* IE len must be evenly divisible by 2 */
if (country_ie_len & 0x01)
--
1.6.3.3
^ permalink raw reply related
* [PATCH v4 0/4] wireless: fix reg lockdep and move country ie hint
From: Luis R. Rodriguez @ 2009-07-31 0:38 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
Alright, this should be it, the snag I found is fixed by the new
patch 2/4 of this series. When we want to deal with conflicts
for multiple country IE hints (when we suspend for example)
we can deal with the conflict on the workqueue and lift the
early check out we have there now.
Luis R. Rodriguez (4):
cfg80211: use goto out on country IE reg hint failure
cfg80211: do not iterate over rdev list on country IE hint
cfg80211: decouple regulatory variables from cfg80211_mutex
cfg80211: enable country IE support to all cfg80211 drivers
include/net/cfg80211.h | 14 ------
net/mac80211/mlme.c | 6 +--
net/wireless/core.c | 4 +-
net/wireless/reg.c | 107 +++++++++++++++++++++--------------------------
net/wireless/reg.h | 15 +++++++
net/wireless/sme.c | 16 +++++++
6 files changed, 81 insertions(+), 81 deletions(-)
^ permalink raw reply
* [PATCH] iw: add beacon hint event parsing
From: Luis R. Rodriguez @ 2009-07-31 0:05 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luis R. Rodriguez
Here's a screenshot:
mcgrof@pogo ~ $ iw event
mcgrof@pogo ~ $ sudo iw dev wlan0 scan trigger
phy #0: beacon hint:
phy0 5180 MHz [36]:
o active scanning enabled
o beaconing enabled
You'll see this on every channel you find a beacon and a flag
is lifted.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
This patch was sitting in a cave lonely since March 31st, seems we forgot
about it it, poor patch. I rebased it.
event.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/event.c b/event.c
index 2671331..0cd3c75 100644
--- a/event.c
+++ b/event.c
@@ -9,6 +9,38 @@ static int no_seq_check(struct nl_msg *msg, void *arg)
return NL_OK;
}
+struct ieee80211_beacon_channel {
+ __u16 center_freq;
+ bool passive_scan;
+ bool no_ibss;
+};
+
+static int parse_beacon_hint_chan(struct nlattr *tb,
+ struct ieee80211_beacon_channel *chan)
+{
+ struct nlattr *tb_freq[NL80211_FREQUENCY_ATTR_MAX + 1];
+ static struct nla_policy beacon_freq_policy[NL80211_FREQUENCY_ATTR_MAX + 1] = {
+ [NL80211_FREQUENCY_ATTR_FREQ] = { .type = NLA_U32 },
+ [NL80211_FREQUENCY_ATTR_PASSIVE_SCAN] = { .type = NLA_FLAG },
+ [NL80211_FREQUENCY_ATTR_NO_IBSS] = { .type = NLA_FLAG },
+ };
+
+ if (nla_parse_nested(tb_freq,
+ NL80211_FREQUENCY_ATTR_MAX,
+ tb,
+ beacon_freq_policy))
+ return -EINVAL;
+
+ chan->center_freq = nla_get_u32(tb_freq[NL80211_FREQUENCY_ATTR_FREQ]);
+
+ if (tb_freq[NL80211_FREQUENCY_ATTR_PASSIVE_SCAN])
+ chan->passive_scan = true;
+ if (tb_freq[NL80211_FREQUENCY_ATTR_NO_IBSS])
+ chan->no_ibss = true;
+
+ return 0;
+}
+
static void print_frame(struct print_event_args *args, struct nlattr *attr)
{
uint8_t *frame;
@@ -70,12 +102,21 @@ static void print_frame(struct print_event_args *args, struct nlattr *attr)
static int print_event(struct nl_msg *msg, void *arg)
{
+#define PARSE_BEACON_CHAN(_attr, _chan) do { \
+ r = parse_beacon_hint_chan(tb[_attr], \
+ &_chan); \
+ if (r) \
+ return NL_SKIP; \
+} while (0)
struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
struct nlattr *tb[NL80211_ATTR_MAX + 1], *nst;
struct print_event_args *args = arg;
char ifname[100];
char macbuf[6*3];
__u8 reg_type;
+ struct ieee80211_beacon_channel chan_before_beacon, chan_after_beacon;
+ __u32 wiphy_idx = 0;
+ int r;
int rem_nst;
__u16 status;
@@ -159,6 +200,33 @@ static int print_event(struct nl_msg *msg, void *arg)
printf("\n");
break;
+ case NL80211_CMD_REG_BEACON_HINT:
+
+ wiphy_idx = nla_get_u32(tb[NL80211_ATTR_WIPHY]);
+
+ memset(&chan_before_beacon, 0, sizeof(chan_before_beacon));
+ memset(&chan_after_beacon, 0, sizeof(chan_after_beacon));
+
+ PARSE_BEACON_CHAN(NL80211_ATTR_FREQ_BEFORE, chan_before_beacon);
+ PARSE_BEACON_CHAN(NL80211_ATTR_FREQ_AFTER, chan_after_beacon);
+
+ if (chan_before_beacon.center_freq != chan_after_beacon.center_freq)
+ break;
+
+ /* A beacon hint is sent _only_ if something _did_ change */
+ printf("beacon hint:\n");
+
+ printf("phy%d %d MHz [%d]:\n",
+ wiphy_idx,
+ chan_before_beacon.center_freq,
+ ieee80211_frequency_to_channel(chan_before_beacon.center_freq));
+
+ if (chan_before_beacon.passive_scan && !chan_after_beacon.passive_scan)
+ printf("\to active scanning enabled\n");
+ if (chan_before_beacon.no_ibss && !chan_after_beacon.no_ibss)
+ printf("\to beaconing enabled\n");
+
+ break;
case NL80211_CMD_JOIN_IBSS:
mac_addr_n2a(macbuf, nla_data(tb[NL80211_ATTR_MAC]));
printf("IBSS %s joined\n", macbuf);
@@ -236,6 +304,7 @@ static int print_event(struct nl_msg *msg, void *arg)
}
return NL_SKIP;
+#undef PARSE_BEACON_CHAN
}
struct wait_event {
--
1.6.3.3
^ permalink raw reply related
* RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
From: Jack Lau @ 2009-07-30 22:48 UTC (permalink / raw)
To: proski; +Cc: linux-wireless
In-Reply-To: <1248821338.5206.12.camel@mj>
Pavel,
I have downloaded wireless-testing via git, compiled it and installed it which includes the below patch.
The git version was v2.6.31-rc4-29204-g6b3a8c9 (30/07/2009).
Unfortunately, I am still getting this very annoying crash.
Regards,
Jack
----------------------------------------
> Subject: RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
> From: proski@gnu.org
> To: jackelectronics@hotmail.com
> CC: linux-wireless@vger.kernel.org
> Date: Tue, 28 Jul 2009 18:48:58 -0400
>
> On Tue, 2009-07-28 at 21:21 +0000, Jack Lau wrote:
>
>>> I have enabled debugging in config.mk and installed it.
>
> I didn't suggest that. I think it's irrelevant. Only the setting
> in .config is relevant.
>
> If you are using compat-wireless, I suggest that you try the current
> kernel from wireless-testing. It was quite unstable a few days ago, but
> it should be cleaned up by now. Since you are using the AP mode, you'll
> need this patch, it's still not applied as of now:
>
> http://marc.info/?l=linux-wireless&m=124871936602667&w=2
>
> compat-wireless is great if everything is working, but if something is
> broken, the first suspicion is that compat-wireless doesn't backport
> something correctly.
>
>> The kernel already has debugging enabled as I have examined the
>> source from Ubuntu.
>
> Please be specific what you found and where. I don't have Ubuntu
> around, but others could correct you if you are looking in a wrong
> place.
>
>>> When I load the gdb command, I just get no debugging symbols found
>> and with the l command I just get no symbol file now.
>
> Please don't rephrase tell the error messages, especially if you don't
> understand them fully. I cannot see from your words why there are no
> debugging symbols.
>
> Also please don't top-post, as it makes it harder to quote the
> discussion in a reasonable way.
>
> --
> Regards,
> Pavel Roskin
_________________________________________________________________
Share your memories online with anyone you want.
http://clk.atdmt.com/UKM/go/134665338/direct/01/
^ permalink raw reply
* Re: ath5k: monitor mode needs channel change
From: Bob Copeland @ 2009-07-30 22:05 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4A72113F.8000604@gmx.de>
On Thu, Jul 30, 2009 at 5:31 PM, Joerg Albert<jal2@gmx.de> wrote:
> I currently need an extra trigger by changing the channel after
> "ifconfig up" to see any output in monitor mode from ath5k, e.g.
Does this (accidentally) fix it by chance?
http://patchwork.kernel.org/patch/38165/
It reloads the filters at ifup time.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* lockdep complaint between ieee80211_process_addba_resp() and del_timer_sync()
From: Luis R. Rodriguez @ 2009-07-30 22:05 UTC (permalink / raw)
To: linux-wireless
I get this upon association to my AP, not always reproducible, I
think. I do have my reg patches on top of this but I do not think that
should affect this. The issue is between
ieee80211_process_addba_resp() and del_timer_sync() it seems.
Luis
[ 83.047764] =======================================================
[ 83.047982] [ INFO: possible circular locking dependency detected ]
[ 83.048100] 2.6.31-rc4-wl #15
[ 83.048195] -------------------------------------------------------
[ 83.048299] swapper/0 is trying to acquire lock:
[ 83.048393]
(&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer){+.-...}, at:
[<ffffffff81062cc0>] del_timer_sync+0x0/0xc0
[ 83.048739]
[ 83.048739] but task is already holding lock:
[ 83.048919] (&sta->lock){+.-...}, at: [<ffffffffa0152454>]
ieee80211_process_addba_resp+0x44/0x110 [mac80211]
[ 83.049276]
[ 83.049276] which lock already depends on the new lock.
[ 83.049277]
[ 83.049548]
[ 83.049548] the existing dependency chain (in reverse order) is:
[ 83.049728]
[ 83.049729] -> #1 (&sta->lock){+.-...}:
[ 83.050140] [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[ 83.050315] [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[ 83.050492] [<ffffffff814f0e01>] _spin_lock_bh+0x31/0x40
[ 83.050666] [<ffffffffa01525ea>]
sta_addba_resp_timer_expired+0x3a/0x90 [mac80211]
[ 83.050860] [<ffffffff8106254e>] run_timer_softirq+0x1be/0x2b0
[ 83.051035] [<ffffffff8105cc2a>] __do_softirq+0xfa/0x1f0
[ 83.051210] [<ffffffff8101322c>] call_softirq+0x1c/0x30
[ 83.051385] [<ffffffff81014a65>] do_softirq+0x95/0xd0
[ 83.051559] [<ffffffff8105c645>] irq_exit+0x85/0xb0
[ 83.051682] [<ffffffff810141a3>] do_IRQ+0x73/0xf0
[ 83.051682] [<ffffffff81012a13>] ret_from_intr+0x0/0x16
[ 83.051682] [<ffffffffffffffff>] 0xffffffffffffffff
[ 83.051682]
[ 83.051682] -> #0 (&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer){+.-...}:
[ 83.051682] [<ffffffff8108587b>] __lock_acquire+0xe3b/0x12b0
[ 83.051682] [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[ 83.051682] [<ffffffff81062d0a>] del_timer_sync+0x4a/0xc0
[ 83.051682] [<ffffffffa01524a9>]
ieee80211_process_addba_resp+0x99/0x110 [mac80211]
[ 83.051682] [<ffffffffa015f95f>]
ieee80211_invoke_rx_handlers+0x195f/0x1a90 [mac80211]
[ 83.051682] [<ffffffffa015fdc9>]
__ieee80211_rx_handle_packet+0x339/0x640 [mac80211]
[ 83.051682] [<ffffffffa01607e3>] __ieee80211_rx+0x403/0x6f0 [mac80211]
[ 83.051682] [<ffffffffa0248440>]
ath_rx_send_to_mac80211+0x130/0x140 [ath9k]
[ 83.051682] [<ffffffffa0248bd3>] ath_rx_tasklet+0x6d3/0xb70 [ath9k]
[ 83.051682] [<ffffffffa024680a>] ath9k_tasklet+0xea/0x130 [ath9k]
[ 83.051682] [<ffffffff8105c14d>] tasklet_action+0x7d/0x110
[ 83.051682] [<ffffffff8105cc2a>] __do_softirq+0xfa/0x1f0
[ 83.051682] [<ffffffff8101322c>] call_softirq+0x1c/0x30
[ 83.051682] [<ffffffff81014a65>] do_softirq+0x95/0xd0
[ 83.051682] [<ffffffff8105c645>] irq_exit+0x85/0xb0
[ 83.051682] [<ffffffff810141a3>] do_IRQ+0x73/0xf0
[ 83.051682] [<ffffffff81012a13>] ret_from_intr+0x0/0x16
[ 83.051682] [<ffffffffffffffff>] 0xffffffffffffffff
[ 83.051682]
[ 83.051682] other info that might help us debug this:
[ 83.051682]
[ 83.051682] 4 locks held by swapper/0:
[ 83.051682] #0: (&sc->rx.rxflushlock){+.-...}, at:
[<ffffffffa0246800>] ath9k_tasklet+0xe0/0x130 [ath9k]
[ 83.051682] #1: (&sc->rx.rxbuflock){+.-...}, at:
[<ffffffffa0248549>] ath_rx_tasklet+0x49/0xb70 [ath9k]
[ 83.051682] #2: (rcu_read_lock){.+.+..}, at: [<ffffffffa01604cf>]
__ieee80211_rx+0xef/0x6f0 [mac80211]
[ 83.051682] #3: (&sta->lock){+.-...}, at: [<ffffffffa0152454>]
ieee80211_process_addba_resp+0x44/0x110 [mac80211]
[ 83.051682]
[ 83.051682] stack backtrace:
[ 83.051682] Pid: 0, comm: swapper Not tainted 2.6.31-rc4-wl #15
[ 83.051682] Call Trace:
[ 83.051682] <IRQ> [<ffffffff81083f0c>] print_circular_bug_tail+0xac/0x100
[ 83.051682] [<ffffffff8108587b>] __lock_acquire+0xe3b/0x12b0
[ 83.051682] [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[ 83.051682] [<ffffffff81062cc0>] ? del_timer_sync+0x0/0xc0
[ 83.051682] [<ffffffff81062d0a>] del_timer_sync+0x4a/0xc0
[ 83.051682] [<ffffffff81062cc0>] ? del_timer_sync+0x0/0xc0
[ 83.051682] [<ffffffffa01524a9>]
ieee80211_process_addba_resp+0x99/0x110 [mac80211]
[ 83.051682] [<ffffffffa015dde6>] ?
ieee80211_drop_unencrypted+0x66/0x190 [mac80211]
[ 83.051682] [<ffffffffa015f95f>]
ieee80211_invoke_rx_handlers+0x195f/0x1a90 [mac80211]
[ 83.051682] [<ffffffff810843fd>] ? mark_held_locks+0x6d/0x90
[ 83.051682] [<ffffffff814f0c3f>] ? _spin_unlock_irqrestore+0x3f/0x70
[ 83.051682] [<ffffffff81084647>] ? trace_hardirqs_on_caller+0x67/0x1a0
[ 83.051682] [<ffffffff81063259>] ? mod_timer+0xf9/0x160
[ 83.051682] [<ffffffffa015fdc9>]
__ieee80211_rx_handle_packet+0x339/0x640 [mac80211]
[ 83.051682] [<ffffffffa01607e3>] __ieee80211_rx+0x403/0x6f0 [mac80211]
[ 83.051682] [<ffffffffa01604cf>] ? __ieee80211_rx+0xef/0x6f0 [mac80211]
[ 83.051682] [<ffffffff814f0baf>] ? _spin_unlock_bh+0x2f/0x40
[ 83.051682] [<ffffffffa02481d5>] ? ath_get_virt_hw+0x25/0xa0 [ath9k]
[ 83.051682] [<ffffffffa0248440>] ath_rx_send_to_mac80211+0x130/0x140 [ath9k]
[ 83.051682] [<ffffffffa0248bd3>] ath_rx_tasklet+0x6d3/0xb70 [ath9k]
[ 83.051682] [<ffffffffa0248825>] ? ath_rx_tasklet+0x325/0xb70 [ath9k]
[ 83.051682] [<ffffffffa024680a>] ath9k_tasklet+0xea/0x130 [ath9k]
[ 83.051682] [<ffffffff8105c14d>] tasklet_action+0x7d/0x110
[ 83.051682] [<ffffffff8105cc2a>] __do_softirq+0xfa/0x1f0
[ 83.051682] [<ffffffff8101322c>] call_softirq+0x1c/0x30
[ 83.051682] [<ffffffff81014a65>] do_softirq+0x95/0xd0
[ 83.051682] [<ffffffff8105c645>] irq_exit+0x85/0xb0
[ 83.051682] [<ffffffff810141a3>] do_IRQ+0x73/0xf0
[ 83.051682] [<ffffffff81012a13>] ret_from_intr+0x0/0x16
[ 83.051682] <EOI> [<ffffffff812a572a>] ? acpi_idle_enter_bm+0x258/0x28d
[ 83.051682] [<ffffffff812a5723>] ? acpi_idle_enter_bm+0x251/0x28d
[ 83.051682] [<ffffffff813cbc25>] ? cpuidle_idle_call+0xa5/0x100
[ 83.051682] [<ffffffff8101114d>] ? cpu_idle+0x6d/0xc0
[ 83.051682] [<ffffffff814d7fe5>] ? rest_init+0x65/0x70
[ 83.051682] [<ffffffff8187fddd>] ? start_kernel+0x3c0/0x475
[ 83.051682] [<ffffffff8187f2b9>] ? x86_64_start_reservations+0x99/0xb9
[ 83.051682] [<ffffffff8187f3df>] ? x86_64_start_kernel+0x106/0x121
[ 83.051682] [<ffffffff8187f140>] ? early_idt_handler+0x0/0x71
^ permalink raw reply
* Re: [PATCH] compat-2.6: Makefile: fixed test expressions for target install
From: Pavel Roskin @ 2009-07-30 21:42 UTC (permalink / raw)
To: Joerg Albert; +Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <4A720FE4.4020301@gmx.de>
On Thu, 2009-07-30 at 23:25 +0200, Joerg Albert wrote:
> This removes the two errors of [ with target "install"
>
> make[1]: Leaving directory `/home/joerg/src/linux-2.6.30'
> [: 9: missing ]
> [: 9: missing ]
> depmod will prefer updates/ over kernel/ -- OK!
I believe "-a" in test is not very portable. I remember getting
complaints about it. I believe the built-in test command in bash 1.x
doesn't have it. I'd rather stick with && and || written properly.
"-a" and -o" are currently only used in the clean target and in the
maintenance scripts, so they probably don't get enough testing on
systems with old bash.
--
Regards,
Pavel Roskin
^ permalink raw reply
* ath5k: monitor mode needs channel change
From: Joerg Albert @ 2009-07-30 21:31 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
I currently need an extra trigger by changing the channel after
"ifconfig up" to see any output in monitor mode from ath5k, e.g.
ifconfig wlan0 down
iwconfig wlan0 mode monitor channel 1
ifconfig wlan0 up
# no output by tcpdump -n -i wlan0 in another xterm
iwconfig wlan0 channel 2
# tcpdump output starts
The second "iwconfig" call must specify a channel different to the
first one.
The above sequence without the second "iwconfig" works fine with a
RTL8187 device.
I'm running
compat-wireless-2.6: master-2009-07-26-11-g83c091c
wireless-testing: v2.6.31-rc4-29204-g6b3a8c9
on top of a 2.6.30 kernel.
The WLAN NIC is a:
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x
802.11abg Wireless PCI Express Adapter (rev 01),
PCI id: 168c:001c (rev 01)
ath5k identifies it as:
ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
It's not a big issue, but a bit annoying sometimes.
^ permalink raw reply
* [PATCH] compat-2.6: Makefile: fixed test expressions for target install
From: Joerg Albert @ 2009-07-30 21:25 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless@vger.kernel.org
This removes the two errors of [ with target "install"
make[1]: Leaving directory `/home/joerg/src/linux-2.6.30'
[: 9: missing ]
[: 9: missing ]
depmod will prefer updates/ over kernel/ -- OK!
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 62eb5db..90279c9 100644
--- a/Makefile
+++ b/Makefile
@@ -80,7 +80,7 @@ install-scripts:
@install scripts/athload $(DESTDIR)/usr/sbin/
@install scripts/b43load $(DESTDIR)/usr/sbin/
@install scripts/iwl-load $(DESTDIR)/usr/sbin/
- @if [ ! -z $(MADWIFI) && -z "$(DESTDIR)" ]; then \
+ @if [ ! -z "$(MADWIFI)" -a -z "$(DESTDIR)" ]; then \
echo ;\
echo -n "Note: madwifi detected, we're going to disable it. " ;\
echo "If you would like to enable it later you can run:" ;\
@@ -89,7 +89,7 @@ install-scripts:
echo Running athenable ath5k...;\
/usr/sbin/athenable ath5k ;\
fi
- @if [ ! -z $(OLD_IWL) && -z "$(DESTDIR)" ]; then \
+ @if [ ! -z "$(OLD_IWL)" -a -z "$(DESTDIR)" ]; then \
echo ;\
echo -n "Note: iwl4965 detected, we're going to disable it. " ;\
echo "If you would like to enable it later you can run:" ;\
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH v2 0/3] wireless: fix 11d lockdep and move 11d hint to cfg80211
From: Luis R. Rodriguez @ 2009-07-30 20:59 UTC (permalink / raw)
To: johannes, John W. Linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1248974386-8168-1-git-send-email-lrodriguez@atheros.com>
On Thu, Jul 30, 2009 at 10:19 AM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> This cures the lockdep warning, now with a mutex instead of a spin_lock
> to allow sleeping during the driver reg notifier, and we finish the
> move of the regulatory_hint_11d() to cfg80211. We also add some missing
> lock calls and remove the cfg80211 mutex usage from the driver custom
> regulatory settings wiphy_apply_custom_regulatory(). This caller is now
> used internally within cfg80211 automatically for all cfg80211 drivers.
>
> Luis R. Rodriguez (3):
> cfg80211: use goto out on 11d reg hint failure
> cfg80211: decouple regulatory variables from cfg80211_mutex
> cfg80211: enable country IE support to all cfg80211 drivers
Just hit a snag, will try to fix and respin. We were still trying to
get the rdev for the last country ie request when we plug in a second
card. Will try to use the wiphy_idx only.
Luis
^ permalink raw reply
* Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode
From: Johannes Berg @ 2009-07-30 20:13 UTC (permalink / raw)
To: Igor Perminov; +Cc: linux-wireless
In-Reply-To: <1248984581.29068.265.camel@sunlight>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
On Fri, 2009-07-31 at 00:09 +0400, Igor Perminov wrote:
> How will a driver behave in case a device has no a separate hardware
> filter for PS Poll frames? I.e. what value should the driver return from
> configure_filter in total_flags?
>
> In case there is one common filter for all control frames, it's an easy
> thing. If FIF_CONTROL or FIF_PSPOLL are passed to driver's
> configure_filter in total_flags, both of them should be set there and
> the filter should be configured to pass through all control frames.
>
> And suppose a device has two filters: one for ACK frames and one for all
> other control frames.
> Suppose FIF_CONTROL is passed in total_flags only. In that case the
> driver sets FIF_PSPOLL there and configures both filters to pass through
> frames. Right?
> And what if FIF_PSPOLL is passed in total_flags only? In that case the
> ACK filter should be configured to filter out ACK frames (otherwise it
> would have performance overhead at least). And the second filter is
> configured to pass through frames only (i.e. all control frames except
> for ACK). So, the driver will receive not only PS Poll control frames,
> but some others.
> The question here is: should the driver set FIF_CONTROL in total_flags
> or not in that case?
Huh this is getting complicated.
I think that driver behave as follows:
* PSPOLL: configure control, no-ack, set PSPOLL
* CONTROL: configure control, ack, set CONTROL
* PSPOLL | CONTROL: configure control, ack, set PSPOLL | CONTROL
Although I guess it could also set PSPOLL to indicate that is being
passed. OTOH, I don't think CONTROL by itself makes any sense to pass
in, so the second case won't really happen anyway.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 05/14 w-t and 2.6.31] iwlagn: do not send key clear commands when rfkill enabled
From: reinette chatre @ 2009-07-30 20:12 UTC (permalink / raw)
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247848227-24031-6-git-send-email-reinette.chatre@intel.com>
John,
This patch did not make it to Linus's repo. Could you please consider it
for 2.6.31? We would like to have this patch in 2.6.31 because it fixes
a regression that is tracked in
http://bugzilla.kernel.org/show_bug.cgi?id=13742
Thank you
Reinette
On Fri, 2009-07-17 at 09:30 -0700, Chatre, Reinette wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> Do all key clearing except sending sommands to device when rfkill
> enabled. When rfkill enabled the interface is brought down and will
> be brought back up correctly after rfkill is enabled again.
>
> Same change is not needed for iwl3945 as it ignores return code when
> sending key clearing command to device.
>
> This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13742
>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> Tested-by: Frans Pop <elendil@planet.nl>
> ---
> drivers/net/wireless/iwlwifi/iwl-sta.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.c b/drivers/net/wireless/iwlwifi/iwl-sta.c
> index 2addf73..ffd5c61 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-sta.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
> @@ -566,6 +566,8 @@ int iwl_remove_default_wep_key(struct iwl_priv *priv,
> unsigned long flags;
>
> spin_lock_irqsave(&priv->sta_lock, flags);
> + IWL_DEBUG_WEP(priv, "Removing default WEP key: idx=%d\n",
> + keyconf->keyidx);
>
> if (!test_and_clear_bit(keyconf->keyidx, &priv->ucode_key_table))
> IWL_ERR(priv, "index %d not used in uCode key table.\n",
> @@ -573,6 +575,11 @@ int iwl_remove_default_wep_key(struct iwl_priv *priv,
>
> priv->default_wep_key--;
> memset(&priv->wep_keys[keyconf->keyidx], 0, sizeof(priv->wep_keys[0]));
> + if (iwl_is_rfkill(priv)) {
> + IWL_DEBUG_WEP(priv, "Not sending REPLY_WEPKEY command due to RFKILL.\n");
> + spin_unlock_irqrestore(&priv->sta_lock, flags);
> + return 0;
> + }
> ret = iwl_send_static_wepkey_cmd(priv, 1);
> IWL_DEBUG_WEP(priv, "Remove default WEP key: idx=%d ret=%d\n",
> keyconf->keyidx, ret);
> @@ -853,6 +860,11 @@ int iwl_remove_dynamic_key(struct iwl_priv *priv,
> priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
> priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
>
> + if (iwl_is_rfkill(priv)) {
> + IWL_DEBUG_WEP(priv, "Not sending REPLY_ADD_STA command because RFKILL enabled. \n");
> + spin_unlock_irqrestore(&priv->sta_lock, flags);
> + return 0;
> + }
> ret = iwl_send_add_sta(priv, &priv->stations[sta_id].sta, CMD_ASYNC);
> spin_unlock_irqrestore(&priv->sta_lock, flags);
> return ret;
^ permalink raw reply
* Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode
From: Igor Perminov @ 2009-07-30 20:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1248794724.8113.12.camel@johannes.local>
On Tue, 28/07/2009 at 17:25 +0200, Johannes Berg wrote:
> On Tue, 2009-07-28 at 18:17 +0400, Igor Perminov wrote:
>
> > And in case we introduce the FIF_PSPOLL flag, what the exact semantics
> > will it have? When the FIF_CONTROL flag is passed to a driver, but the
> > FIF_PSPOLL one isn't, should the driver filter out PS Poll frames (a) or
> > not (b)?
>
> Like all filter flags, FIF_PSPOLL would mean "give us PSPOLL frames
> please", so (b).
And one more question.
How will a driver behave in case a device has no a separate hardware
filter for PS Poll frames? I.e. what value should the driver return from
configure_filter in total_flags?
In case there is one common filter for all control frames, it's an easy
thing. If FIF_CONTROL or FIF_PSPOLL are passed to driver's
configure_filter in total_flags, both of them should be set there and
the filter should be configured to pass through all control frames.
And suppose a device has two filters: one for ACK frames and one for all
other control frames.
Suppose FIF_CONTROL is passed in total_flags only. In that case the
driver sets FIF_PSPOLL there and configures both filters to pass through
frames. Right?
And what if FIF_PSPOLL is passed in total_flags only? In that case the
ACK filter should be configured to filter out ACK frames (otherwise it
would have performance overhead at least). And the second filter is
configured to pass through frames only (i.e. all control frames except
for ACK). So, the driver will receive not only PS Poll control frames,
but some others.
The question here is: should the driver set FIF_CONTROL in total_flags
or not in that case?
Igor
^ 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