* Re: Ath5k/mac80211 triggers WARN_ON in kernel/softirq.c
From: Johannes Berg @ 2009-07-30 15:37 UTC (permalink / raw)
To: Bob Copeland
Cc: Michael Buesch, jirislaby, mickflemm, lrodriguez, wireless,
John Linville
In-Reply-To: <b6c5339f0907300745l3e7ec63eu9819503c4e7766bb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
On Thu, 2009-07-30 at 10:45 -0400, Bob Copeland wrote:
> On Thu, Jul 30, 2009 at 10:31 AM, Michael Buesch<mb@bu3sch.de> wrote:
> > Ath5k from today's compat-wireless triggers the following WARNing
> > on hostapd startup.
> > [ 1669.799870] ------------[ cut here ]------------
> > [ 1669.799934] WARNING: at kernel/softirq.c:141 local_bh_enable_ip+0x8b/0xb0()
>
> because ath5k calls ieee80211_beacon_get inside a spin_lock_irqsave()
> and this is WARN_ON_ONCE(in_irq() || irqs_disabled).
> > [ 1669.800493] [<ffffffff807e0fef>] _spin_unlock_bh+0xf/0x20
> > [ 1669.800564] [<ffffffffa0040b92>] ieee80211_beacon_get+0x2c2/0x2d0 [mac80211]
>
> I guess this is the first victim of spin_lock_bh conversion?
Indeed. I think this means we need to convert the local->sta_lock back
to _irqsave/restore.
John, can you revert the BH patch ("mac80211: do not use irq locks where
not necessary") and I'll send a new one with those changes removed?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: decouple regulatory variables from cfg80211_mutex
From: Luis R. Rodriguez @ 2009-07-30 15:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1248967964.16129.4.camel@johannes.local>
On Thu, Jul 30, 2009 at 8:32 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-30 at 07:54 -0700, Luis R. Rodriguez wrote:
>> On Thu, Jul 30, 2009 at 12:43 AM, Johannes
>> Berg<johannes@sipsolutions.net> wrote:
>> > On Wed, 2009-07-29 at 17:46 -0700, Luis R. Rodriguez wrote:
>> >> We change regulatory code to be protected by its own regulatory
>> >> spinlock and alleviate cfg80211_mutex to only be used to protect
>> >> cfg80211_rdev_list, the registered device list.
>> >>
>> >> By doing this we will be able to work on regulatory core components
>> >> without having to have hog up the cfg80211_mutex. An example here is
>> >> we no longer need to use the cfg80211_mutex during the country IE
>> >> regulatory hint; by doing so we end up curing this new lockdep warning:
>> >
>> > This is ok with me, but be sure that it changes the API between drivers
>> > and cfg80211 -- the reg notifier can no longer sleep now.
>>
>> We could use a mutex as well.
>
> Right. I don't care, just wanted you to be aware of the change. I don't
> expect many drivers to really use the reg notifier stuff so if it
> doesn't matter for ath.ko it probably just doesn't matter.
Yeah understood, I'll still respin with a mutex.
Luis
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: decouple regulatory variables from cfg80211_mutex
From: Johannes Berg @ 2009-07-30 15:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <43e72e890907300754v7ed8cb66w9b1bdbfe9917486c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
On Thu, 2009-07-30 at 07:54 -0700, Luis R. Rodriguez wrote:
> On Thu, Jul 30, 2009 at 12:43 AM, Johannes
> Berg<johannes@sipsolutions.net> wrote:
> > On Wed, 2009-07-29 at 17:46 -0700, Luis R. Rodriguez wrote:
> >> We change regulatory code to be protected by its own regulatory
> >> spinlock and alleviate cfg80211_mutex to only be used to protect
> >> cfg80211_rdev_list, the registered device list.
> >>
> >> By doing this we will be able to work on regulatory core components
> >> without having to have hog up the cfg80211_mutex. An example here is
> >> we no longer need to use the cfg80211_mutex during the country IE
> >> regulatory hint; by doing so we end up curing this new lockdep warning:
> >
> > This is ok with me, but be sure that it changes the API between drivers
> > and cfg80211 -- the reg notifier can no longer sleep now.
>
> We could use a mutex as well.
Right. I don't care, just wanted you to be aware of the change. I don't
expect many drivers to really use the reg notifier stuff so if it
doesn't matter for ath.ko it probably just doesn't matter.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] mac80211: FIF_PSPOLL filter flag
From: Johannes Berg @ 2009-07-30 15:31 UTC (permalink / raw)
To: Igor Perminov; +Cc: linux-wireless
In-Reply-To: <1248966336.29068.178.camel@sunlight>
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
On Thu, 2009-07-30 at 19:05 +0400, Igor Perminov wrote:
> > > @@ -497,6 +509,13 @@ static int ieee80211_stop(struct net_device *dev)
> > > }
> > > /* fall through */
> > > default:
> > > + if (sdata->vif.type == NL80211_IFTYPE_AP) {
> >
> > I'd probably put this after a
> > case NL80211_IFTYPE_AP:
> > label but you need the if () anyway ... hmm I guess we really should
> > clean up this code and split it into two switch statements...
>
> And may be do it above?
>
> if (sdata->flags & IEEE80211_SDATA_ALLMULTI)
> atomic_dec(&local->iff_allmultis);
>
> if (sdata->flags & IEEE80211_SDATA_PROMISC)
> atomic_dec(&local->iff_promiscs);
>
> + if (sdata->vif.type == NL80211_IFTYPE_AP)
> + local->fif_pspoll--;
> +
Looks good, yeah, also saves another configure_filter call.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] mac80211: FIF_PSPOLL filter flag
From: Igor Perminov @ 2009-07-30 15:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1248963525.16129.2.camel@johannes.local>
> > @@ -497,6 +509,13 @@ static int ieee80211_stop(struct net_device *dev)
> > }
> > /* fall through */
> > default:
> > + if (sdata->vif.type == NL80211_IFTYPE_AP) {
>
> I'd probably put this after a
> case NL80211_IFTYPE_AP:
> label but you need the if () anyway ... hmm I guess we really should
> clean up this code and split it into two switch statements...
And may be do it above?
if (sdata->flags & IEEE80211_SDATA_ALLMULTI)
atomic_dec(&local->iff_allmultis);
if (sdata->flags & IEEE80211_SDATA_PROMISC)
atomic_dec(&local->iff_promiscs);
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ local->fif_pspoll--;
+
netif_addr_lock_bh(dev);
spin_lock_bh(&local->filter_lock);
__dev_addr_unsync(&local->mc_list, &local->mc_count,
&dev->mc_list, &dev->mc_count);
ieee80211_configure_filter(local);
spin_unlock_bh(&local->filter_lock);
netif_addr_unlock_bh(dev);
Igor
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: decouple regulatory variables from cfg80211_mutex
From: Luis R. Rodriguez @ 2009-07-30 14:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1248939781.8925.2.camel@johannes.local>
On Thu, Jul 30, 2009 at 12:43 AM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-07-29 at 17:46 -0700, Luis R. Rodriguez wrote:
>> We change regulatory code to be protected by its own regulatory
>> spinlock and alleviate cfg80211_mutex to only be used to protect
>> cfg80211_rdev_list, the registered device list.
>>
>> By doing this we will be able to work on regulatory core components
>> without having to have hog up the cfg80211_mutex. An example here is
>> we no longer need to use the cfg80211_mutex during the country IE
>> regulatory hint; by doing so we end up curing this new lockdep warning:
>
> This is ok with me, but be sure that it changes the API between drivers
> and cfg80211 -- the reg notifier can no longer sleep now.
We could use a mutex as well.
Luis
^ permalink raw reply
* Re: Ath5k/mac80211 triggers WARN_ON in kernel/softirq.c
From: Bob Copeland @ 2009-07-30 14:45 UTC (permalink / raw)
To: Michael Buesch, Johannes Berg; +Cc: jirislaby, mickflemm, lrodriguez, wireless
In-Reply-To: <200907301631.50780.mb@bu3sch.de>
On Thu, Jul 30, 2009 at 10:31 AM, Michael Buesch<mb@bu3sch.de> wrote:
> Ath5k from today's compat-wireless triggers the following WARNing
> on hostapd startup.
> [ 1669.799870] ------------[ cut here ]------------
> [ 1669.799934] WARNING: at kernel/softirq.c:141 local_bh_enable_ip+0x8b/0xb0()
because ath5k calls ieee80211_beacon_get inside a spin_lock_irqsave()
and this is WARN_ON_ONCE(in_irq() || irqs_disabled).
> [ 1669.799982] Hardware name:
> [ 1669.800023] Modules linked in: ath5k mac80211 ath cfg80211
> [ 1669.800192] Pid: 24862, comm: hostapd Not tainted 2.6.30.2 #3
> [ 1669.800238] Call Trace:
> [ 1669.800287] [<ffffffff80248e3b>] ? local_bh_enable_ip+0x8b/0xb0
> [ 1669.800340] [<ffffffff802432f8>] warn_slowpath_common+0x78/0xd0
> [ 1669.800391] [<ffffffff8024335f>] warn_slowpath_null+0xf/0x20
> [ 1669.800441] [<ffffffff80248e3b>] local_bh_enable_ip+0x8b/0xb0
> [ 1669.800493] [<ffffffff807e0fef>] _spin_unlock_bh+0xf/0x20
> [ 1669.800564] [<ffffffffa0040b92>] ieee80211_beacon_get+0x2c2/0x2d0 [mac80211]
I guess this is the first victim of spin_lock_bh conversion?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [Linux Wireless] Update of "en/users/Download" by ReinetteChatre
From: Luis R. Rodriguez @ 2009-07-30 14:43 UTC (permalink / raw)
To: Roman Macko; +Cc: reinette chatre, linux-wireless
In-Reply-To: <4A719C44.6050208@gmail.com>
On Thu, Jul 30, 2009 at 6:12 AM, Roman Macko<rmacko72@gmail.com> wrote:
> Luis,
>
> I used stable version 2.6.30.
> Anyway I downloaded bleeding edge version and ran script check_depmod.
> But it created new configuration in /etc/depmod.d directory instead of
> creating
> global configuration /etc/depmod.conf what I did. It doesn't work in that
> way.
What do you mean it doesn't work that way?
Do you mean you tested it and that it didn't work?
> I can read in manual pages of depmod.conf that depmod.d directory serves for
> configuration on per-module basis,
> so I think you can change the order of proceding directories for particular
> module only there.
Nope. Even Ubuntu uses their own file in there for the same purpose:
mcgrof@tux ~ $ cat /etc/depmod.d/ubuntu.conf
search updates ubuntu built-in
> But I don't know how to name that file or if my thought is right at all.
The man page needs some updating.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Ben Greear @ 2009-07-30 14:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <1248949853.29062.3.camel@johannes.local>
Johannes Berg wrote:
> On Wed, 2009-07-29 at 14:39 -0700, Ben Greear wrote:
>
>> On 07/29/2009 02:32 PM, Reinette Chatre wrote:
>>
>>> From: Reinette Chatre<reinette.chatre@intel.com>
>>>
>>> The connection monitor currently relies on probe requests paired
>>> with probe responses to ensure that a connection is alive. This is
>>> fragile in some environments where probe responses can get lost.
>>> When we receive beacons we can also consider the connection to be
>>> alive, so cancel connection poll instance when we receive a beacon.
>>>
>> I'm chasing a similar problem while working on virtual STA device
>> support in ath5k. I was also going to try sending up to 3 polls before
>> giving up on the connection. Does that seems like a valid thing to do?
>>
>
> That seems somewhat better, yeah.
>
> I suspect the real cause of the issue is something else though, like the
> probe request not going out properly or the card being in a kind of
> 'temporary lock-up' state where it's not really doing anything for the
> time being -- I've never had a problem on any other (than iwlwifi)
> hardware.
>
> Of course, the virtual STA device support stuff potentially has similar
> issues, especially if it does channel switching like the ath9k virtual
> wiphy stuff.
>
We're not trying any channel switching, though it does seem to stop
transmitting
and/or receiving for a bit during some operations. The retransmit logic
was helping,
but it still isn't quite right. Hopefully we'll make more progress today.
Thanks,
Ben
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Ath5k/mac80211 triggers WARN_ON in kernel/softirq.c
From: Michael Buesch @ 2009-07-30 14:31 UTC (permalink / raw)
To: jirislaby, mickflemm, lrodriguez, me; +Cc: wireless
Ath5k from today's compat-wireless triggers the following WARNing
on hostapd startup.
[ 1588.927501] cfg80211: Calling CRDA to update world regulatory domain
[ 1588.967169] ath5k 0000:04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[ 1588.967334] ath5k 0000:04:00.0: registered as 'phy0'
[ 1588.974208] cfg80211: World regulatory domain updated:
[ 1588.974271] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1588.974342] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[ 1589.157198] ath: EEPROM regdomain: 0x809c
[ 1589.157205] ath: EEPROM indicates we should expect a country code
[ 1589.157210] ath: doing EEPROM country->regdmn map search
[ 1589.157215] ath: country maps to regdmn code: 0x52
[ 1589.157220] ath: Country alpha2 being used: CN
[ 1589.157224] ath: Regpair used: 0x52
[ 1589.157563] phy0: Selected rate control algorithm 'minstrel'
[ 1589.158027] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
[ 1589.158516] cfg80211: Calling CRDA for country: CN
[ 1589.168612] cfg80211: Regulatory domain changed to country: CN
[ 1589.168670] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1589.168739] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1589.168788] (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
[ 1668.667833] cfg80211: Calling CRDA for country: DE
[ 1668.674341] cfg80211: Regulatory domain changed to country: DE
[ 1668.674397] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1668.674463] (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1668.674528] (5150000 KHz - 5255000 KHz @ 40000 KHz), (N/A, 2301 mBm)
[ 1668.674577] (5470000 KHz - 5650000 KHz @ 40000 KHz), (N/A, 3000 mBm)
[ 1669.799870] ------------[ cut here ]------------
[ 1669.799934] WARNING: at kernel/softirq.c:141 local_bh_enable_ip+0x8b/0xb0()
[ 1669.799982] Hardware name:
[ 1669.800023] Modules linked in: ath5k mac80211 ath cfg80211
[ 1669.800192] Pid: 24862, comm: hostapd Not tainted 2.6.30.2 #3
[ 1669.800238] Call Trace:
[ 1669.800287] [<ffffffff80248e3b>] ? local_bh_enable_ip+0x8b/0xb0
[ 1669.800340] [<ffffffff802432f8>] warn_slowpath_common+0x78/0xd0
[ 1669.800391] [<ffffffff8024335f>] warn_slowpath_null+0xf/0x20
[ 1669.800441] [<ffffffff80248e3b>] local_bh_enable_ip+0x8b/0xb0
[ 1669.800493] [<ffffffff807e0fef>] _spin_unlock_bh+0xf/0x20
[ 1669.800564] [<ffffffffa0040b92>] ieee80211_beacon_get+0x2c2/0x2d0 [mac80211]
[ 1669.800625] [<ffffffffa006a283>] ath5k_beacon_update+0x23/0x430 [ath5k]
[ 1669.800682] [<ffffffffa006b0ac>] ? ath5k_beacon_config+0xcc/0x200 [ath5k]
[ 1669.800735] [<ffffffff807de4b0>] ? wait_for_common+0x150/0x170
[ 1669.800791] [<ffffffffa006b30f>] ath5k_bss_info_changed+0x12f/0x1e0 [ath5k]
[ 1669.800854] [<ffffffffa002c18a>] ieee80211_bss_info_change_notify+0x10a/0x1e0 [mac80211]
[ 1669.800931] [<ffffffffa003ac8b>] ieee80211_config_beacon+0x17b/0x1c0 [mac80211]
[ 1669.801006] [<ffffffffa003ad28>] ieee80211_add_beacon+0x28/0x40 [mac80211]
[ 1669.801068] [<ffffffffa00096b1>] nl80211_addset_beacon+0x181/0x1e0 [cfg80211]
[ 1669.801136] [<ffffffff806b4a76>] genl_rcv_msg+0x1b6/0x1f0
[ 1669.801186] [<ffffffff806b48c0>] ? genl_rcv_msg+0x0/0x1f0
[ 1669.801235] [<ffffffff806b40a9>] netlink_rcv_skb+0x89/0xb0
[ 1669.801286] [<ffffffff806b48a7>] genl_rcv+0x27/0x40
[ 1669.801335] [<ffffffff806b3ab8>] netlink_unicast+0x2a8/0x2c0
[ 1669.801386] [<ffffffff8066744e>] ? __alloc_skb+0x6e/0x160
[ 1669.801436] [<ffffffff806b3cb3>] netlink_sendmsg+0x1e3/0x2e0
[ 1669.801487] [<ffffffff8065e8bf>] sock_sendmsg+0xdf/0x110
[ 1669.801538] [<ffffffff8025a510>] ? autoremove_wake_function+0x0/0x40
[ 1669.801589] [<ffffffff8025a510>] ? autoremove_wake_function+0x0/0x40
[ 1669.801642] [<ffffffff8029212b>] ? find_get_page+0x1b/0xb0
[ 1669.801691] [<ffffffff80292485>] ? find_lock_page+0x25/0x70
[ 1669.801740] [<ffffffff80292b04>] ? filemap_fault+0x144/0x450
[ 1669.801790] [<ffffffff8066da62>] ? __dev_get_by_name+0xa2/0xc0
[ 1669.801841] [<ffffffff8065d8eb>] ? move_addr_to_kernel+0x2b/0x40
[ 1669.801891] [<ffffffff80668a3c>] ? verify_iovec+0x3c/0xd0
[ 1669.801940] [<ffffffff8065ea79>] sys_sendmsg+0x189/0x320
[ 1669.801990] [<ffffffff8065d2d4>] ? sock_destroy_inode+0x14/0x20
[ 1669.802041] [<ffffffff802dc10e>] ? destroy_inode+0x2e/0x60
[ 1669.802091] [<ffffffff802d890a>] ? __d_free+0x3a/0x60
[ 1669.802142] [<ffffffff802dfe7a>] ? mntput_no_expire+0x2a/0x140
[ 1669.802192] [<ffffffff802d89e6>] ? d_kill+0x56/0x70
[ 1669.802242] [<ffffffff802c8521>] ? __fput+0x161/0x1e0
[ 1669.802291] [<ffffffff802c85bd>] ? fput+0x1d/0x30
[ 1669.802340] [<ffffffff802c4d0b>] ? filp_close+0x5b/0x90
[ 1669.802391] [<ffffffff8020b3eb>] system_call_fastpath+0x16/0x1b
[ 1669.802439] ---[ end trace e56b46f2a3c5ff89 ]---
[ 1680.059849] wlan0: no IPv6 routers present
--
Greetings, Michael.
^ permalink raw reply
* Re: [RFC PATCH] mac80211: FIF_PSPOLL filter flag
From: Johannes Berg @ 2009-07-30 14:18 UTC (permalink / raw)
To: Igor Perminov; +Cc: linux-wireless
In-Reply-To: <1248962000.29068.170.camel@sunlight>
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
On Thu, 2009-07-30 at 17:53 +0400, Igor Perminov wrote:
> @@ -245,6 +247,14 @@ static int ieee80211_open(struct net_device *dev)
>
> ieee80211_start_mesh(sdata);
> }
> + else if (sdata->vif.type == NL80211_IFTYPE_AP) {
Put 'else if' on the same line as '}' please
> + if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
> + local->fif_pspoll--;
> local->fif_control--;
> + }
Yeah, that's exactly what I was thinking of :)
> @@ -497,6 +509,13 @@ static int ieee80211_stop(struct net_device *dev)
> }
> /* fall through */
> default:
> + if (sdata->vif.type == NL80211_IFTYPE_AP) {
I'd probably put this after a
case NL80211_IFTYPE_AP:
label but you need the if () anyway ... hmm I guess we really should
clean up this code and split it into two switch statements...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* wireless-regdb entry for DE wrong
From: Andreas Steinmetz @ 2009-07-30 13:57 UTC (permalink / raw)
To: linux-wireless
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[please CC me as I'm not subscribed]
Error in regulatory database for country DE:
The document
http://www.bundesnetzagentur.de/media/archive/5009.pdf
states that the frequency range from 5470 GHz to 5725 GHz can be used
indoor and outdoor, thus the NO-OUTDOOR flag for this range is wrong.
Quick and dirty translation of the relevant text from this document
including the note:
Usage indoor and outdoor. Transmission between within a plane and a
location outside of a plane prohibited.
- --
Andreas Steinmetz SPAMmers use robotrap@domdv.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFKcaa+V/yW5kkAz4MRAscGAJ4wtUWV6kM8u3nFCstuUrcOD22ZpACgp7Yq
Ipm98KWAFilOCEyannUCIsU=
=t5GW
-----END PGP SIGNATURE-----
^ permalink raw reply
* [RFC PATCH] mac80211: FIF_PSPOLL filter flag
From: Igor Perminov @ 2009-07-30 13:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
When an interface is configured in the AP mode, the mac80211
implementation doesn't inform the driver to receive PS Poll frames.
It leads to inability to communicate with power-saving stations
reliably.
The FIF_CONTROL flag isn't passed by mac80211 to
ieee80211_ops.configure_filter when an interface is in the AP mode.
And it's ok, because we don't want to receive ACK frames and other
control ones, but only PS Poll ones.
This patch introduces the FIF_PSPOLL filter flag in addition to
FIF_CONTROL, which means for the driver "pass PS Poll frames".
This flag is passed to the driver:
A) When an interface is configured in the AP mode.
B) In all cases, when the FIF_CONTROL flag was passed earlier (in
addition to it).
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
include/net/mac80211.h | 8 ++++++--
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/iface.c | 23 +++++++++++++++++++++--
net/mac80211/main.c | 3 +++
4 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d4e09a0..5113bba 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1236,10 +1236,13 @@ ieee80211_get_alt_retry_rate(const struct ieee80211_hw *hw,
* mac80211 needs to do and the amount of CPU wakeups, so you should
* honour this flag if possible.
*
- * @FIF_CONTROL: pass control frames, if PROMISC_IN_BSS is not set then
- * only those addressed to this station
+ * @FIF_CONTROL: pass control frames (except for PS Poll), if PROMISC_IN_BSS
+ * is not set then only those addressed to this station.
*
* @FIF_OTHER_BSS: pass frames destined to other BSSes
+ *
+ * @FIF_PSPOLL: pass PS Poll frames, if PROMISC_IN_BSS is not set then only
+ * those addressed to this station.
*/
enum ieee80211_filter_flags {
FIF_PROMISC_IN_BSS = 1<<0,
@@ -1249,6 +1252,7 @@ enum ieee80211_filter_flags {
FIF_BCN_PRBRESP_PROMISC = 1<<4,
FIF_CONTROL = 1<<5,
FIF_OTHER_BSS = 1<<6,
+ FIF_PSPOLL = 1<<7,
};
/**
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..ab6003d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -621,7 +621,7 @@ struct ieee80211_local {
int open_count;
int monitors, cooked_mntrs;
/* number of interfaces with corresponding FIF_ flags */
- int fif_fcsfail, fif_plcpfail, fif_control, fif_other_bss;
+ int fif_fcsfail, fif_plcpfail, fif_control, fif_other_bss, fif_pspoll;
unsigned int filter_flags; /* FIF_* */
struct iw_statistics wstats;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index a83087f..bbf32da 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -220,8 +220,10 @@ static int ieee80211_open(struct net_device *dev)
local->fif_fcsfail++;
if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
local->fif_plcpfail++;
- if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+ if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
local->fif_control++;
+ local->fif_pspoll++;
+ }
if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
local->fif_other_bss++;
@@ -245,6 +247,14 @@ static int ieee80211_open(struct net_device *dev)
ieee80211_start_mesh(sdata);
}
+ else if (sdata->vif.type == NL80211_IFTYPE_AP) {
+ local->fif_pspoll++;
+
+ spin_lock_bh(&local->filter_lock);
+ ieee80211_configure_filter(local);
+ spin_unlock_bh(&local->filter_lock);
+ }
+
changed |= ieee80211_reset_erp_info(sdata);
ieee80211_bss_info_change_notify(sdata, changed);
ieee80211_enable_keys(sdata);
@@ -439,8 +449,10 @@ static int ieee80211_stop(struct net_device *dev)
local->fif_fcsfail--;
if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
local->fif_plcpfail--;
- if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+ if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
+ local->fif_pspoll--;
local->fif_control--;
+ }
if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
local->fif_other_bss--;
@@ -497,6 +509,13 @@ static int ieee80211_stop(struct net_device *dev)
}
/* fall through */
default:
+ if (sdata->vif.type == NL80211_IFTYPE_AP) {
+ local->fif_pspoll--;
+
+ spin_lock_bh(&local->filter_lock);
+ ieee80211_configure_filter(local);
+ spin_unlock_bh(&local->filter_lock);
+ }
if (local->scan_sdata == sdata) {
if (!local->ops->hw_scan)
cancel_delayed_work_sync(&local->scan_work);
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5e76dd1..c330235 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -77,6 +77,9 @@ void ieee80211_configure_filter(struct ieee80211_local *local)
if (local->fif_other_bss)
new_flags |= FIF_OTHER_BSS;
+ if (local->fif_pspoll)
+ new_flags |= FIF_PSPOLL;
+
changed_flags = local->filter_flags ^ new_flags;
/* be a bit nasty */
^ permalink raw reply related
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Bartlomiej Zolnierkiewicz @ 2009-07-30 13:17 UTC (permalink / raw)
To: Luis Correia
Cc: Mike Galbraith, linux-wireless, LKML, John W. Linville,
Johannes Berg
In-Reply-To: <efe7343f0907300306o44d0e718p2880b7406a38fc6a@mail.gmail.com>
Hi,
On Thursday 30 July 2009 12:06:00 Luis Correia wrote:
> Hi Mike,
>
> On Thu, Jul 30, 2009 at 10:55, Johannes Berg<johannes@sipsolutions.net> wrote:
> > On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> >> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> >> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> >> >
> >> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> >> >
> >> > Sorry, but that '/staging/' thing in there means we cannot support this.
> >> > If you must, take your query to the staging list,
> >> > devel@driverdev.osuosl.org (according to MAINTAINERS).
> >>
> >> Forwarded, thanks.
> >>
> >> ....hm. Does "If you must" mean reports aren't welcome?
> >
> > To be honest, I don't know. I'd rather see people use the rt2x00 code
> > instead of spending time cleaning up that mess (the code you've pasted
> > was pretty bad!). But you may or may not find somebody who cares about
> > that, just rather unlikely on this list.
rt2800pci which I would need for my Asus Eee 901 is not even ready for
the upstream inclusion (after a year or so since Ralink's driver has been
released).
The sad reality is that some vendors have discovered "the loophole" in
the current kernel development model and are using it. Pretending that
the GPL-ed-but-fugly _working_ drivers do not exist is not an answer!
[ Especially not in the long-term (I think thank the support for the newest
generation of Ralink chipsets will probably also be based on more-or-less
the same code base). ]
Users are pragmatic beasts and don't care about "proper" code. They are
just using what works "good enough" for them (i.e. if distribution ships
a slightly inferior solution to the official one nobody will bother with
the official one, now lets think about the incomplete official one..).
No, I don't have a good answer for the problem. However I think that we
should be looking for the real, long-term solution instead of pretending
that the issue doesn't exist.
> What is appreciated is people with time to compare both code paths,
> and report some inconsistancies, specially about card initialization
> and general handling.
You are talking about people who:
* are familiar with wireless networking and wireless drivers
* have ability to work with the ugly/complicated code
* have good code reading/review skills
* have a quite some free time in their hands
Well, good luck..
> To be hones, we, the rt2x00 team, find Ralink's code to be very
> difficult to follow, and combersome most of the times.
I completely agree but it _works_, rt2x00 does _not_.
> But any help is welcome!
I think that cleaning of vendor drivers is an indirect form of help to
rt2x00 team (by making the mess easier to read and comprehend) and not a
competition to rt2x00 project. rt2x00 code is of very high quality and
I'm impressed by the work done by you, Ivo and the rest of the team.
However I think that you will never able to out do the _vendor_ when it
comes to the support for their new devices and I find the idea of finding
highly skilled volunteers helping with the most difficult, tedious and
thankless parts of the work a bit over-optimistic.
^ permalink raw reply
* Re: zd1211rw couldn't load firmware. Error number -145 with Kernel 2.6.30
From: Mladen Horvat @ 2009-07-30 13:14 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <3ace41890907292043rad37b63y12cacfeb713dc575@mail.gmail.com>
Hin-Tak Leung <hintak.leung@...> writes:
> I noticed you have a particularly slow CPU (33MHz?)... the vendor
> driver has some preculiar coding to interrupt some operations to
> prevent deadlocks; I wonder if the rw driver inherit that? One of the
> patches in my patch set for the vendor driver put a delay right after
> firmware load;
> it might be appropriate to add something similiar to the rw driver.
> --
As i have written
here http://article.gmane.org/gmane.network.wireless.zd1211.devel/1736
the vendor 3.0 driver has no problem with the firmware upload and at least gets
an working interface up.
So i think this is definitively a driver problem with the zd1211rw.
regards
Mladen
^ permalink raw reply
* Re: [Linux Wireless] Update of "en/users/Download" by ReinetteChatre
From: Roman Macko @ 2009-07-30 13:12 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette chatre, linux-wireless
In-Reply-To: <43e72e890907291504o1de0fb31hde287f2af42dcc8@mail.gmail.com>
Luis,
I used stable version 2.6.30.
Anyway I downloaded bleeding edge version and ran script check_depmod.
But it created new configuration in /etc/depmod.d directory instead of
creating
global configuration /etc/depmod.conf what I did. It doesn't work in
that way.
I can read in manual pages of depmod.conf that depmod.d directory serves
for configuration on per-module basis,
so I think you can change the order of proceding directories for
particular module only there.
But I don't know how to name that file or if my thought is right at all.
Roman
Luis R. Rodriguez wrote:
> On Wed, Jul 29, 2009 at 2:57 PM, reinette
> chatre<reinette.chatre@intel.com> wrote:
>
>> On Wed, 2009-07-29 at 14:53 -0700, Luis R. Rodriguez wrote:
>>
>>> On Wed, Jul 29, 2009 at 2:45 PM, Linux
>>> Wireless<johannes@sipsolutions.net> wrote:
>>>
>>>> Dear Wiki user,
>>>>
>>>> You have subscribed to a wiki page or wiki category on "Linux Wireless" for change notification.
>>>>
>>>> The "en/users/Download" page has been changed by ReinetteChatre:
>>>> http://wireless.kernel.org/en/users/Download?action=diff&rev1=93&rev2=94
>>>>
>>>> }}}
>>>> '''Install''':
>>>>
>>>> - We use the updates/ directory so your distribution's drivers are left intact.
>>>> + We use the updates/ directory so your distribution's drivers are left intact. By default depmod will search this directory first, but if you find that it does not then check that your depmod.conf file lists the search order correctly with ''updates'' appearing first (before ''built-in'').
>>>>
>>> Hm, so compat-wireless now actually checks this for you and if its not
>>> there it adds it for you. Was there an issue with a particular user on
>>> this?
>>>
>> Yes, a madriva user ran into this problem. See
>> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2061#c6
>>
>
> Roman, I added a little check for this, specifically since another
> user reported the same issue. Did you use bleeding edge
> compat-wireless?
>
> The script is in:
>
> scripts/check_depmod
>
> We run this at make install time.
>
> Can you run that manually?
>
> Luis
>
^ permalink raw reply
* [rt2800 doesn't authenticate (wpapsk/tkip)] Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Mike Galbraith @ 2009-07-30 12:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1248948326.8823.4.camel@marge.simson.net>
On Thu, 2009-07-30 at 12:05 +0200, Mike Galbraith wrote:
> On Thu, 2009-07-30 at 11:55 +0200, Johannes Berg wrote:
> > On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> > > On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> > > > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> > > >
> > > > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> > > >
> > > > Sorry, but that '/staging/' thing in there means we cannot support this.
> > > > If you must, take your query to the staging list,
> > > > devel@driverdev.osuosl.org (according to MAINTAINERS).
> > >
> > > Forwarded, thanks.
> > >
> > > ....hm. Does "If you must" mean reports aren't welcome?
> >
> > To be honest, I don't know. I'd rather see people use the rt2x00 code
> > instead of spending time cleaning up that mess (the code you've pasted
> > was pretty bad!). But you may or may not find somebody who cares about
> > that, just rather unlikely on this list.
>
> Understood (and yeah, the source is.. not pretty). Sorry for the noise.
>
> WRT rt2x00 with this adapter, I tried it, was a nogo. If I find time,
> I'll reconfigure/report.
This is nogo with rt2x00 driver fwiw. Maybe some simple configuration
thing, but I'm having no luck getting the bugger to work.
[ 12.942335] phy0: Selected rate control algorithm 'minstrel'
[ 12.942440] Registered led device: rt2800usb-phy0::radio
[ 12.955279] Registered led device: rt2800usb-phy0::assoc
[ 12.968003] Registered led device: rt2800usb-phy0::quality
[ 12.981183] usbcore: registered new interface driver rt2800usb
[ 33.032056] rt2800usb 1-5:1.0: firmware: requesting rt2870.bin
[ 33.161552] input: rt2800usb as /devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0/input/input4
[ 33.347130] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 34.513078] eth0: no IPv6 routers present
[ 35.935289] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 35.937306] wlan0: authenticated
[ 35.937309] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 35.942551] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 35.942555] wlan0: associated
[ 35.950948] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 37.314470] mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary
[ 39.937271] wlan0: deauthenticated (Reason: 1)
[ 40.936521] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 40.939152] wlan0 direct probe responded
[ 40.939155] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 40.941145] wlan0: authenticated
[ 40.941148] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 40.945904] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 40.945909] wlan0: associated
[ 44.947499] wlan0: deauthenticated (Reason: 1)
[ 45.944034] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 45.946623] wlan0 direct probe responded
[ 45.946627] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 45.948744] wlan0: authenticated
[ 45.948747] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 45.953996] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 45.953999] wlan0: associated
[ 46.376015] wlan0: no IPv6 routers present
[ 49.947986] wlan0: deauthenticated (Reason: 1)
[ 50.944545] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 50.947230] wlan0 direct probe responded
[ 50.947234] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 50.949219] wlan0: authenticated
[ 50.949222] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 50.954473] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 50.954477] wlan0: associated
[ 54.958220] wlan0: deauthenticated (Reason: 1)
[ 55.956527] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 55.959137] wlan0 direct probe responded
[ 55.959140] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 55.961123] wlan0: authenticated
[ 55.961126] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 55.966502] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 55.966505] wlan0: associated
[ 59.968460] wlan0: deauthenticated (Reason: 1)
[ 60.968032] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 60.970625] wlan0 direct probe responded
[ 60.970628] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 60.972741] wlan0: authenticated
[ 60.972743] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 60.978499] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 60.978502] wlan0: associated
[ 64.978212] wlan0: deauthenticated (Reason: 1)
[ 65.976524] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 65.979117] wlan0 direct probe responded
[ 65.979119] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 65.981120] wlan0: authenticated
[ 65.981124] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 65.986501] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 65.986505] wlan0: associated
[ 69.988830] wlan0: deauthenticated (Reason: 1)
[ 70.988546] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 70.991121] wlan0 direct probe responded
[ 70.991124] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 70.993237] wlan0: authenticated
[ 70.993239] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 70.998494] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 70.998498] wlan0: associated
[ 74.998070] wlan0: deauthenticated (Reason: 1)
[ 75.996510] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 75.999123] wlan0 direct probe responded
[ 75.999127] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 76.001239] wlan0: authenticated
[ 76.001242] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 76.006745] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 76.006749] wlan0: associated
[ 80.007943] wlan0: deauthenticated (Reason: 1)
[ 81.008508] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 81.011115] wlan0 direct probe responded
[ 81.011118] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 81.013111] wlan0: authenticated
[ 81.013115] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 81.018494] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 81.018498] wlan0: associated
[ 85.017825] wlan0: deauthenticated (Reason: 1)
[ 86.016508] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 86.019115] wlan0 direct probe responded
[ 86.019118] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 86.021230] wlan0: authenticated
[ 86.021233] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 86.026610] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 86.026613] wlan0: associated
[ 96.027614] wlan0: disassociating by local choice (reason=3)
[ 96.030483] wlan0: deauthenticated (Reason: 6)
[ 97.485736] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 97.487617] wlan0: authenticated
[ 97.487620] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 97.492871] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 97.492875] wlan0: associated
[ 101.487940] wlan0: deauthenticated (Reason: 1)
[ 102.484011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 102.486625] wlan0 direct probe responded
[ 102.486629] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 102.488742] wlan0: authenticated
[ 102.488746] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 102.493993] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 102.493996] wlan0: associated
[ 112.496478] wlan0: disassociating by local choice (reason=3)
[ 112.499359] wlan0: deauthenticated (Reason: 6)
[ 123.951239] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 123.953248] wlan0: authenticated
[ 123.953252] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 123.958499] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 123.958503] wlan0: associated
[ 127.957566] wlan0: deauthenticated (Reason: 1)
[ 128.956012] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 128.958616] wlan0 direct probe responded
[ 128.958619] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 128.960743] wlan0: authenticated
[ 128.960746] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 128.966121] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 128.966125] wlan0: associated
[ 132.967815] wlan0: deauthenticated (Reason: 1)
[ 133.964011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 133.966613] wlan0 direct probe responded
[ 133.966616] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 133.968740] wlan0: authenticated
[ 133.968744] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 133.973868] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 133.973871] wlan0: associated
[ 137.967813] wlan0: deauthenticated (Reason: 1)
[ 138.964014] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 138.966613] wlan0 direct probe responded
[ 138.966616] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 138.968738] wlan0: authenticated
[ 138.968741] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 138.973996] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 138.973999] wlan0: associated
[ 142.967685] wlan0: deauthenticated (Reason: 1)
[ 143.964009] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 143.966609] wlan0 direct probe responded
[ 143.966612] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 143.968736] wlan0: authenticated
[ 143.968740] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 143.973988] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 143.973991] wlan0: associated
[ 147.967736] wlan0: deauthenticated (Reason: 1)
[ 148.964016] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 148.966607] wlan0 direct probe responded
[ 148.966609] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 148.968734] wlan0: authenticated
[ 148.968736] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 148.973983] wlan0: RX ReassocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 148.973985] wlan0: associated
[ 152.967813] wlan0: deauthenticated (Reason: 1)
[ 153.964009] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 154.164015] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 2
[ 154.364015] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 3
[ 154.564009] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 timed out
[ 181.899242] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 182.096012] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 2
[ 182.296011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 3
[ 182.496011] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 timed out
[ 200.602027] usbcore: deregistering interface driver rt2800usb
^ permalink raw reply
* [PATCH] cfg80211: fix NETDEV_UNREGISTER notifier
From: Johannes Berg @ 2009-07-30 12:04 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
It's possible to get the NETDEV_UNREGISTER callback multiple
times (see net/core/dev.c:netdev_wait_allrefs) and this will
completely mess up our cleanup code. To avoid that, clean up
only when the interface is still on the wiphy interface list
from which it's removed on the first NETDEV_UNREGISTER call.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/wireless/core.c 2009-07-30 13:41:26.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-07-30 13:52:59.000000000 +0200
@@ -725,15 +725,22 @@ static int cfg80211_netdev_notifier_call
break;
case NETDEV_UNREGISTER:
mutex_lock(&rdev->devlist_mtx);
+ /*
+ * It is possible to get NETDEV_UNREGISTER
+ * multiple times. To detect that, check
+ * that the interface is still on the list
+ * of registered interfaces, and only then
+ * remove and clean it up.
+ */
if (!list_empty(&wdev->list)) {
sysfs_remove_link(&dev->dev.kobj, "phy80211");
list_del_init(&wdev->list);
- }
- mutex_unlock(&rdev->devlist_mtx);
- mutex_destroy(&wdev->mtx);
+ mutex_destroy(&wdev->mtx);
#ifdef CONFIG_WIRELESS_EXT
- kfree(wdev->wext.keys);
+ kfree(wdev->wext.keys);
#endif
+ }
+ mutex_unlock(&rdev->devlist_mtx);
break;
case NETDEV_PRE_UP:
if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-30 10:30 UTC (permalink / raw)
To: Ben Greear; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <4A70C17B.6090309@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
On Wed, 2009-07-29 at 14:39 -0700, Ben Greear wrote:
> On 07/29/2009 02:32 PM, Reinette Chatre wrote:
> > From: Reinette Chatre<reinette.chatre@intel.com>
> >
> > The connection monitor currently relies on probe requests paired
> > with probe responses to ensure that a connection is alive. This is
> > fragile in some environments where probe responses can get lost.
> > When we receive beacons we can also consider the connection to be
> > alive, so cancel connection poll instance when we receive a beacon.
>
> I'm chasing a similar problem while working on virtual STA device
> support in ath5k. I was also going to try sending up to 3 polls before
> giving up on the connection. Does that seems like a valid thing to do?
That seems somewhat better, yeah.
I suspect the real cause of the issue is something else though, like the
probe request not going out properly or the card being in a kind of
'temporary lock-up' state where it's not really doing anything for the
time being -- I've never had a problem on any other (than iwlwifi)
hardware.
Of course, the virtual STA device support stuff potentially has similar
issues, especially if it does channel switching like the ath9k virtual
wiphy stuff.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-30 10:28 UTC (permalink / raw)
To: Ben Greear; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <4A70C8D2.5050100@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Wed, 2009-07-29 at 15:10 -0700, Ben Greear wrote:
> While poking in this code, I think I found a logic bug:
>
> In mlme.c ieee80211_associated, there are several places that do a mod-timer,
> and then goto out. But, out: just does a mod timer again blindly.
>
> Am I missing something, or is this just wrong?
It seems wrong, but it's been rewritten anyway since the version you're
looking at :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Luis Correia @ 2009-07-30 10:06 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-wireless, LKML, John W. Linville, Johannes Berg
In-Reply-To: <1248947740.8925.12.camel@johannes.local>
Hi Mike,
On Thu, Jul 30, 2009 at 10:55, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
>> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
>> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
>> >
>> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
>> >
>> > Sorry, but that '/staging/' thing in there means we cannot support this.
>> > If you must, take your query to the staging list,
>> > devel@driverdev.osuosl.org (according to MAINTAINERS).
>>
>> Forwarded, thanks.
>>
>> ....hm. Does "If you must" mean reports aren't welcome?
>
> To be honest, I don't know. I'd rather see people use the rt2x00 code
> instead of spending time cleaning up that mess (the code you've pasted
> was pretty bad!). But you may or may not find somebody who cares about
> that, just rather unlikely on this list.
What is appreciated is people with time to compare both code paths,
and report some inconsistancies, specially about card initialization
and general handling.
To be hones, we, the rt2x00 team, find Ralink's code to be very
difficult to follow, and combersome most of the times.
But any help is welcome!
>
> johannes
>
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Mike Galbraith @ 2009-07-30 10:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1248947740.8925.12.camel@johannes.local>
On Thu, 2009-07-30 at 11:55 +0200, Johannes Berg wrote:
> On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> > On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> > > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> > >
> > > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> > >
> > > Sorry, but that '/staging/' thing in there means we cannot support this.
> > > If you must, take your query to the staging list,
> > > devel@driverdev.osuosl.org (according to MAINTAINERS).
> >
> > Forwarded, thanks.
> >
> > ....hm. Does "If you must" mean reports aren't welcome?
>
> To be honest, I don't know. I'd rather see people use the rt2x00 code
> instead of spending time cleaning up that mess (the code you've pasted
> was pretty bad!). But you may or may not find somebody who cares about
> that, just rather unlikely on this list.
Understood (and yeah, the source is.. not pretty). Sorry for the noise.
WRT rt2x00 with this adapter, I tried it, was a nogo. If I find time,
I'll reconfigure/report.
-Mike (outta here;)
^ permalink raw reply
* [PATCH] iwlwifi: don't export symbols not needed in other modules
From: Johannes Berg @ 2009-07-30 9:58 UTC (permalink / raw)
To: John Linville; +Cc: Reinette Chatre, linux-wireless
Even with the split into iwlcore/agn/3945 not all symbols
that cross file boundaries are needed in other modules, a
few are only used within iwlcore, for example.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/iwlwifi/iwl-core.c | 3 ---
drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
drivers/net/wireless/iwlwifi/iwl-rx.c | 1 -
drivers/net/wireless/iwlwifi/iwl-sta.c | 1 -
4 files changed, 6 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.c 2009-07-30 11:42:11.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.c 2009-07-30 11:51:28.000000000 +0200
@@ -1139,7 +1139,6 @@ void iwl_set_flags_for_band(struct iwl_p
priv->staging_rxon.flags &= ~RXON_FLG_CCK_MSK;
}
}
-EXPORT_SYMBOL(iwl_set_flags_for_band);
/*
* initialize rxon structure with default values from eeprom
@@ -2289,7 +2288,6 @@ int iwl_send_card_state(struct iwl_priv
return iwl_send_cmd(priv, &cmd);
}
-EXPORT_SYMBOL(iwl_send_card_state);
void iwl_rx_pm_sleep_notif(struct iwl_priv *priv,
struct iwl_rx_mem_buffer *rxb)
@@ -2333,7 +2331,6 @@ void iwl_clear_isr_stats(struct iwl_priv
{
memset(&priv->isr_stats, 0, sizeof(priv->isr_stats));
}
-EXPORT_SYMBOL(iwl_clear_isr_stats);
int iwl_mac_conf_tx(struct ieee80211_hw *hw, u16 queue,
const struct ieee80211_tx_queue_params *params)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-led.c 2009-07-30 11:42:11.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-led.c 2009-07-30 11:50:58.000000000 +0200
@@ -335,7 +335,6 @@ void iwl_leds_background(struct iwl_priv
priv->last_blink_time = jiffies;
priv->last_blink_rate = blink_idx;
}
-EXPORT_SYMBOL(iwl_leds_background);
/* Register all led handler */
int iwl_leds_register(struct iwl_priv *priv)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-rx.c 2009-07-30 11:42:11.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-rx.c 2009-07-30 11:51:15.000000000 +0200
@@ -406,7 +406,6 @@ void iwl_rx_queue_reset(struct iwl_priv
rxq->free_count = 0;
spin_unlock_irqrestore(&rxq->lock, flags);
}
-EXPORT_SYMBOL(iwl_rx_queue_reset);
int iwl_rx_init(struct iwl_priv *priv, struct iwl_rx_queue *rxq)
{
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-sta.c 2009-07-30 11:42:11.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-sta.c 2009-07-30 11:51:07.000000000 +0200
@@ -464,7 +464,6 @@ out:
spin_unlock_irqrestore(&priv->sta_lock, flags);
return ret;
}
-EXPORT_SYMBOL(iwl_remove_station);
/**
* iwl_clear_stations_table - Clear the driver's station table
^ permalink raw reply
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Johannes Berg @ 2009-07-30 9:55 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1248947099.8396.6.camel@marge.simson.net>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> >
> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> >
> > Sorry, but that '/staging/' thing in there means we cannot support this.
> > If you must, take your query to the staging list,
> > devel@driverdev.osuosl.org (according to MAINTAINERS).
>
> Forwarded, thanks.
>
> ....hm. Does "If you must" mean reports aren't welcome?
To be honest, I don't know. I'd rather see people use the rt2x00 code
instead of spending time cleaning up that mess (the code you've pasted
was pretty bad!). But you may or may not find somebody who cares about
that, just rather unlikely on this list.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-30 9:54 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Reinette Chatre, linville, linux-wireless
In-Reply-To: <200907301136.40274.helmut.schaa@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Thu, 2009-07-30 at 11:36 +0200, Helmut Schaa wrote:
> Am Mittwoch, 29. Juli 2009 schrieb Johannes Berg:
> > On Wed, 2009-07-29 at 14:32 -0700, Reinette Chatre wrote:
> > > From: Reinette Chatre <reinette.chatre@intel.com>
> > >
> > > The connection monitor currently relies on probe requests paired
> > > with probe responses to ensure that a connection is alive. This is
> > > fragile in some environments where probe responses can get lost.
> > > When we receive beacons we can also consider the connection to be
> > > alive, so cancel connection poll instance when we receive a beacon.
> > >
> > > The debug message "cancelling probereq poll due to a received beacon"
> > > is removed as part of this change as this case is hit very often after
> > > the above change and debug log receives significant number of these messages.
> >
> > Not doing that was actually intentional -- we want to know whether or
> > not the connection is working both ways, not just whether we can receive
> > frames. This can certainly be improved, but I'm not sure this is the
> > best approach.
>
> Just out of curiosity, do direct probe requests get ACKed?
Yes, they are normal directed management frames.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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