* [PATCH 1/2] cfg80211: process new country regulatory flags (DFS)
From: Luis R. Rodriguez @ 2010-12-20 17:02 UTC (permalink / raw)
To: linville
Cc: kathy.giori, amod.bodas, david.quan, michael.green,
linux-wireless, Luis R. Rodriguez
In-Reply-To: <1292864555-28661-1-git-send-email-lrodriguez@atheros.com>
This lets us pick up the new country regulatory flags.
This will later be used to inform of drivers later of
DFS parameters.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
include/linux/nl80211.h | 23 +++++++++++++++++++++++
include/net/regulatory.h | 1 +
net/wireless/nl80211.c | 9 +++++++++
net/wireless/reg.c | 26 ++++++++++++++++++++++++++
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 1cee56b..f5553ba 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -858,6 +858,9 @@ enum nl80211_commands {
* attributes, specifying what a key should be set as default as.
* See &enum nl80211_key_default_types.
*
+ * @NL80211_ATTR_REG_COUNTRY_FLAGS: Country specific regulatory flags.
+ * These are @NL80211_CFLAG_DFS_*
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1040,6 +1043,8 @@ enum nl80211_attrs {
NL80211_ATTR_MAX_REMAIN_ON_CHANNEL_DURATION,
+ NL80211_ATTR_REG_COUNTRY_FLAGS,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -1477,6 +1482,24 @@ enum nl80211_reg_rule_flags {
};
/**
+ * enum nl80211_cflags - country regulatory flags
+ *
+ * @NL80211_CFLAG_DFS_FCC_: Country follows DFS master rules from FCC
+ * @NL80211_CFLAG_DFS_FCC_: Country follows DFS master rules from ETSI
+ * @NL80211_CFLAG_DFS_JP_: Country follows DFS master rules from JP/Telec
+ */
+enum nl80211_cflags {
+ NL80211_CFLAG_DFS_FCC = 1<<0,
+ NL80211_CFLAG_DFS_ETSI = 1<<1,
+ NL80211_CFLAG_DFS_JP = 1<<2,
+};
+
+#define NL80211_CFLAG_ALL_DFS_FLAGS \
+ (NL80211_CFLAG_DFS_FCC | \
+ NL80211_CFLAG_DFS_ETSI | \
+ NL80211_CFLAG_DFS_JP)
+
+/**
* enum nl80211_survey_info - survey information
*
* These attribute types are used with %NL80211_ATTR_SURVEY_INFO
diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index 356d6e3..9fcb603 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -85,6 +85,7 @@ struct ieee80211_reg_rule {
struct ieee80211_regdomain {
u32 n_reg_rules;
char alpha2[2];
+ u16 flags;
struct ieee80211_reg_rule reg_rules[];
};
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 594a6ac..d255499 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -172,6 +172,7 @@ 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_REG_COUNTRY_FLAGS] = { .type = NLA_U16 },
};
/* policy for the key attributes */
@@ -2906,6 +2907,8 @@ static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
NLA_PUT_STRING(msg, NL80211_ATTR_REG_ALPHA2,
cfg80211_regdomain->alpha2);
+ NLA_PUT_U16(msg, NL80211_ATTR_REG_COUNTRY_FLAGS,
+ cfg80211_regdomain->flags);
nl_reg_rules = nla_nest_start(msg, NL80211_ATTR_REG_RULES);
if (!nl_reg_rules)
@@ -2963,6 +2966,7 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
char *alpha2 = NULL;
int rem_reg_rules = 0, r = 0;
u32 num_rules = 0, rule_idx = 0, size_of_regd;
+ u16 cflags = 0;
struct ieee80211_regdomain *rd = NULL;
if (!info->attrs[NL80211_ATTR_REG_ALPHA2])
@@ -2973,6 +2977,10 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
alpha2 = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
+ if (info->attrs[NL80211_ATTR_REG_COUNTRY_FLAGS])
+ cflags =
+ nla_get_u16(info->attrs[NL80211_ATTR_REG_COUNTRY_FLAGS]);
+
nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
rem_reg_rules) {
num_rules++;
@@ -2999,6 +3007,7 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
rd->n_reg_rules = num_rules;
rd->alpha2[0] = alpha2[0];
rd->alpha2[1] = alpha2[1];
+ rd->flags = cflags;
nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
rem_reg_rules) {
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 99d4183..a3731d2 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1881,6 +1881,31 @@ static void print_rd_rules(const struct ieee80211_regdomain *rd)
}
}
+#define flag_check_print(_str) \
+ do { \
+ if (has_flag) \
+ pr_info(", "); \
+ pr_info(_str); \
+ has_flag = true; \
+ } while (0)
+
+static void print_country_flags(u16 flags)
+{
+ bool has_flag = false;
+
+ if (!(flags & NL80211_CFLAG_ALL_DFS_FLAGS))
+ return;
+
+ pr_info("DFS Master region:");
+
+ if (flags & NL80211_CFLAG_DFS_FCC)
+ flag_check_print("FCC");
+ if (flags & NL80211_CFLAG_DFS_ETSI)
+ flag_check_print("ETSI");
+ if (flags & NL80211_CFLAG_DFS_JP)
+ flag_check_print("JP");
+}
+
static void print_regdomain(const struct ieee80211_regdomain *rd)
{
@@ -1908,6 +1933,7 @@ static void print_regdomain(const struct ieee80211_regdomain *rd)
pr_info("Regulatory domain changed to country: %c%c\n",
rd->alpha2[0], rd->alpha2[1]);
}
+ print_country_flags(rd->flags);
print_rd_rules(rd);
}
--
1.7.3.2.90.gd4c43
^ permalink raw reply related
* [PATCH 1/8] wireless-regdb: Add DFS bit fields for countries
From: Luis R. Rodriguez @ 2010-12-20 17:02 UTC (permalink / raw)
To: linville
Cc: kathy.giori, amod.bodas, david.quan, michael.green,
linux-wireless, Luis R. Rodriguez
In-Reply-To: <1292864555-28661-1-git-send-email-lrodriguez@atheros.com>
To support DFS we add the three known DFS regions which countries
can support. In order to not modify the regulatory database scheme
in an incompatible way we use some two pad bytes which were unused
for this. This lets us later also add some more bits for general
country specific regulatory data.
We keep the regulatory database intact as otherwise older CRDA
versions will not read new regulatory file updates. Instead of
requiring new CRDA version out in the field we can treat this
as a regulatory update and simply have users who want DFS master
support to upgrade their CRDA. We'll treat the DFS region assignemnts
as a simple regulatory update.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
db2bin.py | 2 +-
dbparse.py | 25 ++++++++++++++++++++-----
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/db2bin.py b/db2bin.py
index 23d3ee2..b8a153c 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -116,7 +116,7 @@ countrynames.sort()
for alpha2 in countrynames:
coll = countries[alpha2]
# struct regdb_file_reg_country
- output.write(struct.pack('>ccxxI', str(alpha2[0]), str(alpha2[1]), reg_rules_collections[coll.permissions]))
+ output.write(struct.pack('>cchI', str(alpha2[0]), str(alpha2[1]), coll.cflags, reg_rules_collections[coll.permissions]))
if len(sys.argv) > 3:
diff --git a/dbparse.py b/dbparse.py
index 2c0d738..f5087f2 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -18,6 +18,12 @@ flag_definitions = {
'NO-HT40': 1<<10,
}
+country_flag_definitions = {
+ 'DFS-FCC': 1<<0,
+ 'DFS-ETSI': 1<<1,
+ 'DFS-JP': 1<<2,
+}
+
class FreqBand(object):
def __init__(self, start, end, bw, comments=None):
self.start = start
@@ -61,6 +67,10 @@ class PowerRestriction(object):
s = self
return hash((s.max_ant_gain, s.max_eirp))
+class CountryFlagError(Exception):
+ def __init__(self, cflag):
+ self.flag = cflag
+
class FlagError(Exception):
def __init__(self, flag):
self.flag = flag
@@ -90,9 +100,15 @@ class Permission(object):
return hash(self._as_tuple())
class Country(object):
- def __init__(self, permissions=None, comments=None):
+ def __init__(self, cflags, permissions=None, comments=None):
self._permissions = permissions or []
self.comments = comments or []
+ self.cflags = 0
+ if cflags:
+ for cflag in cflags.split(','):
+ if not cflag in country_flag_definitions:
+ raise CountryFlagError(cflag)
+ self.cflags |= country_flag_definitions[cflag]
def add(self, perm):
assert isinstance(perm, Permission)
@@ -224,11 +240,10 @@ class DBParser(object):
def _parse_country(self, line):
try:
- cname, line = line.split(':', 1)
+ cname, cflags = line.split(':', 1)
+ cflags = cflags.strip()
if not cname:
self._syntax_error("'country' keyword must be followed by name")
- if line:
- self._syntax_error("extra data at end of country line")
except ValueError:
self._syntax_error("country name must be followed by colon")
@@ -239,7 +254,7 @@ class DBParser(object):
if len(cname) != 2:
self._warn("country '%s' not alpha2" % cname)
if not cname in self._countries:
- self._countries[cname] = Country(comments=self._comments)
+ self._countries[cname] = Country(cflags, comments=self._comments)
self._current_countries[cname] = self._countries[cname]
self._comments = []
--
1.7.3.2.90.gd4c43
^ permalink raw reply related
* [PATCH 0/8] wireless: DFS region support
From: Luis R. Rodriguez @ 2010-12-20 17:02 UTC (permalink / raw)
To: linville
Cc: kathy.giori, amod.bodas, david.quan, michael.green,
linux-wireless, Luis R. Rodriguez
This series has a list of changes to kernel and userspace to start addressing
DFS region support. I've cheated and figured out a way to alter the current
regulatory database in such a way that it remains backwards compatible with
older databases so that no new CRDAs are required and we don't have to provide
two releases for old kernels and newer kernels for wireless-regdb updates.
In the end we end up passing the DFS region to the drivers. In terms of our DFS
development roadmap this covers parts I and II as promissed that I would take care
of by tomorrow, and leaves open now the chance for developers to start working
on part III: "Where do we stuff DFS parameters for each region":
http://wireless.kernel.org/en/developers/DFS
In tomorrow's meeting we can cover who is going to work on part III. People who
want to work on part III can start using these patches on their systems.
John, lets wait to merge these until Wednesday, I post these in patch form as I
think they are ready but tomorrow's discussions may push us to alter this a
bit, not sure. I will also review what we have done here with Michael Green so
he is on the same page.
Luis
^ permalink raw reply
* Re: [RFC 3/8] cfg80211: pass DFS region to drivers through reg_notifier()
From: Luis R. Rodriguez @ 2010-12-20 16:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <AANLkTimZaYX+YPUJF9PG5_fbopuSPBH_bFUkH=MabNXb@mail.gmail.com>
On Mon, Dec 20, 2010 at 8:16 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, Dec 17, 2010 at 11:40 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> On Fri, Dec 17, 2010 at 1:50 AM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> On Thu, 2010-12-16 at 19:23 -0800, Luis R. Rodriguez wrote:
>>>
>>>> /* Lets us get back the wiphy on the callback */
>>>> int (*reg_notifier)(struct wiphy *wiphy,
>>>> - struct regulatory_request *request);
>>>> + struct regulatory_request *request,
>>>> + u8 dfs_region);
>>>
>>> So does that mean we need to implement a reg_notifier if we want to have
>>> radar detection? Doesn't an empty reg_notifier already alter behaviour
>>
>> An empty reg_notifier() should not do anything. Its either through the
>> reg_notifier() or we add a new callback specifically for DFS. A new
>> callback may give more flexibility later if we want to pass up more
>> data.
>
> After some more thought I think its best to keep this within the
> reg_notifier() instead of adding a new callback, the reason being that
> we are already passing some regulatory data on it, no point in
> splitting up the calls and having those synch up on themselves later
> on the driver. But we are missing the alpha2 which I suspect drivers
> may need to request_firmware() some DFS data for the specific chipset,
> or do their own lookup on local static data. We don't currently pass
> the cfg80211_regdomain but I think it makes sense in this case, then
> the user can just check the alpha2 from it and in case other users
> need any other data from the regulatory domain they can have at it.
>
> I'm going to make this change and submit as PATCH form next. I haven't
> seen any more feeback on this so I take it that we're OK with this.
Actually, the alpha2 is already part of the struct regulatory_request
which is passed and come to think of it I can just peg the dfs_region
onto this so we do not have to extend the callbacks anywhere.
Luis
^ permalink raw reply
* [PATCH] ath9k: fix aphy / wiphy idle mismatch
From: Luis R. Rodriguez @ 2010-12-20 16:29 UTC (permalink / raw)
To: linville
Cc: linux-wireless, Luis R. Rodriguez, stable, Paul Stewart,
Amod Bodas
ath9k supports its own set of virtual wiphys, and it uses
the mac80211 idle notifications to know when a device needs
to be idle or not. We recently changed ath9k to force idle
on driver stop() and on resume but forgot to take into account
ath9k's own virtual wiphy idle states. These are used internally
by ath9k to check if the device's radio should be powered down
on each idle call. Without this change its possible that the
device could have been forced off but the virtual wiphy idle
was left on.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
I'm not yet sure if this actually fixes an issue but it
certainly is a proper ammendment to the other idle fix
submitted for stable for suspend/resume.
drivers/net/wireless/ath/ath9k/main.c | 1 +
drivers/net/wireless/ath/ath9k/pci.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 4d64716..1b35175 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1354,6 +1354,7 @@ static void ath9k_stop(struct ieee80211_hw *hw)
ath9k_ps_restore(sc);
sc->ps_idle = true;
+ ath9k_set_wiphy_idle(aphy, true);
ath_radio_disable(sc, hw);
sc->sc_flags |= SC_OP_INVALID;
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 7ca8499..4538283 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -310,6 +310,7 @@ static int ath_pci_resume(struct device *device)
ath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, 1);
sc->ps_idle = true;
+ ath9k_set_wiphy_idle(aphy, true);
ath_radio_disable(sc, hw);
return 0;
--
1.7.3.2.90.gd4c43
^ permalink raw reply related
* Re: [RFC 3/8] cfg80211: pass DFS region to drivers through reg_notifier()
From: Luis R. Rodriguez @ 2010-12-20 16:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <AANLkTimseBRXix3sFsHnCVBjZh6=Jfum8MGUqq1Uf6z0@mail.gmail.com>
On Fri, Dec 17, 2010 at 11:40 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, Dec 17, 2010 at 1:50 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Thu, 2010-12-16 at 19:23 -0800, Luis R. Rodriguez wrote:
>>
>>> /* Lets us get back the wiphy on the callback */
>>> int (*reg_notifier)(struct wiphy *wiphy,
>>> - struct regulatory_request *request);
>>> + struct regulatory_request *request,
>>> + u8 dfs_region);
>>
>> So does that mean we need to implement a reg_notifier if we want to have
>> radar detection? Doesn't an empty reg_notifier already alter behaviour
>
> An empty reg_notifier() should not do anything. Its either through the
> reg_notifier() or we add a new callback specifically for DFS. A new
> callback may give more flexibility later if we want to pass up more
> data.
After some more thought I think its best to keep this within the
reg_notifier() instead of adding a new callback, the reason being that
we are already passing some regulatory data on it, no point in
splitting up the calls and having those synch up on themselves later
on the driver. But we are missing the alpha2 which I suspect drivers
may need to request_firmware() some DFS data for the specific chipset,
or do their own lookup on local static data. We don't currently pass
the cfg80211_regdomain but I think it makes sense in this case, then
the user can just check the alpha2 from it and in case other users
need any other data from the regulatory domain they can have at it.
I'm going to make this change and submit as PATCH form next. I haven't
seen any more feeback on this so I take it that we're OK with this.
Luis
^ permalink raw reply
* Re: [PATCH 2/2] compat-wireless: unify some driver-select colors
From: Luis R. Rodriguez @ 2010-12-20 15:55 UTC (permalink / raw)
To: Walter Goldens; +Cc: linux-wireless
In-Reply-To: <216485.77625.qm@web56801.mail.re3.yahoo.com>
On Mon, Dec 20, 2010 at 3:34 AM, Walter Goldens
<goldenstranger@yahoo.com> wrote:
> unify driver-select colors for better user screen readbility
>
> Signed-off-by: Walter Goldens <goldenstranger@yahoo.com>
Applied and pushed both, thanks!
Luis
^ permalink raw reply
* Re: rtl8192 does not see N networks in my building
From: Amos Blanton @ 2010-12-20 15:49 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <AANLkTinCWK95_eFb47pFLz2O=+UHMGpeXg9Z_JstFEa=@mail.gmail.com>
Ok, I did the lwist scan properly this time. And wow, we have a lot of
wifi here - 96 cells in fact.
The list has most of the visible networks that others can see in the
area with the exception of MIT N, which is the one that works decently
well. There's also MIT Secure N, which it doesn't see either. So I
guess the device is not finding any N networks?
Would this be something I should report to RealTek?
Thanks very much for your help with this.
-Amos
p.s. Also, I heard a rumor that the people responsible for installing
the Wifi here overdid it a tad, with too many transmitters. Seems like
it might be true?
Here's a page or two of lwlist results:
wlan0 Scan completed :
Cell 01 - Address: 00:23:EB:D1:C0:B3
ESSID:"MIT"
Protocol:IEEE802.11N-24G
Mode:Master
Channel:1
Encryption key:off
Bit Rates:300 Mb/s
Extra: Rates (Mb/s): 1 2 5.5 6 9 11 12 18 24 36 48 54
Quality=76/100 Signal level=-67 dBm Noise level=-108 dBm
Extra: Last beacon: 122ms ago
Cell 02 - Address: 00:23:EB:D1:C0:B4
ESSID:"MIT SECURE"
Protocol:IEEE802.11N-24G
Mode:Master
Channel:1
Encryption key:on
Bit Rates:300 Mb/s
Extra: Rates (Mb/s): 1 2 5.5 6 9 11 12 18 24 36 48 54
Quality=79/100 Signal level=-67 dBm Noise level=-109 dBm
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : 802.1x
Extra: Last beacon: 128ms ago
Cell 03 - Address: 00:23:EB:D1:C0:B6
ESSID:"<hidden>\x00"
Protocol:IEEE802.11N-24G
Mode:Master
Channel:1
Encryption key:on
Bit Rates:300 Mb/s
Extra: Rates (Mb/s): 1 2 5.5 6 9 11 12 18 24 36 48 54
Quality=81/100 Signal level=-65 dBm Noise level=-110 dBm
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Extra: Last beacon: 1ms ago
Cell 04 - Address: 00:23:EB:D2:26:90
ESSID:"MIT GUEST"
Protocol:IEEE802.11N-24G
Mode:Master
Channel:1
Encryption key:off
Bit Rates:300 Mb/s
On Fri, Dec 17, 2010 at 10:32 PM, Amos Blanton <amos.blanton@gmail.com> wrote:
> On Fri, Dec 17, 2010 at 2:57 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> The report I have from Realtek is that a mac80211 driver for that device is
>> nearing completion. I originally thought that you were using a staging driver,
>> but you must be using a driver from Realtek's site. Do you have the latest? I
>> show it to be rtl8192se_linux_2.6.0018.1025.2010. As I recall, that one does not
>> work on a 64-bit system.
>
> AFAIK it's whatever ships with Ubuntu 10.10, unless the people at
> Zareason installed a different driver before shipping this laptop.
> I've searched the package manager but can't find anything related.
> Let's see, google says modinfo should tell me. Here's the output:
>
> lightnin@Buford:~$ modinfo r8192se_pci
> filename:
> /lib/modules/2.6.35-23-generic/kernel/ubuntu/rtl8192se/r8192se_pci.ko
> license: GPL
> version: 0017.0507.2010
> author: Copyright(c) 2008 - 2010 Realsil Semiconductor
> Corporation <wlanfae@realtek.com>
> description: Linux driver for Realtek RTL819x WiFi cards
> srcversion: 64C041B4E539FCBBF8BEA08
> alias: pci:v000010ECd00008174sv*sd*bc*sc*i*
> alias: pci:v000010ECd00008173sv*sd*bc*sc*i*
> alias: pci:v000010ECd00008172sv*sd*bc*sc*i*
> alias: pci:v000010ECd00008171sv*sd*bc*sc*i*
> alias: pci:v000010ECd00008192sv*sd*bc*sc*i*
> depends:
> vermagic: 2.6.35-23-generic SMP mod_unload modversions
> parm: ifname: Net interface name, wlan%d=default (charp)
> parm: hwwep: Try to use hardware WEP support(default use hw.
> set 0 to use software security) (int)
> parm: channels: Channel bitmask for specific locales. NYI (int)
>
>
>> You need to run iwlist as root to get an active scan. That is why I specified
>> the "sudo iwlist scan". Your prompt above looks like the regular user one. If
>> I'm wrong there, then something is blocking transmission. Is the module rfkill
>> loaded?
>
> Ah, my apologies! I did forget the sudo - sorry about that. I've left
> work now but will do a scan on Monday.
>
> Should I try installing an updated version of the driver that is
> compatible with 64 bit systems? Where might that be?
>
> Amos
>
>>
>> Larry
>>
>
^ permalink raw reply
* Re: vendor IEs?
From: Luis R. Rodriguez @ 2010-12-20 15:44 UTC (permalink / raw)
To: Daniel Halperin; +Cc: linux-wireless
In-Reply-To: <AANLkTi=n4pUEy_3PYX=7wbY+zR4D8=EGDNN-NtqhFs2q@mail.gmail.com>
On Sun, Dec 19, 2010 at 4:53 PM, Daniel Halperin
<dhalperi@cs.washington.edu> wrote:
> Is there a compiled list of vendor-specific IEs out there? Googling
> didn't offer much help.
If you would like, feel free to peg them on the wireless.kernel.org somewhere :)
Luis
^ permalink raw reply
* Recent suspend/resume fix for which devices?
From: Sujith @ 2010-12-20 14:53 UTC (permalink / raw)
To: Jonas H.; +Cc: linux-wireless
In-Reply-To: <4D0E19EB.3070802@lophus.org>
Jonas H. wrote:
> Hello!
>
> My AR9285 wireless card, used with the ath9k driver, stops working after
> supsend/resume - I have to reboot to make it work again.
>
> Trying to figure out whether this is fixed for 2.6.37 I noticed commit
> f933ebed (in Linus' tree) "ath9k_htc: Fix suspend/resume.
> The HW has to be set to FULLSLEEP mode during suspend, ...".
>
> My question is: Does that fix also apply to my card? I realize the patch
> only applies to ath9k_htc but I couldn't figure what "htc" stands for in
> this context.
Nope, that commit is not relevant for ath9k, which is the driver for your card.
ath9k_htc is a different driver.
Sujith
^ permalink raw reply
* Re: Recent suspend/resume fix for which devices?
From: John W. Linville @ 2010-12-20 14:15 UTC (permalink / raw)
To: Jonas H.; +Cc: linux-wireless
In-Reply-To: <4D0E19EB.3070802@lophus.org>
On Sun, Dec 19, 2010 at 03:42:51PM +0100, Jonas H. wrote:
> Hello!
>
> My AR9285 wireless card, used with the ath9k driver, stops working
> after supsend/resume - I have to reboot to make it work again.
>
> Trying to figure out whether this is fixed for 2.6.37 I noticed
> commit f933ebed (in Linus' tree) "ath9k_htc: Fix suspend/resume. The
> HW has to be set to FULLSLEEP mode during suspend, ...".
>
> My question is: Does that fix also apply to my card? I realize the
> patch only applies to ath9k_htc but I couldn't figure what "htc"
> stands for in this context.
Probably not. Did you try reverting it?
> If it doesn't, does this mailing list also function as a bug tracker?
Sorta, but not really. There is a bugzilla instance at bugzilla.kernel.org.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Wireless channel stuck to -1 on mon0 (fix patch submission)
From: John W. Linville @ 2010-12-20 14:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gábor Stefanik, CalimeroTeknik, linux-wireless
In-Reply-To: <1292794572.8422.0.camel@jlt3.sipsolutions.net>
On Sun, Dec 19, 2010 at 10:36:12PM +0100, Johannes Berg wrote:
> On Sun, 2010-12-19 at 21:58 +0100, Gábor Stefanik wrote:
> > This is a known problem, that has basically been WONTFIXed a while
> > ago. I highly disagree with the reasoning, but the decision ultimately
> > rests on Johannes. In the meantime, check patches.aircrack-ng.org for
> > a workaround.
> >
> > Johannes: I know that you consider reporting the actual channel of the
> > PHY to be "confusing to users" when running with multiple virtual
> > PHYs, but apparently this is what most users expect. Perhaps it
> > *should* be implemented after all.
>
> In which case it should be implemented properly, not half-baked like all
> the patches we've seen so far.
This does continue to pop-up. Do you have a link to a description
of a proper implementation?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: smatch stuff: potential read past the end of the buffer
From: Dan Carpenter @ 2010-12-20 12:42 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Vasanthakumar Thiagarajan, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F0594D7@SJEXCHCCR02.corp.ad.broadcom.com>
On Mon, Dec 20, 2010 at 02:16:56AM -0800, Arend Van Spriel wrote:
> Hi Dan,
>
> Why not use min() function?
> index = min(COMP_HDR_LEN + osize, 2046);
> mchecksum = word[index] |
> (word[index + 1] << 8);
>
> Or would smatch miss this in its analysis?
That would silence the warning, but is it the right fix? I thought
maybe we should make word a larger buffer?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Fix panic on frame padding for rt2800 usb devices (due to not enough skb tailroom)
From: Ivo Van Doorn @ 2010-12-20 11:45 UTC (permalink / raw)
To: Ismael Luceno; +Cc: linux-wireless, Gertjan van Wingerde
In-Reply-To: <1292833909-20138-2-git-send-email-ismael.luceno@gmail.com>
Hi,
> Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
Please add a short description why this change is needed,
I only know why because of a discussion over private mail...
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 85185de..d284e1e 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -369,7 +369,8 @@ static void rt2800usb_write_tx_desc(struct queue_entry *entry,
> static void rt2800usb_write_tx_data(struct queue_entry *entry,
> struct txentry_desc *txdesc)
> {
> - u8 padding_len;
> + unsigned int padding_len;
> + int err;
>
> /*
> * pad(1~3 bytes) is added after each 802.11 payload.
> @@ -379,8 +380,14 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
> * |<------------- tx_pkt_len ------------->|
> */
> padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
> - memset(skb_put(entry->skb, padding_len), 0, padding_len);
>
> + err = skb_pad(entry->skb, padding_len);
> + if (unlikely(err)) {
> + WARNING(entry->queue->rt2x00dev, "TX SKB padding error, out of memory\n");
> + return;
> + }
Please use skb_padto instead, that will actually check if the padding
is needed or not...
Ivo
^ permalink raw reply
* [PATCH 2/2] compat-wireless: unify some driver-select colors
From: Walter Goldens @ 2010-12-20 11:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
unify driver-select colors for better user screen readbility
Signed-off-by: Walter Goldens <goldenstranger@yahoo.com>
---
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -45,7 +45,7 @@ fi
SUPPORTED_ETH_DRIVERS=""
function usage {
- echo -e "${GREEN}Usage${NORMAL}: ${CYAN}$0${NORMAL} [ ${PURPLE}<driver-name>${NORMAL} | ${PURPLE}<driver-group-name>${NORMAL} | ${GREEN}restore${NORMAL} ]"
+ echo -e "${GREEN}Usage${NORMAL}: ${BOLD}$0${NORMAL} [ ${PURPLE}<driver-name>${NORMAL} | ${CYAN}<driver-group-name>${NORMAL} | ${GREEN}restore${NORMAL} ]"
# These should match the switch below.
echo -e "Supported 802.11 drivers:"
@@ -64,8 +64,8 @@ function usage {
echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 wl12xx (SPI and SDIO)${NORMAL}>"
echo -e "\nSupported group drivers: Bluetooth & Ethernet:"
- echo -e "\t${BLUE}atlxx${NORMAL} < ${PURPLE} atl1 atl2 atl1e atl1c ${NORMAL}>"
- echo -e "\t${BLUE}bt${NORMAL} < ${PURPLE} Linux bluetooth drivers ${NORMAL}>"
+ echo -e "\t${CYAN}atlxx${NORMAL} < ${PURPLE} atl1 atl2 atl1e atl1c ${NORMAL}>"
+ echo -e "\t${CYAN}bt${NORMAL} < ${PURPLE} Linux bluetooth drivers ${NORMAL}>"
echo -e "Restoring compat-wireless:"
echo -e "\t${GREEN}restore${NORMAL}: you can use this option to restore compat-wireless to the original state"
^ permalink raw reply
* [PATCH 1/2] compat-wireless: complete rtlwifi/RTL8192CE support
From: Walter Goldens @ 2010-12-20 11:33 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <1292625768-17318-3-git-send-email-hauke@hauke-m.de>
enable driver-select for rtlwifi/rtl8192ce
complete renaming rtlwifi entries for compat-wireless
Signed-off-by: Walter Goldens <goldenstranger@yahoo.com>
---
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -60,6 +60,7 @@ function usage {
echo -e "\t${CYAN}intel${NORMAL} < ${PURPLE} iwl3945 iwlagn ipw2100 ipw2200 ${NORMAL}>"
echo -e "\t${CYAN}iwlwifi${NORMAL} < ${PURPLE} iwl3945 iwlagn ${NORMAL}>"
echo -e "\t${CYAN}rtl818x${NORMAL} < ${PURPLE} rtl8180 rtl8187 ${NORMAL}>"
+ echo -e "\t${CYAN}rtlwifi${NORMAL} < ${PURPLE} rtl8192ce ${NORMAL}>"
echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 wl12xx (SPI and SDIO)${NORMAL}>"
echo -e "\nSupported group drivers: Bluetooth & Ethernet:"
@@ -332,6 +333,11 @@ case $1 in
disable_staging
disable_var_02
;;
+ rtlwifi)
+ select_drivers CONFIG_RTL8192CE CONFIG_RTLWIFI
+ disable_staging
+ disable_bt_usb_ethernet_var
+ ;;
wl12xx)
select_drivers CONFIG_WL1251 \
CONFIG_WL12XX
--- a/Makefile
+++ b/Makefile
@@ -271,6 +271,8 @@ install-scripts:
@$(MODPROBE) -l rt73usb
@$(MODPROBE) -l rtl8180
@$(MODPROBE) -l rtl8187
+ @$(MODPROBE) -l rtlwifi
+ @$(MODPROBE) -l rtl8192ce
@$(MODPROBE) -l spectrum_cs
@$(MODPROBE) -l ssb
@$(MODPROBE) -l usb8xxx
@@ -400,6 +402,8 @@ uninstall:
@$(MODPROBE) -l rt73usb
@$(MODPROBE) -l rtl8180
@$(MODPROBE) -l rtl8187
+ @$(MODPROBE) -l rtlwifi
+ @$(MODPROBE) -l rtl8192ce
@$(MODPROBE) -l spectrum_cs
@$(MODPROBE) -l ssb
@$(MODPROBE) -l usb8xxx
--- a/README
+++ b/README
@@ -159,6 +159,8 @@ rt61pci
rt73usb
rtl8180
rtl8187
+rtlwifi
+rtl8192ce
spectrum_cs
ssb
wl1251
--- a/scripts/unload.sh
+++ b/scripts/unload.sh
@@ -23,7 +23,7 @@ MODULES="$MODULES rt2400pci rt2500pci rt
MODULES="$MODULES rt2500usb rt73usb"
MODULES="$MODULES rt2800usb rt2800lib"
MODULES="$MODULES rt2x00usb rt2x00lib"
-MODULES="$MODULES rtl8180 rtl8187"
+MODULES="$MODULES rtl8180 rtl8187 rtl8192ce rtlwifi"
MODULES="$MODULES mwl8k mac80211_hwsim"
MODULES="$MODULES at76c50x_usb at76_usb"
MODULES="$MODULES rndis_wlan rndis_host cdc_ether usbnet"
--- a/scripts/wlunload.sh
+++ b/scripts/wlunload.sh
@@ -23,7 +23,7 @@ MODULES="$MODULES rt2400pci rt2500pci rt
MODULES="$MODULES rt2500usb rt73usb"
MODULES="$MODULES rt2800usb rt2800lib"
MODULES="$MODULES rt2x00usb rt2x00lib"
-MODULES="$MODULES rtl8180 rtl8187"
+MODULES="$MODULES rtl8180 rtl8187 rtl8192ce rtlwifi"
MODULES="$MODULES mwl8k mac80211_hwsim"
MODULES="$MODULES at76c50x_usb at76_usb"
MODULES="$MODULES rndis_wlan rndis_host cdc_ether usbnet"
^ permalink raw reply
* Re: [PATCH 1/2] rt2x00: Write the frame *after* padding (rt2800 usb devices)
From: Helmut Schaa @ 2010-12-20 10:30 UTC (permalink / raw)
To: Julian Calaby
Cc: Ismael Luceno, linux-wireless, Ivo Van Doorn,
Gertjan van Wingerde
In-Reply-To: <AANLkTi=0AkWAoNhgMbkjwQb5Byu6SVWmOaNWRYsacfU6@mail.gmail.com>
Am Montag, 20. Dezember 2010 schrieb Julian Calaby:
> On Mon, Dec 20, 2010 at 19:55, Helmut Schaa <helmut.schaa@googlemail.com> wrote:
> > Hi,
> >
> > Am Montag, 20. Dezember 2010 schrieb Ismael Luceno:
> >> Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
> >> ---
> >> drivers/net/wireless/rt2x00/rt2800usb.c | 7 ++++---
> >> 1 files changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> >> index 3e0205d..85185de 100644
> >> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> >> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> >> @@ -378,9 +378,10 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
> >> * | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB end pad |
> >> * |<------------- tx_pkt_len ------------->|
> >> */
> >> - rt2800_write_tx_data(entry, txdesc);
> >> - padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
> >> - memset(skb_put(entry->skb, padding_len), 0, padding_len);
> >> + padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
> >> + memset(skb_put(entry->skb, padding_len), 0, padding_len);
> >> +
> >> + rt2800_write_tx_data(entry, txdesc);
> >
> > Could you please explain this change in more detail please?
> > Why is it needed? rt2800_write_tx_data only adds the TXWI to the front of the
> > buffer, doing that before or after the padding doesn't make a difference, no?
>
> Semantically it makes more sense this way, why modify a entry before
> writing it - but maybe the issue is that the name of the function
> makes it's function ambiguous, maybe renaming it to something along
> the lines of "rt2800_prepend_TXWI" would make it's purpose clearer.
Correct.
Helmut
^ permalink raw reply
* Failing on timeout while stopping DMA channel
From: Bringfried Stecklum @ 2010-12-20 10:28 UTC (permalink / raw)
To: linux-wireless
Since updating the kernel to 2.6.36.1, I am getting "Failing on timeout while
stopping DMA channel" messages during suspend/hibernate. They seem to harmless
but I'd like to get rid of them. This is the dmesg part
Dec 20 11:01:26 extragalactix kernel: [96861.854138] wlan0: deauthenticating
from 00:15:0c:be:e3:d0 by local choice (reason=3)
Dec 20 11:01:26 extragalactix kernel: [96861.900288] cfg80211: Calling CRDA to
update world regulatory domain
Dec 20 11:01:26 extragalactix dhcpcd[2468]: wlan0: carrier lost
Dec 20 11:01:26 extragalactix kernel: [96862.006292] iwlagn 0000:0c:00.0:
Failing on timeout while stopping DMA channel 1 [0xa5a5a5a2]
Dec 20 11:01:26 extragalactix kernel: [96862.006292] iwlagn 0000:0c:00.0:
Failing on timeout while stopping DMA channel 3 [0xa5a5a5a2]
Dec 20 11:01:26 extragalactix kernel: [96862.006292] iwlagn 0000:0c:00.0:
Failing on timeout while stopping DMA channel 4 [0xa5a5a5a2]
Dec 20 11:01:26 extragalactix kernel: [96862.006292] iwlagn 0000:0c:00.0:
Failing on timeout while stopping DMA channel 6 [0xa5a5a5a2]
Dec 20 11:01:26 extragalactix kernel: [96862.151195] iwlagn 0000:0c:00.0: PCI
INT A disabled
Dec 20 11:01:26 extragalactix dhcpcd[2468]: wlan0: del_route: No such device
Dec 20 11:01:26 extragalactix dhcpcd[2468]: del_address: No such device
Dec 20 11:01:26 extragalactix dhcpcd[2468]: manage_link: No such device or address
Dec 20 11:01:26 extragalactix dhcpcd[2468]: wlan0: removing interface
Dec 20 11:01:28 extragalactix dhcpcd[5849]: dhcpcd not running
Dec 20 11:01:28 extragalactix kernel: [96864.320479] tg3 0000:09:00.0: irq 41
for MSI/MSI-X
Dec 20 11:01:28 extragalactix dhcpcd[5854]: dhcpcd not running
Dec 20 11:01:28 extragalactix kernel: [96864.480575] tg3 0000:09:00.0: irq 41
for MSI/MSI-X
Dec 20 11:02:34 extragalactix acpid: client 4558[0:0] has disconnected
Dec 20 11:02:35 extragalactix kernel: [96865.301314] PM: Syncing filesystems ...
done.
Dec 20 11:02:35 extragalactix kernel: [96865.309300] Freezing user space
processes ... (elapsed 0.01 seconds) done.
^ permalink raw reply
* RE: smatch stuff: potential read past the end of the buffer
From: Arend Van Spriel @ 2010-12-20 10:16 UTC (permalink / raw)
To: Dan Carpenter, Vasanthakumar Thiagarajan
Cc: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <20101220083041.GQ1936@bicker>
Hi Dan,
Why not use min() function?
index = min(COMP_HDR_LEN + osize, 2046);
mchecksum = word[index] |
(word[index + 1] << 8);
Or would smatch miss this in its analysis?
Gr. AvS
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] On Behalf Of Dan Carpenter [error27@gmail.com]
Sent: Monday, December 20, 2010 9:30 AM
To: Vasanthakumar Thiagarajan
Cc: linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org
Subject: smatch stuff: potential read past the end of the buffer
Hello Vasanthakumar,
Smatch complains that in linux-next 60e0c3a7 "ath9k_hw: Eeeprom changes
for AR9485" means there is a potential read past the end of the buffer
int ar9300_eeprom_restore_internal().
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
ar9300_eeprom_restore_internal(81)
error: buffer overflow 'word' 2048 <= 4099
"word" is allocated with 2048 bytes:
word = kzalloc(2048, GFP_KERNEL);
"length" can be up to 4099:
if ((!AR_SREV_9485(ah) && length >= 1024) ||
(AR_SREV_9485(ah) && length >= (4 * 1024))) {
^^^^^^^^^^^^^^^^^^^^^
so "osize" can be up to 4099 as well:
osize = length;
We're reading way past the end of the word array here:
mchecksum = word[COMP_HDR_LEN + osize] |
^^^^^^^^^^^^^^^^^^^^^^^^^^
(word[COMP_HDR_LEN + osize + 1] << 8);
I don't know how to fix this. Can you take a look?
regards,
dan carpenter
--
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
* Re: [PATCH 1/2] rt2x00: Write the frame *after* padding (rt2800 usb devices)
From: Julian Calaby @ 2010-12-20 9:30 UTC (permalink / raw)
To: Helmut Schaa
Cc: Ismael Luceno, linux-wireless, Ivo Van Doorn,
Gertjan van Wingerde
In-Reply-To: <201012200955.22087.helmut.schaa@googlemail.com>
On Mon, Dec 20, 2010 at 19:55, Helmut Schaa <helmut.schaa@googlemail.com> wrote:
> Hi,
>
> Am Montag, 20. Dezember 2010 schrieb Ismael Luceno:
>> Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
>> ---
>> drivers/net/wireless/rt2x00/rt2800usb.c | 7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
>> index 3e0205d..85185de 100644
>> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
>> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
>> @@ -378,9 +378,10 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
>> * | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB end pad |
>> * |<------------- tx_pkt_len ------------->|
>> */
>> - rt2800_write_tx_data(entry, txdesc);
>> - padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
>> - memset(skb_put(entry->skb, padding_len), 0, padding_len);
>> + padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
>> + memset(skb_put(entry->skb, padding_len), 0, padding_len);
>> +
>> + rt2800_write_tx_data(entry, txdesc);
>
> Could you please explain this change in more detail please?
> Why is it needed? rt2800_write_tx_data only adds the TXWI to the front of the
> buffer, doing that before or after the padding doesn't make a difference, no?
Semantically it makes more sense this way, why modify a entry before
writing it - but maybe the issue is that the name of the function
makes it's function ambiguous, maybe renaming it to something along
the lines of "rt2800_prepend_TXWI" would make it's purpose clearer.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: smatch stuff: potential read past the end of the buffer
From: Senthil Balasubramanian @ 2010-12-20 9:26 UTC (permalink / raw)
To: Dan Carpenter
Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org
In-Reply-To: <20101220083041.GQ1936@bicker>
On Mon, Dec 20, 2010 at 02:00:41PM +0530, Dan Carpenter wrote:
> Hello Vasanthakumar,
>
> Smatch complains that in linux-next 60e0c3a7 "ath9k_hw: Eeeprom changes
> for AR9485" means there is a potential read past the end of the buffer
> int ar9300_eeprom_restore_internal().
>
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
> ar9300_eeprom_restore_internal(81)
> error: buffer overflow 'word' 2048 <= 4099
>
> "word" is allocated with 2048 bytes:
> word = kzalloc(2048, GFP_KERNEL);
>
> "length" can be up to 4099:
> if ((!AR_SREV_9485(ah) && length >= 1024) ||
> (AR_SREV_9485(ah) && length >= (4 * 1024))) {
> ^^^^^^^^^^^^^^^^^^^^^
>
> so "osize" can be up to 4099 as well:
> osize = length;
>
> We're reading way past the end of the word array here:
> mchecksum = word[COMP_HDR_LEN + osize] |
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> (word[COMP_HDR_LEN + osize + 1] << 8);
>
> I don't know how to fix this. Can you take a look?
thanks for pointing this out. we shall look into this.
>
> regards,
> dan carpenter
>
> --
> 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
* [PATCH v2 1/2] ath9k: Fix warnings on card removal
From: Rajkumar Manoharan @ 2010-12-20 9:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Rajkumar Manoharan
The recently added warning message on power change failure
is not needed on device removal.
ath: Failed to wakeup in 500us
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/hw.c:1618
ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]()
Hardware name: 64756D6
Pid: 540, comm: kworker/u:3 Not tainted 2.6.37-rc6-wl #37
Call Trace:
[<ffffffff810501aa>] warn_slowpath_common+0x7a/0xb0
[<ffffffffa056e280>] ? ath9k_iowrite32+0x0/0x90 [ath9k]
[<ffffffff810501f5>] warn_slowpath_null+0x15/0x20
[<ffffffffa05226ef>] ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]
[<ffffffffa05700e5>] ath9k_ps_wakeup+0x85/0xd0 [ath9k]
[<ffffffffa0570685>] ath9k_configure_filter+0x25/0x80 [ath9k]
[<ffffffffa04dde43>] ieee80211_configure_filter+0x133/0x190 [mac80211]
[<ffffffffa04ee502>] ieee80211_do_stop+0x132/0x540 [mac80211]
[<ffffffff813466ff>] ? _raw_spin_unlock_bh+0x1f/0x30
[<ffffffff812b6923>] ? dev_deactivate+0x1c3/0x1e0
[<ffffffffa04ee925>] ieee80211_stop+0x15/0x20 [mac80211]
[<ffffffff8129d1b6>] __dev_close+0x56/0x90
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
v2: handled module unload
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/init.c | 2 ++
drivers/net/wireless/ath/ath9k/pci.c | 2 ++
drivers/net/wireless/ath/ath9k/recv.c | 3 ++-
4 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index b0b1216..c0f6222 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -666,6 +666,7 @@ extern struct ieee80211_ops ath9k_ops;
extern int modparam_nohwcrypt;
extern int led_blink;
extern int ath9k_pm_qos_value;
+extern bool is_ath9k_unloaded;
irqreturn_t ath_isr(int irq, void *dev);
int ath9k_init_device(u16 devid, struct ath_softc *sc, u16 subsysid,
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 1238795..3a8a4c6 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -45,6 +45,7 @@ int ath9k_pm_qos_value = ATH9K_PM_QOS_DEFAULT_VALUE;
module_param_named(pmqos, ath9k_pm_qos_value, int, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(pmqos, "User specified PM-QOS value");
+bool is_ath9k_unloaded;
/* We use the hw_value as an index into our private channel structure */
#define CHAN2G(_freq, _idx) { \
@@ -898,6 +899,7 @@ module_init(ath9k_init);
static void __exit ath9k_exit(void)
{
+ is_ath9k_unloaded = true;
ath_ahb_exit();
ath_pci_exit();
ath_rate_control_unregister();
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 7ca8499..3eb938d 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -264,6 +264,8 @@ static void ath_pci_remove(struct pci_dev *pdev)
struct ath_softc *sc = aphy->sc;
void __iomem *mem = sc->mem;
+ if (!is_ath9k_unloaded)
+ sc->sc_ah->ah_flags |= AH_UNPLUGGED;
ath9k_deinit_device(sc);
free_irq(sc->irq, sc);
ieee80211_free_hw(sc->hw);
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 00ebed3..b2497b8 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -528,7 +528,8 @@ bool ath_stoprecv(struct ath_softc *sc)
sc->rx.rxlink = NULL;
spin_unlock_bh(&sc->rx.rxbuflock);
- if (unlikely(!stopped)) {
+ if (!(ah->ah_flags & AH_UNPLUGGED) &&
+ unlikely(!stopped)) {
ath_err(ath9k_hw_common(sc->sc_ah),
"Could not stop RX, we could be "
"confusing the DMA engine when we start RX up\n");
--
1.7.3.3
^ permalink raw reply related
* Re: [PATCH 1/2] rt2x00: Write the frame *after* padding (rt2800 usb devices)
From: Helmut Schaa @ 2010-12-20 8:55 UTC (permalink / raw)
To: Ismael Luceno; +Cc: linux-wireless, Ivo Van Doorn, Gertjan van Wingerde
In-Reply-To: <1292833909-20138-1-git-send-email-ismael.luceno@gmail.com>
Hi,
Am Montag, 20. Dezember 2010 schrieb Ismael Luceno:
> Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 3e0205d..85185de 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -378,9 +378,10 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
> * | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB end pad |
> * |<------------- tx_pkt_len ------------->|
> */
> - rt2800_write_tx_data(entry, txdesc);
> - padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
> - memset(skb_put(entry->skb, padding_len), 0, padding_len);
> + padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
> + memset(skb_put(entry->skb, padding_len), 0, padding_len);
> +
> + rt2800_write_tx_data(entry, txdesc);
Could you please explain this change in more detail please?
Why is it needed? rt2800_write_tx_data only adds the TXWI to the front of the
buffer, doing that before or after the padding doesn't make a difference, no?
Thanks,
Helmut
^ permalink raw reply
* [PATCH 2/2] rt2x00: Fix panic on frame padding for rt2800 usb devices (due to not enough skb tailroom)
From: Ismael Luceno @ 2010-12-20 8:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Ivo Van Doorn, Gertjan van Wingerde, Ismael Luceno
In-Reply-To: <1292833909-20138-1-git-send-email-ismael.luceno@gmail.com>
Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 85185de..d284e1e 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -369,7 +369,8 @@ static void rt2800usb_write_tx_desc(struct queue_entry *entry,
static void rt2800usb_write_tx_data(struct queue_entry *entry,
struct txentry_desc *txdesc)
{
- u8 padding_len;
+ unsigned int padding_len;
+ int err;
/*
* pad(1~3 bytes) is added after each 802.11 payload.
@@ -379,8 +380,14 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
* |<------------- tx_pkt_len ------------->|
*/
padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
- memset(skb_put(entry->skb, padding_len), 0, padding_len);
+ err = skb_pad(entry->skb, padding_len);
+ if (unlikely(err)) {
+ WARNING(entry->queue->rt2x00dev, "TX SKB padding error, out of memory\n");
+ return;
+ }
+
+ entry->skb->len += padding_len;
rt2800_write_tx_data(entry, txdesc);
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] rt2x00: Write the frame *after* padding (rt2800 usb devices)
From: Ismael Luceno @ 2010-12-20 8:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Ivo Van Doorn, Gertjan van Wingerde, Ismael Luceno
Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 3e0205d..85185de 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -378,9 +378,10 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
* | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB end pad |
* |<------------- tx_pkt_len ------------->|
*/
- rt2800_write_tx_data(entry, txdesc);
- padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
- memset(skb_put(entry->skb, padding_len), 0, padding_len);
+ padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
+ memset(skb_put(entry->skb, padding_len), 0, padding_len);
+
+ rt2800_write_tx_data(entry, txdesc);
}
/*
--
1.7.3.4
^ 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