* Bringing up a virtual wiphy on AR9160 brings down the node
From: Javier Cardona @ 2010-07-01 23:30 UTC (permalink / raw)
To: ath9k-devel; +Cc: linux-wireless
Hi all,
We are trying to bring up two virtual wiphys on an AR9160 with not luck.
Creation succeeds, but bringin up an interface on either wihpy locks up the
target in what appears to be an infinite loop of warnings. More details follow:
- Hardware
phy0: Atheros AR9160 MAC/BB Rev:0 AR5133 RF Rev:b0 mem=0xc8d20000, irq=5
- Wiphy creation
# echo add >> /sys/kernel/debug/ath9k/phy0/wiphy
# cat /sys/kernel/debug/ath9k/phy0/wiphy
primary: phy0 (INACTIVE chan=0 ht=0)
secondary: phy1 (INACTIVE chan=0 ht=0)
addr: 00:00:00:00:00:00
addrmask: ff:ff:ff:ff:ff:ff
- Bring up interface
iwconfig wlan0 essid cozyssid1
ifconfig wlan0 up
Device locks up. Logs at the bottom of this e-mail.
- Versions tested
version d41229637fb42737ff792271b8f0ac9752de9cb8 (wireless-testing
HEAD as of jun 30 2010)
version 062bee448bd539580ef9f64efe50fdfe04eeb103 (wireless-2.6 HEAD as
of jun 30 2010)
version e40152ee1e1c7a63f4777791863215e3faa37a86 (linux-2.6 v2.6.34 )
We have a dedicated target for this, so we can quickly test patches or
diffent kernel versions.
Does anyone know if virtual wiphys should work on the AR9160 ?
Thanks!
Javier
== Log for wireless-testing kernel d41229637fb42737ff792271b8f0ac9752de9cb8 ==
Jul 1 15:56:52 192.168.1.89 [ 625.948014] Pid: 657, comm: udevd
Tainted: G W 2.6.35-rc3-wl+ #36
Jul 1 15:56:52 192.168.1.89 [ 625.948523] Call Trace:
Jul 1 15:56:52 192.168.1.89 [ 625.949019] [<c022159d>]
warn_slowpath_common+0x65/0x7a
Jul 1 15:56:52 192.168.1.89 [ 625.949779] [<c8d4db4f>] ?
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:52 192.168.1.89 [ 625.950459] [<c02215c1>]
warn_slowpath_null+0xf/0x13
Jul 1 15:56:53 192.168.1.89 [ 625.951321] [<c8d4db4f>]
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 [ 625.952010] [<c0503ec5>] ? skb_copy+0x2e/0x83
Jul 1 15:56:53 192.168.1.89 [ 625.952506] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 [ 625.953135] [<c0503f10>] ? skb_copy+0x79/0x83
Jul 1 15:56:53 192.168.1.89 [ 625.953697] [<c8f43545>]
ath_rx_send_to_mac80211+0x47/0x60 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 625.954440] [<c8f445f9>]
ath_rx_tasklet+0xb1a/0xbc7 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 625.955110] [<c0296115>] ?
do_sync_write+0x89/0xc4
Jul 1 15:56:53 192.168.1.89 [ 625.987465] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 [ 626.037154] [<c0503ec5>] ? skb_copy+0x2e/0x83
Jul 1 15:56:53 192.168.1.89 cfg80211
Jul 1 15:56:53 192.168.1.89 [ 626.129764] [<c0202c69>]
common_interrupt+0x29/0x30
Jul 1 15:56:53 192.168.1.89 [ 626.173011] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 [ 626.214305] [<c02034b7>] do_IRQ+0x61/0x74
Jul 1 15:56:53 192.168.1.89 [ 626.259421] [<c8f43545>]
ath_rx_send_to_mac80211+0x47/0x60 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 626.307313] [<c8d4db4f>]
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 ath9k_common
Jul 1 15:56:53 192.168.1.89 [ 626.426786] [<c02259fa>] do_softirq+0x25/0x2a
Jul 1 15:56:53 192.168.1.89 [ 626.482399] [<c02034b7>] do_IRQ+0x61/0x74
Jul 1 15:56:53 192.168.1.89 [ 626.542467] [<c0503ec5>] ? skb_copy+0x2e/0x83
Jul 1 15:56:53 192.168.1.89 [ 626.599719] [<c02259fa>] do_softirq+0x25/0x2a
Jul 1 15:56:53 192.168.1.89 [ 626.658443] [<c8d4db4f>] ?
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 [ 626.713817] [<c0503f10>] ? skb_copy+0x79/0x83
Jul 1 15:56:53 192.168.1.89 [ 626.763933] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 ath
Jul 1 15:56:53 192.168.1.89 [ 626.863347] [<c8d4db4f>] ?
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 [ 626.916466] [<c0503ec5>] ? skb_copy+0x2e/0x83
Jul 1 15:56:53 192.168.1.89 [ 626.966157] [<c8d4db4f>]
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 [ 627.021193] [<c8f4072f>] ?
ath9k_iowrite32+0x36/0x3a [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.073978] [<c02259fa>] do_softirq+0x25/0x2a
Jul 1 15:56:53 192.168.1.89 [ 627.129802] WARNING: at
net/mac80211/rx.c:2615 ieee80211_rx+0x64/0x72d [mac80211]()
Jul 1 15:56:53 192.168.1.89 [ 627.186867] [<c8d4db4f>]
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 [ 627.242171] [<c8f445f9>]
ath_rx_tasklet+0xb1a/0xbc7 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.293765] [<c8f4072f>] ?
ath9k_iowrite32+0x36/0x3a [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.341849] [<c0503f10>] ? skb_copy+0x79/0x83
Jul 1 15:56:53 192.168.1.89 [ 627.386080] Hardware name: Uknown
Jul 1 15:56:53 192.168.1.89 [ 627.430741] [<c02250e8>]
tasklet_action+0x40/0x67
Jul 1 15:56:53 192.168.1.89 [ 627.477316] [<c0503ec5>] ? skb_copy+0x2e/0x83
Jul 1 15:56:53 192.168.1.89 [ 627.517866] [<c02259fa>] do_softirq+0x25/0x2a
Jul 1 15:56:53 192.168.1.89 [ 627.554554] ------------[ cut here
]------------
Jul 1 15:56:53 192.168.1.89 [ 627.585662] [<c0225933>]
__do_softirq+0x91/0x133
Jul 1 15:56:53 192.168.1.89 [ 627.616025] [<c8f445f9>]
ath_rx_tasklet+0xb1a/0xbc7 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.648940] [<c8f43545>]
ath_rx_send_to_mac80211+0x47/0x60 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.683115] [<c8f445f9>]
ath_rx_tasklet+0xb1a/0xbc7 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.715819] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 [ 627.749672] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 [ 627.782008] [<c8d4db4f>]
ieee80211_rx+0x64/0x72d [mac80211]
Jul 1 15:56:53 192.168.1.89 [ 627.811240] Hardware name: Uknown
Jul 1 15:56:53 192.168.1.89 [ 627.837036] [<c8f445f9>]
ath_rx_tasklet+0xb1a/0xbc7 [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.865451] [<c022159d>]
warn_slowpath_common+0x65/0x7a
Jul 1 15:56:53 192.168.1.89 [ 627.894958] WARNING: at
net/mac80211/rx.c:2615 ieee80211_rx+0x64/0x72d [mac80211]()
Jul 1 15:56:53 192.168.1.89 [ 627.923736] [<c8f4278f>]
ath9k_tasklet+0x8f/0x11f [ath9k]
Jul 1 15:56:53 192.168.1.89 [ 627.953563] [<c050195a>] ?
copy_skb_header+0x1b/0x7a
Jul 1 15:56:53 192.168.1.89 [ 627.985001] [<c02215c1>]
warn_slowpath_null+0xf/0x13
Jul 1 15:56:53 192.168.1.89 [ 628.019969] [<c0503ec5>] ? skb_copy+0x2e/0x83
Jul 1 15:56:53 192.168.1.89 [ 628.055442] [<c0503f10>] ? skb_copy+0x79/0x83
Jul 1 15:56:53 192.168.1.89 [ 628.093201] [<c0225933>]
__do_softirq+0x91/0x133
Jul 1 15:56:53 192.168.1.89 ath9k_common
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-01
From: David Miller @ 2010-07-02 0:35 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100701181526.GA2356@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 1 Jul 2010 14:15:27 -0400
> Two weeks since the last request, plenty of new stuff intended for
> 2.6.36...
>
> Included are the usual bunch of driver updates, including a big
> dump from the rt2x00 team. This also includes cfg80211 support
> for libertas, a flurry of (mostly trivial) stuff from me, and a
> wireless-2.6 pull to resolve some patch dependencies.
>
> Please let me know if there are problems!
This failed to pull cleanly, I got a conflict in
drivers/net/wireless/libertas/host.h It was the
usual "__packed" vs. "__attribute__((packed))" thing.
I resolved it but I wonder if this happened because you
did the wireless-2.6 --> wireless-next-2.6 merge here.
^ permalink raw reply
* Re: Setting multicast rate
From: jpo234 @ 2010-07-02 7:44 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4C2C42B6.3050503@googlemail.com>
Dennis Borgmann <dennis.borgmann@...> writes:
> Do you plan to introduce an option for setting the multicast rate? My
> question is especially about ath5k. In madwifi, there was an iwpriv so
> set this rate.
Seconded!
^ permalink raw reply
* Re: wl1271 firmware
From: max @ 2010-07-02 9:47 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AC090B9732AB2B4DB7FF476E907FE660010673660C@dnce02.ent.ti.com>
Levi, Shahar <shahar_levi@...> writes:
> I am checking the way to access the FW and NVS file of wl1271.
> Let me find more details on that and get back to you.
Hi I'm also searching for that file
Please let me know when it will be available
thanks
^ permalink raw reply
* Re: wl1271 firmware
From: mastupristi @ 2010-07-02 9:54 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AC090B9732AB2B4DB7FF476E907FE660010673660C@dnce02.ent.ti.com>
Levi, Shahar <shahar_levi@...> writes:
> Hi pz,
> I am checking the way to access the FW and NVS file of wl1271.
> Let me find more details on that and get back to you.
Hi all,
I have the same problem searching wl1271-nvs.bin.
I hope that it will be possible to find it.
Please I would like to have your feedback
best regards,
bye
^ permalink raw reply
* [PATCH] ath9k: fix crash with WEP in ad-hoc mode
From: Felix Fietkau @ 2010-07-02 12:45 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Luis R. Rodriguez, Senthil Balasubramanian
Commit eed8e22f0133e8278b1f8079fcb452f1f9692f9d added support for using
multicast key lookup to support per-vif/sta keys for AP and ad-hoc.
Unfortunately, it also introduced a crash in ad-hoc mode when the sta
pointer is NULL, which happens when setting up an interface with WEP
keys. This patch fixes it by falling back to the assigned key index.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -319,6 +319,10 @@ int ath9k_cmn_key_config(struct ath_comm
idx = ath_reserve_key_cache_slot(common, key->alg);
break;
case NL80211_IFTYPE_ADHOC:
+ if (!sta) {
+ idx = key->keyidx;
+ break;
+ }
memcpy(gmac, sta->addr, ETH_ALEN);
gmac[0] |= 0x01;
mac = gmac;
^ permalink raw reply
* Re: Question on 'iw reg get/set'
From: John W. Linville @ 2010-07-02 14:12 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4C2CFAEB.9070302@candelatech.com>
On Thu, Jul 01, 2010 at 01:30:35PM -0700, Ben Greear wrote:
> I'm using an ath9k NIC on a slightly hacked 2.6.34 kernel, Fedora 13 32-bit.
> I'm using the stock 'iw' command that comes with Fedora 13.
>
> As far as I can tell, the results of 'iw reg get'
> are funky:
>
> [root@atom lanforge]# iw reg get
> country 98:
> (2402 - 2472 @ 40), (N/A, 20)
> (5170 - 5250 @ 20), (N/A, 17)
> (5250 - 5330 @ 20), (N/A, 18), DFS
>
> What is '98'? It doesn't correspond to anything I can find
> in the numeric or ascii lists of country codes.
>
> Also, setting the domain doesn't seem to do anything, although
> there are no errors:
>
> [root@atom lanforge]# iw reg get
> country 98:
> (2402 - 2472 @ 40), (N/A, 20)
> (5170 - 5250 @ 20), (N/A, 17)
> (5250 - 5330 @ 20), (N/A, 18), DFS
> [root@atom lanforge]# iw reg set US
> [root@atom lanforge]# iw reg get
> country 98:
> (2402 - 2472 @ 40), (N/A, 20)
> (5170 - 5250 @ 20), (N/A, 17)
> (5250 - 5330 @ 20), (N/A, 18), DFS
>
> Anyone know if this is *supposed* to work?
The ath9k driver is setting its own regulatory restrictions based on
its EEPROM. Setting the domain from userland can only further restrict
the regulatory settings. The '98' value represents a synthesized
regulatory domain, based on the intersection of the available source
of regulatory information (which can include the EEPROM, the userland
setting, and a country IE from your AP).
Hth!
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: pull request: wireless-next-2.6 2010-07-01
From: John W. Linville @ 2010-07-02 14:08 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100701.173550.172604489.davem@davemloft.net>
On Thu, Jul 01, 2010 at 05:35:50PM -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Thu, 1 Jul 2010 14:15:27 -0400
>
> > Two weeks since the last request, plenty of new stuff intended for
> > 2.6.36...
> >
> > Included are the usual bunch of driver updates, including a big
> > dump from the rt2x00 team. This also includes cfg80211 support
> > for libertas, a flurry of (mostly trivial) stuff from me, and a
> > wireless-2.6 pull to resolve some patch dependencies.
> >
> > Please let me know if there are problems!
>
> This failed to pull cleanly, I got a conflict in
> drivers/net/wireless/libertas/host.h It was the
> usual "__packed" vs. "__attribute__((packed))" thing.
>
> I resolved it but I wonder if this happened because you
> did the wireless-2.6 --> wireless-next-2.6 merge here.
Sorry, Dave! I probably should have done 'for-davem' branch for you.
Thanks for resolving it!
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
* How to get the current queue length of a wireless device?
From: Zhongliang Zhao @ 2010-07-02 14:20 UTC (permalink / raw)
To: linux-wireless; +Cc: peter.dely, staub
Hi all,
We are currently porting the Net-X framework [University of Illinois,
Urbana-Champaign] (multi-channel framework) to recent Linux kernels (>=
2.6.34) with the new wireless drivers (ath5k etc.). In corporation with
University of Karlstad, we have already ported the framework from 2.4
kernels to 2.6.18 using the madwifi drivers.
Now, we want to produce more generic code and therefore use the new
wireless drivers / mac80211. The multi-channel framework is based on an
extension of the net bonding drivers, which combines multiple
radio/channel pairs to one single virtual device. In order to do the
scheduling, it requires knowledge about the current queue length of the
individual wireless device for appropriate scheduling. However, we found
that "get_tx_stats()" has been removed from mac80211. Which function
should we use for getting the queue length?
Any comment is welcome.
Thank you very much in advance.
Zhongliang and Thomas
--
Zhongliang Zhao, Research Assistant
Institute of Computer Science and Applied Mathematics
University of Bern, Neubrueckstrasse 10, CH-3012 Bern, Switzerland
Email: zhao@iam.unibe.ch
Phone: +41 (0)31 511 2639
Fax: +41 (0)31 631 3261
^ permalink raw reply
* Re: Problem with firmware load on ipw2200
From: Larry Finger @ 2010-07-02 16:08 UTC (permalink / raw)
To: Pavel Roskin; +Cc: wireless, John Linville
In-Reply-To: <1277876773.2536.5.camel@ct>
On 06/30/2010 12:46 AM, Pavel Roskin wrote:
> On Tue, 2010-06-29 at 08:37 -0500, Larry Finger wrote:
>> I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
>> stuck. The system is failing to load the firmware with error -2 (File or
>> directory not found). The difficulty is that the required files are
>> present with the correct permissions.
>>
>> What system component might be missing and/or borked to get this symptom?
>
> Older versions of compat-wireless had a race condition in the firmware
> code that could cause that. From the log of the compat repository:
Thanks to all that responded. The problem turned out to be a missing
package that contained the compat-wireless scripts. The device is now
running - another satisfied "customer" that just converted his wife from
Windows to Linux. We get em one box at a time.
Larry
^ permalink raw reply
* Re: iwlwifi and 802.11s
From: Guy, Wey-Yi @ 2010-07-02 16:08 UTC (permalink / raw)
To: Iuri Diniz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTim89kFmpafv2UsmanpiysGw8W1nfKZGXPsjPpXZ@mail.gmail.com>
Hi Iuri,
Yes, it is possible to add "mesh" support to iwlwifi, but currently it
is not in our (Intel) schedule to enable/support this feature.
If you or anybody from community would like to implement and support
this feature, it is very welcome and we will consider the patches for
inclusion, but base on few requirements:
* We assume the patches make "mesh" works since we are not testing the
mesh functions
* The mesh feature should not break any of the normal WiFi operations
which we _do_ test for
* Since we are not testing the "mesh" function and would rely on the
author to resolve any issues. We will disable the feature if "mesh"
break any of the normal WiFi operation and both ourselves and the author
are not be able to address the issues.
The best place to start is base on the latest iwlwifi driver which you
can find in the following location:
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=summary
Good luck and looking forward for your patches.
Thanks
Wey
On Thu, 2010-07-01 at 08:29 -0700, Iuri Diniz wrote:
> Is possible to add mesh support to iwlwifi (I have a intel wireless
> 4965AGN hardware) ?
>
> if so, where can I get start?
> is this information
> http://linuxwireless.org/en/developers/Documentation/mac80211/API
> sufficient?
>
> thanks in advance.
>
^ permalink raw reply
* Re: Question on 'iw reg get/set'
From: Ben Greear @ 2010-07-02 16:42 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100702141216.GB2381@tuxdriver.com>
On 07/02/2010 07:12 AM, John W. Linville wrote:
> On Thu, Jul 01, 2010 at 01:30:35PM -0700, Ben Greear wrote:
>> I'm using an ath9k NIC on a slightly hacked 2.6.34 kernel, Fedora 13 32-bit.
>> I'm using the stock 'iw' command that comes with Fedora 13.
>>
>> As far as I can tell, the results of 'iw reg get'
>> are funky:
>>
>> [root@atom lanforge]# iw reg get
>> country 98:
>> (2402 - 2472 @ 40), (N/A, 20)
>> (5170 - 5250 @ 20), (N/A, 17)
>> (5250 - 5330 @ 20), (N/A, 18), DFS
>>
>> What is '98'? It doesn't correspond to anything I can find
>> in the numeric or ascii lists of country codes.
>>
>> Also, setting the domain doesn't seem to do anything, although
>> there are no errors:
>>
>> [root@atom lanforge]# iw reg get
>> country 98:
>> (2402 - 2472 @ 40), (N/A, 20)
>> (5170 - 5250 @ 20), (N/A, 17)
>> (5250 - 5330 @ 20), (N/A, 18), DFS
>> [root@atom lanforge]# iw reg set US
>> [root@atom lanforge]# iw reg get
>> country 98:
>> (2402 - 2472 @ 40), (N/A, 20)
>> (5170 - 5250 @ 20), (N/A, 17)
>> (5250 - 5330 @ 20), (N/A, 18), DFS
>>
>> Anyone know if this is *supposed* to work?
>
> The ath9k driver is setting its own regulatory restrictions based on
> its EEPROM. Setting the domain from userland can only further restrict
> the regulatory settings. The '98' value represents a synthesized
> regulatory domain, based on the intersection of the available source
> of regulatory information (which can include the EEPROM, the userland
> setting, and a country IE from your AP).
Is there any way to get/set these raw settings (like, whatever it has in EEPROM)?
I expect we may ship some of these systems overseas, and would like the flexibility
to set the country-code for testing purposes, if nothing else.
Is there any documentation as to what '98' really means, or do we just ignore that
value and look at the info printed out after that?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Question on 'iw reg get/set'
From: John W. Linville @ 2010-07-02 16:48 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4C2E170E.6040207@candelatech.com>
On Fri, Jul 02, 2010 at 09:42:54AM -0700, Ben Greear wrote:
> On 07/02/2010 07:12 AM, John W. Linville wrote:
> >The ath9k driver is setting its own regulatory restrictions based on
> >its EEPROM. Setting the domain from userland can only further restrict
> >the regulatory settings. The '98' value represents a synthesized
> >regulatory domain, based on the intersection of the available source
> >of regulatory information (which can include the EEPROM, the userland
> >setting, and a country IE from your AP).
>
> Is there any way to get/set these raw settings (like, whatever it has in EEPROM)?
>
> I expect we may ship some of these systems overseas, and would like the flexibility
> to set the country-code for testing purposes, if nothing else.
I'll leave it to the Atheros guys to address this.
> Is there any documentation as to what '98' really means, or do we just ignore that
> value and look at the info printed out after that?
'98' pretty much means "look at the info" :-)
--
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: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Johannes Berg @ 2010-07-02 17:12 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <201006272100.22216.helmut.schaa@googlemail.com>
On Sun, 2010-06-27 at 21:00 +0200, Helmut Schaa wrote:
> rt2x00 pulls every beacon. But not directly _prior_ to transmission as the
> hw lacks an interrupt for that. Instead the next beacon gets pulled _after_
> the beacondone interrupt (which is obviously triggered directly after the
> beacon was sent). So, all TIM changes that happen during the next beacon
> interval won't be included in the next beacon. Hence, rt2x00 also implements
> the set_tim callback and updates the beacon through these as well.
>
> This gives us a correct TIM but as I explained earlier breaks the DTIM
> count (and thus bc/mc buffering which is done in mac80211 fot rt2x00).
>
> One possible option to fix this in rt2x00 would be to delay the beacon
> update (as it is already put on a workqueue we could simply replace it by
> a delayed work) by beaconinterval - 10ms or something. But I'm not how
> accurate that would be (and of course remove the set_tim callback).
Well, after a beacon is before a beacon. I think iwlwifi also pulls the
next beacon after the previous one was sent. That just means you get a
potential higher delay, but otherwise it doesn't really matter that
much. You'll never be able to close the race fully anyway, unless your
device itself is capable of generating the TIM IE _right before_ the
beacon gets transmitted.
Therefore, with standard beacon intervals of 100 TU, I don't think it
matters all that much whether it's before or after?
johannes
^ permalink raw reply
* Re: [PATCH 2.6.34] mac80211: Fix auth retries if AP sends temporary deauth
From: Johannes Berg @ 2010-07-02 17:21 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, Michael Wu, Jiri Benc, John W. Linville
In-Reply-To: <AANLkTilV1t1737ciSPyyETeBEcN_QXsYxgEwpZIIucR2@mail.gmail.com>
On Thu, 2010-07-01 at 10:21 -0700, Paul Stewart wrote:
> This bypasses destruction of BSS state if a temporary DEAUTH packet is
> received while performing an AUTH. This will allow the retry mechanism
> (which runs regardless of this patch) to succeed, since we do not remove
> the BSS state which is required to complete authentication on the client
> side in cfg80211_send_rx_auth().
>
> The specific case handled here is "Previous authentication no longer
> valid", which is usually generated by an AP if the AP still has saved
> state of the STA being authenticated. Usually a retry will be successful.
You don't usually send patches to stable, you send them to the current
tree with a cc stable tag, and then they get picked up.
I'm going to look at the problem now, I'm still not really convinced by
this.
johannes
^ permalink raw reply
* Re: [PATCH 2.6.34] mac80211: Fix auth retries if AP sends temporary deauth
From: Johannes Berg @ 2010-07-02 17:29 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, Michael Wu, Jiri Benc, John W. Linville
In-Reply-To: <AANLkTilV1t1737ciSPyyETeBEcN_QXsYxgEwpZIIucR2@mail.gmail.com>
On Thu, 2010-07-01 at 10:21 -0700, Paul Stewart wrote:
> @@ -1030,6 +1030,25 @@ ieee80211_rx_result
> ieee80211_work_rx_mgmt(struct ieee80211_sub_if_data *sdata,
> skb_queue_tail(&local->work_skb_queue, skb);
> ieee80211_queue_work(&local->hw, &local->work_work);
> return RX_QUEUED;
> + case IEEE80211_STYPE_DEAUTH:
> + /*
> + * If we get sent a DEAUTH while we are
> + * actively trying to authenticate to this
> + * station, we shoot ourselves in the foot if
> + * we fall through using RX_CONTINUE and allow
> + * the bss context to disappear
> + * (ieee80211_sta_rx_mgmt()). This is
> + * especially true if the reason for the
> + * DEAUTH was a negative but temporary direct
> + * response to an AUTH attempt. Let the retry
> + * mechanism run its course instead.
> + */
> + reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
> + if (wk->type == IEEE80211_WORK_AUTH &&
> + reason_code == WLAN_REASON_PREV_AUTH_NOT_VALID) {
> + return RX_DROP_MONITOR;
> + }
> + break;
Ok, wow, I finally understand this patch, but is it weird!! You're
modifying work.c to avoid having the mlme.c code send this frame to
cfg80211? That's really confusing.
The real reason for this is that we send up the deauth frame even when
we're not even authenticated. This happens in mlme.c. Therefore, we
should improve the logic in ieee80211_sta_rx_queued_mgmt() to make sure
it only triggers when we're authenticated with the BSS?
Alternatively, since cfg80211 tracks this, it would be easier to modify
cfg80211_send_rx_auth() to not send the event to userspace in the !done
case I guess.
johannes
^ permalink raw reply
* How to enable channels 12,13?
From: Jaroslav Fojtik @ 2010-07-02 17:33 UTC (permalink / raw)
To: linux-wireless
Dears,
My device ignores channels 12,13, but they are allowed in our country.
Is it possible to shut down defective regdomain policy?
The proper regdomain is already set:
[ 5.809776] ath5k 0000:02:0a.0: registered as 'phy1'
[ 6.276736] ath: EEPROM regdomain: 0x36
.....
[ 5.152196] ath5k 0000:02:08.0: registered as 'phy0'
[ 5.749710] ath: EEPROM regdomain: 0x36
.....
[ 6.278376] ath5k phy1: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
[ 6.278440] ath5k phy1: RF5112B multiband radio found (0x36)
[ 6.278539] ath5k 0000:02:0b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 6.278679] ath5k 0000:02:0b.0: registered as 'phy2'
[ 6.745533] ath: EEPROM regdomain: 0x36
[ 6.745538] ath: EEPROM indicates we should expect a direct regpair map
[ 6.745547] ath: Country alpha2 being used: CZ
[ 6.745553] ath: Regpair used: 0x36
[ 6.745661] cfg80211: Calling CRDA for country: CZ
Strange ???
root@dvouramenna:~# iw reg get
country 00:
(2402 - 2472 @ 40), (6, 20)
(2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS
(2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
(5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
Hmmm?? What is it:
root@dvouramenna:~# iw reg set CZ
root@dvouramenna:~# iw reg get
country 00:
(2402 - 2472 @ 40), (6, 20)
(2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS
(2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
(5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
(5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS
Even attempt of rewriting regdomain shows that a device has proper
domain in EEPROM:
root@dvouramenna:~#ath_info -g 1:0 -w 0xfdee0000 regdomain 36
......................................
new GPIO CR 00000303 DO 00000001 DI 00000007
regdomain (0x00bf) := 0x0036
WARNING: The write function may easy brick your device or
violate state regulation on frequency usage.
Proceed on your own risk!
Shall I write the above value(s)? (y/n) y
pair 0: skipped, value already there
restoring GPIO CR 303 -> 3
But channels are somehow blocked from unknown reason.
regards
Jara
iw list:
Wiphy phy1
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Frequencies:
* 5180 MHz [36] (30.0 dBm)
* 5200 MHz [40] (30.0 dBm) (passive scanning, no IBSS)
* 5220 MHz [44] (30.0 dBm) (passive scanning, no IBSS)
* 5240 MHz [48] (30.0 dBm) (passive scanning, no IBSS)
* 5260 MHz [52] (30.0 dBm) (passive scanning, no IBSS, radar
detection)
* 5280 MHz [56] (30.0 dBm) (passive scanning, no IBSS, radar
detection)
* 5300 MHz [60] (30.0 dBm) (passive scanning, no IBSS, radar
detection)
* 5320 MHz [64] (30.0 dBm) (passive scanning, no IBSS, radar
detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (30.0 dBm) (passive scanning, no IBSS)
* 5765 MHz [153] (30.0 dBm) (passive scanning, no IBSS)
* 5785 MHz [157] (30.0 dBm) (passive scanning, no IBSS)
* 5805 MHz [161] (30.0 dBm) (passive scanning, no IBSS)
* 5825 MHz [165] (30.0 dBm) (passive scanning, no IBSS)
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* Unknown command (55)
* Unknown command (57)
* Unknown command (59)
* set_wiphy_netns
* Unknown command (65)
* connect
* disconnect
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* Unknown command (55)
* Unknown command (57)
* Unknown command (59)
* set_wiphy_netns
* Unknown command (65)
* connect
* disconnect
root@dvouramenna:~#
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Helmut Schaa @ 2010-07-02 17:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <1278090770.15412.4.camel@jlt3.sipsolutions.net>
Am Freitag 02 Juli 2010 schrieb Johannes Berg:
> On Sun, 2010-06-27 at 21:00 +0200, Helmut Schaa wrote:
>
> > rt2x00 pulls every beacon. But not directly _prior_ to transmission as the
> > hw lacks an interrupt for that. Instead the next beacon gets pulled _after_
> > the beacondone interrupt (which is obviously triggered directly after the
> > beacon was sent). So, all TIM changes that happen during the next beacon
> > interval won't be included in the next beacon. Hence, rt2x00 also implements
> > the set_tim callback and updates the beacon through these as well.
> >
> > This gives us a correct TIM but as I explained earlier breaks the DTIM
> > count (and thus bc/mc buffering which is done in mac80211 fot rt2x00).
> >
> > One possible option to fix this in rt2x00 would be to delay the beacon
> > update (as it is already put on a workqueue we could simply replace it by
> > a delayed work) by beaconinterval - 10ms or something. But I'm not how
> > accurate that would be (and of course remove the set_tim callback).
>
> Well, after a beacon is before a beacon.
Yes ;)
> I think iwlwifi also pulls the
> next beacon after the previous one was sent. That just means you get a
> potential higher delay,
Agreed.
> but otherwise it doesn't really matter that
> much. You'll never be able to close the race fully anyway,
No, but I'd like to get as close as possible. The idea with the delayed
work was intended to reduce the latency as good as we can.
> unless your
> device itself is capable of generating the TIM IE _right before_ the
> beacon gets transmitted.
Agreed. At least on rt2800 we can use the pre tbtt interrupt to update the
beacon just before it is sent out.
> Therefore, with standard beacon intervals of 100 TU, I don't think it
> matters all that much whether it's before or after?
Yeah, maybe that's just fine. I guess I'll just drop the set_tim callback
from all rt2x00 pci variants and implement the pre tbtt interrupt on rt2800.
Thanks,
Helmut
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Johannes Berg @ 2010-07-02 18:06 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <201007021959.45704.helmut.schaa@googlemail.com>
On Fri, 2010-07-02 at 19:59 +0200, Helmut Schaa wrote:
> > unless your
> > device itself is capable of generating the TIM IE _right before_ the
> > beacon gets transmitted.
>
> Agreed. At least on rt2800 we can use the pre tbtt interrupt to update the
> beacon just before it is sent out.
Careful though. You don't know how far in advance it is triggered (or
maybe you do) or if the time will be sufficient to generate and upload
the beacon to the device. You could even hit lock contention I think.
johannes
^ permalink raw reply
* Re: [PATCH 2.6.34] mac80211: Fix auth retries if AP sends temporary deauth
From: Paul Stewart @ 2010-07-02 18:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Michael Wu, Jiri Benc, John W. Linville
In-Reply-To: <1278091743.15412.17.camel@jlt3.sipsolutions.net>
It may be a weird patch, but probably just because I'm still wrapping
my head around how things work. The problem is ultimately the call to
__cfg80211_send_deauth() in wireless/mlme.c that is triggered by
reception of the DEAUTH. That function removes wdev->auth_bsses[i],
which is needed in order for an auth to succeed. The code path that
gets us there is:
mac80211/rx.c: ieee80211_rx_h_mgmt()
mac80211/mlme.c: ieee80211_sta_rx_mgmt()
...then through the queued work and...
ieee80211_sta_rx_queued_mgmt()
At the bottom of the latter function, outside of the block that checks
for our authentication state, we call cfg80211_send_deauth() in
response to IEEE80211_STYPE_DEAUTH, which quite arguably should never
be called if we're authenticated. The only time this issue touches
cfg80211 is that final call to send_deauth() which I believe is done
in error. I think the fix should be in mac80211 somewhere.
I didn't find a way to tell where we were in the authentication proces
from within ieee80211_sta_rx_queued_mgmt(), so I swallowed the packet
much earlier in the process from within ieee80211_work_rx_mgmt(),
which has access to that state, and can indeed claim packets for
itself it it believes it knows best what to do with them.
I hope this clears up my thinking on this. I'd be happy to change the
patch in whatever way makes sense.
--
Paul
On Fri, Jul 2, 2010 at 10:29 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-07-01 at 10:21 -0700, Paul Stewart wrote:
>> @@ -1030,6 +1030,25 @@ ieee80211_rx_result
>> ieee80211_work_rx_mgmt(struct ieee80211_sub_if_data *sdata,
>> skb_queue_tail(&local->work_skb_queue, skb);
>> ieee80211_queue_work(&local->hw, &local->work_work);
>> return RX_QUEUED;
>> + case IEEE80211_STYPE_DEAUTH:
>> + /*
>> + * If we get sent a DEAUTH while we are
>> + * actively trying to authenticate to this
>> + * station, we shoot ourselves in the foot if
>> + * we fall through using RX_CONTINUE and allow
>> + * the bss context to disappear
>> + * (ieee80211_sta_rx_mgmt()). This is
>> + * especially true if the reason for the
>> + * DEAUTH was a negative but temporary direct
>> + * response to an AUTH attempt. Let the retry
>> + * mechanism run its course instead.
>> + */
>> + reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
>> + if (wk->type == IEEE80211_WORK_AUTH &&
>> + reason_code == WLAN_REASON_PREV_AUTH_NOT_VALID) {
>> + return RX_DROP_MONITOR;
>> + }
>> + break;
>
> Ok, wow, I finally understand this patch, but is it weird!! You're
> modifying work.c to avoid having the mlme.c code send this frame to
> cfg80211? That's really confusing.
>
> The real reason for this is that we send up the deauth frame even when
> we're not even authenticated. This happens in mlme.c. Therefore, we
> should improve the logic in ieee80211_sta_rx_queued_mgmt() to make sure
> it only triggers when we're authenticated with the BSS?
>
> Alternatively, since cfg80211 tracks this, it would be easier to modify
> cfg80211_send_rx_auth() to not send the event to userspace in the !done
> case I guess.
>
> johannes
>
>
^ permalink raw reply
* Re: [PATCH 2.6.34] mac80211: Fix auth retries if AP sends temporary deauth
From: Johannes Berg @ 2010-07-02 18:13 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, Michael Wu, Jiri Benc, John W. Linville
In-Reply-To: <AANLkTikfegnc1gAwIUiZKaMeDoUYOFqK8eSc6_3wUggm@mail.gmail.com>
On Fri, 2010-07-02 at 11:09 -0700, Paul Stewart wrote:
> It may be a weird patch, but probably just because I'm still wrapping
> my head around how things work.
Sure.
> The problem is ultimately the call to
> __cfg80211_send_deauth() in wireless/mlme.c that is triggered by
> reception of the DEAUTH.
Is it? I thought it was without double underscore from another code
path?
> That function removes wdev->auth_bsses[i],
No, the BSS can't be in auth_bsses yet. I think the problem is more
complex, and wpa_supplicant itself will remove it from auth_bsses
because the kernel erroneously told it we got deauthenticated.
> which is needed in order for an auth to succeed. The code path that
> gets us there is:
>
> mac80211/rx.c: ieee80211_rx_h_mgmt()
> mac80211/mlme.c: ieee80211_sta_rx_mgmt()
> ...then through the queued work and...
> ieee80211_sta_rx_queued_mgmt()
>
> At the bottom of the latter function, outside of the block that checks
> for our authentication state, we call cfg80211_send_deauth() in
> response to IEEE80211_STYPE_DEAUTH, which quite arguably should never
> be called if we're authenticated. The only time this issue touches
> cfg80211 is that final call to send_deauth() which I believe is done
> in error. I think the fix should be in mac80211 somewhere.
>
> I didn't find a way to tell where we were in the authentication proces
> from within ieee80211_sta_rx_queued_mgmt(), so I swallowed the packet
> much earlier in the process from within ieee80211_work_rx_mgmt(),
> which has access to that state, and can indeed claim packets for
> itself it it believes it knows best what to do with them.
>
> I hope this clears up my thinking on this. I'd be happy to change the
> patch in whatever way makes sense.
Can you try the patch below instead of yours? I'll explain it a bit more
later, but my church wedding ceremony is tomorrow :)
johannes
--- wireless-testing.orig/net/wireless/mlme.c 2010-07-02 20:12:19.000000000 +0200
+++ wireless-testing/net/wireless/mlme.c 2010-07-02 20:12:43.000000000 +0200
@@ -44,10 +44,10 @@ void cfg80211_send_rx_auth(struct net_de
}
}
- WARN_ON(!done);
-
- nl80211_send_rx_auth(rdev, dev, buf, len, GFP_KERNEL);
- cfg80211_sme_rx_auth(dev, buf, len);
+ if (done) {
+ nl80211_send_rx_auth(rdev, dev, buf, len, GFP_KERNEL);
+ cfg80211_sme_rx_auth(dev, buf, len);
+ }
wdev_unlock(wdev);
}
^ permalink raw reply
* Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
From: Helmut Schaa @ 2010-07-02 18:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
In-Reply-To: <1278093964.15412.24.camel@jlt3.sipsolutions.net>
Am Freitag 02 Juli 2010 schrieb Johannes Berg:
> On Fri, 2010-07-02 at 19:59 +0200, Helmut Schaa wrote:
>
> > > unless your
> > > device itself is capable of generating the TIM IE _right before_ the
> > > beacon gets transmitted.
> >
> > Agreed. At least on rt2800 we can use the pre tbtt interrupt to update the
> > beacon just before it is sent out.
>
> Careful though. You don't know how far in advance it is triggered (or
> maybe you do) or if the time will be sufficient to generate and upload
> the beacon to the device. You could even hit lock contention I think.
Yeah, the delay is configurable. And yes, we cannot be 100% sure but
I already did some tests and on my MIPS board anything >1ms was
enough to generate + upload a new beacon to the device. And we can still
increase that to a safe default of maybe 5ms or so.
Helmut
^ permalink raw reply
* Re: Enabling channels 12,13
From: Jaroslav Fojtik @ 2010-07-02 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Paul Fertser
In-Reply-To: <20100702173625.GD974@home.pavel.comp>
[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1983 bytes --]
Dear Paul Fertser,
thank you for a hint.
But unfortunatelly this patch (attached) does not work for me.
May be for multiple devices? Who knows.
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
[ 4.464183] ath5k 0000:02:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 4.464328] ath5k 0000:02:08.0: registered as 'phy0'
[ 5.059773] ath5k phy0: DANGER! You're overriding EEPROM-defined regulatory domain.
[ 5.059837] ath5k phy0: Your card was not certified to operate on the domain you choosed.
[ 5.059902] ath5k phy0: This might result in a violation of your local regulatory rules.
--
[ 5.122197] ath5k 0000:02:0a.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 5.122338] ath5k 0000:02:0a.0: registered as 'phy1'
[ 5.587528] ath5k phy1: DANGER! You're overriding EEPROM-defined regulatory domain.
[ 5.587593] ath5k phy1: Your card was not certified to operate on the domain you choosed.
[ 5.588358] ath5k phy1: This might result in a violation of your local regulatory rules.
> Please see this for reference:
> http://forum.aircrack-ng.org/index.php?topic=6822.15
>
> You can also try "pentoo" gentoo overlay.
regards
Jara
>
> HTH
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav@gmail.com
[-- Attachment #2: ath5k_regdomain_override.patch --]
[-- Type: Application/Octet-stream, Size: 1481 bytes --]
PaulFertser> Get _your_ country code from regd.h, add 32768 and supply as a parameter.
fercerpav@gmail.com
--- linux-2.6.32-gentoo-r1-orig/drivers/net/wireless/ath/ath5k/base.c 2009-12-03 06:51:21.000000000 +0300
+++ linux-2.6.32-gentoo-r1/drivers/net/wireless/ath/ath5k/base.c 2010-01-16 00:02:51.000000000 +0300
@@ -68,6 +68,11 @@
module_param_named(all_channels, modparam_all_channels, bool, S_IRUGO);
MODULE_PARM_DESC(all_channels, "Expose all channels the device can use.");
+static int modparam_override_eeprom_regdomain = -1;
+module_param_named(override_eeprom_regdomain,
+ modparam_override_eeprom_regdomain, int, S_IRUGO);
+MODULE_PARM_DESC(override_eeprom_regdomain, "Override regdomain hardcoded in EEPROM with this value (DANGEROUS).");
+
/******************\
* Internal defines *
@@ -572,6 +577,15 @@
goto err_irq;
}
+ if (modparam_override_eeprom_regdomain != -1) {
+ ATH5K_ERR(sc, "DANGER! You're overriding EEPROM-defined regulatory domain.\n");
+ ATH5K_ERR(sc, "Your card was not certified to operate on the domain you choosed.\n");
+ ATH5K_ERR(sc, "This might result in a violation of your local regulatory rules.\n");
+ ATH5K_ERR(sc, "Do not ever do that unless you really know what you do!\n");
+ sc->ah->ah_capabilities.cap_eeprom.ee_regdomain =
+ modparam_override_eeprom_regdomain;
+ }
+
/* set up multi-rate retry capabilities */
if (sc->ah->ah_version == AR5K_AR5212) {
hw->max_rates = 4;
^ permalink raw reply
* [PATCH wireless-2.6] iwlwifi: remove key information during device restart
From: Wey-Yi Guy @ 2010-07-02 18:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
From: Reinette Chatre <reinette.chatre@intel.com>
When there is a firmware error or the firmware is reloaded for some other
reason we currently clear all station information, including keys
associated with them. A problem is that we do not clear some other
information regarding keys that are not stored in the station structs.
The consequence of this is that when the device is reconfigured after the
firmware reload we can, among other things, run out of key indices.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16232
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2221
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
---
this patch is also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
drivers/net/wireless/iwlwifi/iwl-sta.h | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.h b/drivers/net/wireless/iwlwifi/iwl-sta.h
index c2a453a..dc43ebd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-sta.h
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.h
@@ -97,6 +97,17 @@ static inline void iwl_clear_driver_stations(struct iwl_priv *priv)
spin_lock_irqsave(&priv->sta_lock, flags);
memset(priv->stations, 0, sizeof(priv->stations));
priv->num_stations = 0;
+
+ /*
+ * Remove all key information that is not stored as part of station
+ * information since mac80211 may not have had a
+ * chance to remove all the keys. When device is reconfigured by
+ * mac80211 after an error all keys will be reconfigured.
+ */
+ priv->ucode_key_table = 0;
+ priv->key_mapping_key = 0;
+ memset(priv->wep_keys, 0, sizeof(priv->wep_keys));
+
spin_unlock_irqrestore(&priv->sta_lock, flags);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/8] iwlwifi update for 2.6.36
From: Wey-Yi Guy @ 2010-07-02 18:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
We add support for tx fifo flush command
We also add new supporting sensitivity information for upcoming devices
"fw_restart" module parameter was broken by earlier firmware restart
patch; here we re-enable this module parameter.
Wey-Yi Guy (8):
iwlwifi: fix fw_restart module parameter
iwlwifi: add debug print for parsing firmware TLV
iwlwifi: tx fifo queue flush command
iwlwifi: add mac80211 flush callback support
iwlwifi: add support for device tx flush request
iwlwifi: debugfs file for txfifo command testing
iwlwifi: generic parameter define for _agn device
iwlwifi: adding enhance sensitivity table entries
these patches are also available from wireless-next-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
drivers/net/wireless/iwlwifi/iwl-1000.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 12 ++-
drivers/net/wireless/iwlwifi/iwl-6000.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 133 ++++++++++++++++-----
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 82 +++++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 165 ++++++++++++++++++++------
drivers/net/wireless/iwlwifi/iwl-agn.h | 3 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 85 +++++++++++++-
drivers/net/wireless/iwlwifi/iwl-core.c | 31 ++++--
drivers/net/wireless/iwlwifi/iwl-core.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 29 +++++-
drivers/net/wireless/iwlwifi/iwl-dev.h | 4 +
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 1 +
drivers/net/wireless/iwlwifi/iwl-rx.c | 4 +-
14 files changed, 477 insertions(+), 89 deletions(-)
^ 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