* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 21:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <1256851738.3865.149.camel@johannes.local>
On Thu, Oct 29, 2009 at 2:28 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2009-10-29 at 14:19 -0700, Luis R. Rodriguez wrote:
>> On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
>> > <johannes@sipsolutions.net> wrote:
>> >> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>> >>> I ran into this when ath5k with wpa_supplicant with config file with
>> >>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>> >>> and lets you assoc but later it deauths you -- I guess after it
>> >>> determines you are auth credentials failed. When this happens I get:
>> >>>
>> >>> mcgrof@tux ~ $ iw dev wlan0 link
>> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> >>> Not connected.
>> >>
>> >> I'm guessing that you're using -Dnl80211. You need this patch, or
>> >> equivalent:
>> >> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
>> >
>> > Indeed, it fixes my woes, thanks.
>>
>> Well almost, after a while of being connected it then does this:
>>
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> CTRL-EVENT-SCAN-RESULTS
>> Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
>> Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
>> Associated with 00:0b:85:5b:8d:6c
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> CTRL-EVENT-SCAN-RESULTS
>> Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
>> Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
>> Associated with 00:0b:85:5b:9a:bc
>> CTRL-EVENT-EAP-STARTED EAP authentication started
>> CTRL-EVENT-EAP-STARTED EAP authentication started
>> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
>> OpenSSL: tls_connection_handshake - Failed to read possible
>> Application Data error:00000000:lib(0):func(0):reason(0)
>>
>> And I then end up with the same:
>>
>> >>> mcgrof@tux ~ $ iw dev wlan0 link
>> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> >>> Not connected.
>
> Might be due to that bssid_changed check I was unsure about -- try
> removing that.
OK will do -- it took a while to trigger so will wait and see if it
happens again, and if it happens often enough I can at least confirm
it would fix it. Otherwise not sure what triggered it. I failed to
check the logs to see what disconnect event exactly triggered.
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 21:48 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <84144f020910291245l1a7a3fd6o8822ecd4ce3b5504@mail.gmail.com>
On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> Hi Bart,
>
> On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> lots of cleanups to the staging drivers, why not direct some of that
> >> energy to the drivers/net/wireless ones?
> >
> > When did we start to apply "fix it yourself" rule instead of "submitter
> > should fix it" one to the _new_ code..
>
> Don't be silly, I didn't say that.
Sorry, I must have misunderstood you.
> I was simply pointing out that your time would probably be better
> spent in improving the "proper" ralink wireless drivers but if you
Thanks for the concern. However recent discussions made my realize how
I should really be spending my time effectively way too well.
> _really_ prefer to spend your time in pointless arguments, go ahead.
I don't think that my technical arguments are pointless.
Quite the contrary, I'm pretty confident that addressing my review concerns
would result in better RT28x00 / RT30x0 support in the very near future.
> It should be pretty obvious by now that the best way to improve things
> is to work with the relevant maintainers, not against them. (Unless
> you wish your work to be ignored, of course.)
I work with a lot of other maintainers. I would say that providing valuable
review feedback is also "working with" (at least I would be very happy with
such feedback in my projects).
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* fyi - ath9k virtual wiphy - another thing we would need to synch
From: Luis R. Rodriguez @ 2009-10-29 23:03 UTC (permalink / raw)
To: Jouni.Malinen; +Cc: linux-wireless
sc->sc_ah->opmode
is used and checked for filtering for example, so if another wiphy is
selected it should update its mode there.
Luis
^ permalink raw reply
* OOPS in cfg80211_conn_work
From: Parag Warudkar @ 2009-10-29 23:17 UTC (permalink / raw)
To: LKML; +Cc: linux-wireless
Oct 29 18:59:06 parag-laptop kernel: [ 143.180037] wlan0:
deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
Oct 29 18:59:06 parag-laptop kernel: [ 143.181137] wlan0: direct
probe to AP 00:16:01:d6:6f:12 (try 1)
Oct 29 18:59:06 parag-laptop kernel: [ 143.181148] wlan0:
deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
Oct 29 18:59:06 parag-laptop kernel: [ 143.203375] BUG: unable to
handle kernel NULL pointer dereference at (null)
Oct 29 18:59:06 parag-laptop kernel: [ 143.203432] IP:
[<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.203476] PGD 138abc067 PUD
136d87067 PMD 0
Oct 29 18:59:06 parag-laptop kernel: [ 143.203530] Oops: 0000 [#1] SMP
Oct 29 18:59:06 parag-laptop kernel: [ 143.203571] last sysfs file:
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/controlC1/uevent
Oct 29 18:59:06 parag-laptop kernel: [ 143.203597] CPU 0
Oct 29 18:59:06 parag-laptop kernel: [ 143.203629] Modules linked in:
aes_generic radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea
cfbimgblt cfbfillrect binfmt_misc snd_hda_codec_atihdmi rfcomm
snd_hda_codec_analog sco bnep ppdev l2cap snd_hda_intel arc4
snd_hda_codec snd_pcm_oss snd_mixer_oss snd_hwdep snd_seq_dummy
snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event iwlagn
iptable_filter ext3 snd_seq iwlcore snd_timer led_class snd_seq_device
ip_tables jbd snd mac80211 psmouse btusb x_tables tpm_infineon
soundcore serio_raw bluetooth snd_page_alloc cfg80211 tpm tpm_bios
evdev lp parport ext4 mbcache jbd2 fuse ahci libata video output
intel_agp e1000e
Oct 29 18:59:06 parag-laptop kernel: [ 143.204560] Pid: 9, comm:
events/0 Not tainted 2.6.32-rc5 #2 HP EliteBook 8530p
Oct 29 18:59:06 parag-laptop kernel: [ 143.204588] RIP:
0010:[<ffffffffa0139161>] [<ffffffffa0139161>]
cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.204634] RSP:
0000:ffff88013f8b5dc0 EFLAGS: 00010246
Oct 29 18:59:06 parag-laptop kernel: [ 143.204656] RAX:
0000000000000000 RBX: ffff88013e8db690 RCX: ffff88013cb80118
Oct 29 18:59:06 parag-laptop kernel: [ 143.204679] RDX:
0000000000000000 RSI: 0000000000000282 RDI: ffff88013e8db690
Oct 29 18:59:06 parag-laptop kernel: [ 143.204702] RBP:
ffff88013f8b5e30 R08: 0000000000000000 R09: 0000000000000001
Oct 29 18:59:06 parag-laptop kernel: [ 143.204724] R10:
0000000000000000 R11: ffff880028295718 R12: ffff88013e8db6b8
Oct 29 18:59:06 parag-laptop kernel: [ 143.204747] R13:
ffff88013cb800a8 R14: ffff88013cb80000 R15: ffff88013f8b5df0
Oct 29 18:59:06 parag-laptop kernel: [ 143.204770] FS:
0000000000000000(0000) GS:ffff880028200000(0000)
knlGS:0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.204799] CS: 0010 DS: 0018
ES: 0018 CR0: 000000008005003b
Oct 29 18:59:06 parag-laptop kernel: [ 143.204820] CR2:
0000000000000000 CR3: 000000013dde3000 CR4: 00000000000406f0
Oct 29 18:59:06 parag-laptop kernel: [ 143.204843] DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.204866] DR3:
0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct 29 18:59:06 parag-laptop kernel: [ 143.204889] Process events/0
(pid: 9, threadinfo ffff88013f8b4000, task ffff88013f885980)
Oct 29 18:59:06 parag-laptop kernel: [ 143.204917] Stack:
Oct 29 18:59:06 parag-laptop kernel: [ 143.204936] ffff88013f8b5dc0
ffff88013f8b5dc0 0000000000000282 ffffffff8162afb8
Oct 29 18:59:06 parag-laptop kernel: [ 143.204996] <0>
ffff88013cb80018 ffff88013cb80088 ffff880028218040 ffff88013f8b5fd8
Oct 29 18:59:06 parag-laptop kernel: [ 143.205085] <0>
ffff88013f8b5e10 ffff88013cb80130 ffff880028218040 ffffffffa01390b0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205190] Call Trace:
Oct 29 18:59:06 parag-laptop kernel: [ 143.205215]
[<ffffffffa01390b0>] ? cfg80211_conn_work+0x0/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.205242]
[<ffffffff8106c86f>] worker_thread+0x17f/0x2c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205265]
[<ffffffff810710d0>] ? autoremove_wake_function+0x0/0x40
Oct 29 18:59:06 parag-laptop kernel: [ 143.205289]
[<ffffffff8106c6f0>] ? worker_thread+0x0/0x2c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205311]
[<ffffffff81070cfe>] kthread+0x8e/0xa0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205334]
[<ffffffff81012f2a>] child_rip+0xa/0x20
Oct 29 18:59:06 parag-laptop kernel: [ 143.205356]
[<ffffffff81070c70>] ? kthread+0x0/0xa0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205378]
[<ffffffff81012f20>] ? child_rip+0x0/0x20
Oct 29 18:59:06 parag-laptop kernel: [ 143.205399] Code: 63 28 4c 89
e7 e8 c0 02 2b e1 48 8b 43 20 f6 40 48 01 74 c6 83 bb 8c 00 00 00 01
75 bd 48 8b 83 90 00 00 00 48 89 df 48 8b 40 08 <8b> 10 41 89 17 0f b7
40 04 66 41 89 47 04 e8 fc ee ff ff 85 c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.206242] RIP
[<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.206286] RSP <ffff88013f8b5dc0>
Oct 29 18:59:06 parag-laptop kernel: [ 143.206306] CR2: 0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.206327] ---[ end trace
ccb079f99bd67991 ]---
Oct 29 18:59:58 parag-laptop kernel: Kernel logging (proc) stopped.
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Zhu Yi @ 2009-10-30 2:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, Chatre, Reinette, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1256842728.3865.128.camel@johannes.local>
On Fri, 2009-10-30 at 02:58 +0800, Johannes Berg wrote:
> Step 1)
> fix a few corner cases other drivers might have, and stick the bit
> of
> code iwlwifi has right before passing the frame to mac80211 into
> mac80211 as the first thing it does with the frame
>
> Step 2)
> Look through rx.c and check how much stuff it really needs
> linearised,
> and where. I suspect that most of the time it _only_ needs the first
> two bytes, until it comes to actually passing the frame up.
>
> Step 3)
> After the audit, push down the linearizing to where needed, i.e.
> management frames completely, other frames up to and including the
> ethernet header, software decryption all of the frame
>
> Step 4)
> make software decryption aware of paged SKBs, and remove the
> linearising in that case
Yes, this sounds like a very good plan.
Thanks,
-yi
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-30 5:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910292248.42229.bzolnier@gmail.com>
Hi Bart,
On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.
Pekka
^ permalink raw reply
* Re: [RFC] ath9k: fix listening to idle requests
From: Vasanthakumar Thiagarajan @ 2009-10-30 6:33 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Luis Rodriguez
In-Reply-To: <1256849546-15119-1-git-send-email-lrodriguez@atheros.com>
On Fri, Oct 30, 2009 at 02:22:26AM +0530, Luis Rodriguez wrote:
> The way idle configuration detection was implemented as
> busted due to the fact that it assumed the ath9k virtual wiphy,
> the aphy, would be marked as inactive if it was not used but
> it turns out an aphy is always active if its the only wiphy
> present. We need to distinguish between aphy activity and
> idleness so we now add an idle bool for the aphy and mark
> it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
> from mac80211.
>
> Previous to all_wiphys_idle would never be true when using
> only one device so we never really were using
> IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
> off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
> changes depended on all_wiphys_idle being true either to
> turn the radio on or off. Since it was always false for
> one device this code was doing nothing.
>
> Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>
> Vasanth, what do you think?
Still we will have issue when bringing up a sec wiphy while the
primary wiphy is in idle state. ath9k_start() does not brought up
the newly created wiphy interface when the state of at least one
previously created interface is in ACTIVE state. Unless already
brought up interfaces are put down we hit this situation whenever
we try to bring up a new secondary wiphy interface. So with this
patch the actual h/w will remain radio disabled state even after
a new interface is in active state. We need to bring the h/w into
active state if all old interfaces are in idle state in
ath9k_start().
Vasanth
^ permalink raw reply
* Re: OOPS in cfg80211_conn_work
From: Johannes Berg @ 2009-10-30 6:49 UTC (permalink / raw)
To: Parag Warudkar; +Cc: LKML, linux-wireless
In-Reply-To: <f7848160910291617q2b168089l5ce489d2f47ebe96@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Thu, 2009-10-29 at 19:17 -0400, Parag Warudkar wrote:
> Oct 29 18:59:06 parag-laptop kernel: [ 143.180037] wlan0:
> deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
> Oct 29 18:59:06 parag-laptop kernel: [ 143.181137] wlan0: direct
> probe to AP 00:16:01:d6:6f:12 (try 1)
sorry, I can't read this log. please provide a non-wrapped version
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Johannes Berg @ 2009-10-30 7:00 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel,
linville
In-Reply-To: <200910292248.42229.bzolnier@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
So you know how to make the driver better, whine that it doesn't work,
but don't help out either. Hey, good way to collaborate!
> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
>
> I work with a lot of other maintainers. I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).
Face it though, people have read your feedback, thought about it, and
decided to disagree. You seem to have a childish problem with that,
appealing to higher authority to get your way just makes you look more
childish.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: wpa_supplicant eventual unrecoverable state
From: Johannes Berg @ 2009-10-30 7:16 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jouni.Malinen, linux-wireless
In-Reply-To: <43e72e890910291613u2a00125etfb31c8e95a66a5ea@mail.gmail.com>
On Thu, 2009-10-29 at 16:13 -0700, Luis R. Rodriguez wrote:
> Following up on the thread I started about some odd state
> wpa_supplicant gets into, I now managed to get the dmesg log of this
> happening.
> [10551.652480] wlan1: deauthenticating from 00:0b:85:6f:12:ac by local
> choice (reason=3)
Please everybody take more care to not line-wrap logs.
> [10551.676034] ------------[ cut here ]------------
> [10551.676057] WARNING: at net/mac80211/scan.c:291
> ieee80211_scan_completed+0x26c/0x280 [mac80211]()
> [10551.676061] Hardware name: 7660A14
> [10551.676064] Modules linked in: ath9k ath9k_hw mac80211 ath cfg80211
> aes_generic i915 drm_kms_helper drm i2c_algo_bit binfmt_misc bridge
> stp bnep lp snd_hda_codec_analog snd_hda_intel snd_hda_codec
> snd_pcm_oss snd_mixer_oss arc4 snd_pcm snd_seq_dummy snd_seq_oss
> snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq pcmcia snd_timer
> snd_seq_device ppdev joydev psmouse yenta_socket rsrc_nonstatic snd
> parport_pc hid_microsoft video intel_agp thinkpad_acpi soundcore
> parport serio_raw usbhid output pcmcia_core pcspkr agpgart nvram
> iTCO_wdt led_class btusb snd_page_alloc iTCO_vendor_support ohci1394
> ieee1394 [last unloaded: e1000e]
> [10551.676149] Pid: 8068, comm: wpa_supplicant Tainted: G W
> 2.6.32-rc5-wl #28
> [10551.676153] Call Trace:
> [10551.676162] [<c05a3a03>] ? printk+0x1d/0x22
> [10551.676176] [<fce0916c>] ? ieee80211_scan_completed+0x26c/0x280 [mac80211]
> [10551.676184] [<c0146121>] warn_slowpath_common+0x71/0xd0
> [10551.676198] [<fce0916c>] ? ieee80211_scan_completed+0x26c/0x280 [mac80211]
> [10551.676204] [<c014619a>] warn_slowpath_null+0x1a/0x20
> [10551.676218] [<fce0916c>] ieee80211_scan_completed+0x26c/0x280 [mac80211]
> [10551.676231] [<fce091c9>] ieee80211_scan_cancel+0x49/0x80 [mac80211]
> [10551.676247] [<fce1287a>] ieee80211_stop+0x59a/0x5b0 [mac80211]
> [10551.676254] [<c04e513e>] ? dev_deactivate+0x17e/0x1a0
> [10551.676260] [<c04d34cb>] dev_close+0x6b/0xc0
This patch should help.
johannes
---
net/mac80211/scan.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/mac80211/scan.c 2009-10-30 08:11:52.000000000 +0100
+++ wireless-testing/net/mac80211/scan.c 2009-10-30 08:14:42.000000000 +0100
@@ -288,10 +288,14 @@ void ieee80211_scan_completed(struct iee
mutex_lock(&local->scan_mtx);
- if (WARN_ON(!local->scanning)) {
- mutex_unlock(&local->scan_mtx);
- return;
- }
+ /*
+ * It's ok to abort a not-yet-running scan (that
+ * we have one at all will be verified by checking
+ * local->scan_req next), but not to complete it
+ * successfully.
+ */
+ if (WARN_ON(!local->scanning && !aborted))
+ aborted = true;
if (WARN_ON(!local->scan_req)) {
mutex_unlock(&local->scan_mtx);
^ permalink raw reply
* [RFC] mac80211: make ieee80211_find_sta per virtual interface
From: Johannes Berg @ 2009-10-30 9:58 UTC (permalink / raw)
To: linux-wireless
Cc: Jouni Malinen, Luis R. Rodriguez, Sujith Manoharan,
Vasanthakumar Thiagarajan, Senthil Balasubramanian
Since we have a TODO item to make all station
management dependent on virtual interfaces, I
figured I'd start with pushing such a change
to drivers before more drivers use this kind
of functionality...
The iwlwifi bits are easy, but I don't know
what to do about the ath9k bits. Any ideas?
---
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 3 ++-
drivers/net/wireless/iwlwifi/iwl-core.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 2 +-
include/net/mac80211.h | 4 ++--
net/mac80211/sta_info.c | 7 +++++--
7 files changed, 13 insertions(+), 9 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-3945-rs.c 2009-10-30 10:54:30.000000000 +0100
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-3945-rs.c 2009-10-30 10:54:46.000000000 +0100
@@ -960,7 +960,8 @@ void iwl3945_rate_scale_init(struct ieee
rcu_read_lock();
- sta = ieee80211_find_sta(hw, priv->stations[sta_id].sta.sta.addr);
+ sta = ieee80211_find_sta(priv->vif,
+ priv->stations[sta_id].sta.sta.addr);
if (!sta) {
rcu_read_unlock();
return;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.c 2009-10-30 10:54:50.000000000 +0100
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.c 2009-10-30 10:54:56.000000000 +0100
@@ -2338,7 +2338,7 @@ static void iwl_ht_conf(struct iwl_priv
switch (priv->iw_mode) {
case NL80211_IFTYPE_STATION:
rcu_read_lock();
- sta = ieee80211_find_sta(priv->hw, priv->bssid);
+ sta = ieee80211_find_sta(priv->vif, priv->bssid);
if (sta) {
struct ieee80211_sta_ht_cap *ht_cap = &sta->ht_cap;
int maxstreams;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-sta.c 2009-10-30 10:55:00.000000000 +0100
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-sta.c 2009-10-30 10:55:03.000000000 +0100
@@ -1012,7 +1012,7 @@ int iwl_rxon_add_station(struct iwl_priv
*/
if (priv->current_ht_config.is_ht) {
rcu_read_lock();
- sta = ieee80211_find_sta(priv->hw, addr);
+ sta = ieee80211_find_sta(priv->vif, addr);
if (sta) {
memcpy(&ht_config, &sta->ht_cap, sizeof(ht_config));
cur_ht_config = &ht_config;
--- wireless-testing.orig/include/net/mac80211.h 2009-10-30 10:51:36.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2009-10-30 10:51:58.000000000 +0100
@@ -2106,13 +2106,13 @@ void ieee80211_stop_tx_ba_cb_irqsafe(str
/**
* ieee80211_find_sta - find a station
*
- * @hw: pointer as obtained from ieee80211_alloc_hw()
+ * @vif: virtual interface to look for station on
* @addr: station's address
*
* This function must be called under RCU lock and the
* resulting pointer is only valid under RCU lock as well.
*/
-struct ieee80211_sta *ieee80211_find_sta(struct ieee80211_hw *hw,
+struct ieee80211_sta *ieee80211_find_sta(struct ieee80211_vif *vif,
const u8 *addr);
/**
--- wireless-testing.orig/net/mac80211/sta_info.c 2009-10-30 10:52:13.000000000 +0100
+++ wireless-testing/net/mac80211/sta_info.c 2009-10-30 10:53:07.000000000 +0100
@@ -801,10 +801,13 @@ void ieee80211_sta_expire(struct ieee802
sta_info_destroy(sta);
}
-struct ieee80211_sta *ieee80211_find_sta(struct ieee80211_hw *hw,
+struct ieee80211_sta *ieee80211_find_sta(struct ieee80211_vif *vif,
const u8 *addr)
{
- struct sta_info *sta = sta_info_get(hw_to_local(hw), addr);
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct sta_info *sta;
+
+ sta = sta_info_get(sdata->local, addr);
if (!sta)
return NULL;
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/recv.c 2009-10-30 10:53:27.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ath9k/recv.c 2009-10-30 10:55:38.000000000 +0100
@@ -202,7 +202,7 @@ static int ath_rx_prepare(struct sk_buff
}
rcu_read_lock();
- sta = ieee80211_find_sta(sc->hw, hdr->addr2);
+ sta = ieee80211_find_sta(/*?????*/, hdr->addr2);
if (sta) {
an = (struct ath_node *) sta->drv_priv;
if (ds->ds_rxstat.rs_rssi != ATH9K_RSSI_BAD &&
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/xmit.c 2009-10-30 10:54:10.000000000 +0100
+++ wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c 2009-10-30 10:55:48.000000000 +0100
@@ -282,7 +282,7 @@ static void ath_tx_complete_aggr(struct
rcu_read_lock();
- sta = ieee80211_find_sta(sc->hw, hdr->addr1);
+ sta = ieee80211_find_sta(/*??????*/, hdr->addr1);
if (!sta) {
rcu_read_unlock();
return;
^ permalink raw reply
* Re: OOPS in cfg80211_conn_work
From: Parag Warudkar @ 2009-10-30 10:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: Parag Warudkar, LKML, linux-wireless
In-Reply-To: <1256885343.3555.0.camel@johannes.local>
On Fri, 30 Oct 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 19:17 -0400, Parag Warudkar wrote:
> > Oct 29 18:59:06 parag-laptop kernel: [ 143.180037] wlan0:
> > deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
> > Oct 29 18:59:06 parag-laptop kernel: [ 143.181137] wlan0: direct
> > probe to AP 00:16:01:d6:6f:12 (try 1)
>
> sorry, I can't read this log. please provide a non-wrapped version
>
How does this look? (Sorry sent it in a rush earlier.)
Below also is a disassembly of cfg80211_conn_work.
Thanks
Parag
OOPS
----
Oct 29 18:59:06 parag-laptop kernel: [ 143.181148] wlan0: deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
Oct 29 18:59:06 parag-laptop kernel: [ 143.203375] BUG: unable to handle kernel NULL pointer dereference at (null)
Oct 29 18:59:06 parag-laptop kernel: [ 143.203432] IP: [<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.203476] PGD 138abc067 PUD 136d87067 PMD 0
Oct 29 18:59:06 parag-laptop kernel: [ 143.203530] Oops: 0000 [#1] SMP
Oct 29 18:59:06 parag-laptop kernel: [ 143.203571] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/controlC1/uevent
Oct 29 18:59:06 parag-laptop kernel: [ 143.203597] CPU 0
Oct 29 18:59:06 parag-laptop kernel: [ 143.203629] Modules linked in: aes_generic radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect binfmt_misc snd_hda_codec_atihdmi rfcomm snd_hda_codec_analog sco bnep ppdev l2cap snd_hda_intel arc4 snd_hda_codec snd_pcm_oss snd_mixer_oss snd_hwdep snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event iwlagn iptable_filter ext3 snd_seq iwlcore snd_timer led_class snd_seq_device ip_tables jbd snd mac80211 psmouse btusb x_tables tpm_infineon soundcore serio_raw bluetooth snd_page_alloc cfg80211 tpm tpm_bios evdev lp parport ext4 mbcache jbd2 fuse ahci libata video output intel_agp e1000e
Oct 29 18:59:06 parag-laptop kernel: [ 143.204560] Pid: 9, comm: events/0 Not tainted 2.6.32-rc5 #2 HP EliteBook 8530p
Oct 29 18:59:06 parag-laptop kernel: [ 143.204588] RIP: 0010:[<ffffffffa0139161>] [<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.204634] RSP: 0000:ffff88013f8b5dc0 EFLAGS: 00010246
Oct 29 18:59:06 parag-laptop kernel: [ 143.204656] RAX: 0000000000000000 RBX: ffff88013e8db690 RCX: ffff88013cb80118
Oct 29 18:59:06 parag-laptop kernel: [ 143.204679] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff88013e8db690
Oct 29 18:59:06 parag-laptop kernel: [ 143.204702] RBP: ffff88013f8b5e30 R08: 0000000000000000 R09: 0000000000000001
Oct 29 18:59:06 parag-laptop kernel: [ 143.204724] R10: 0000000000000000 R11: ffff880028295718 R12: ffff88013e8db6b8
Oct 29 18:59:06 parag-laptop kernel: [ 143.204747] R13: ffff88013cb800a8 R14: ffff88013cb80000 R15: ffff88013f8b5df0
Oct 29 18:59:06 parag-laptop kernel: [ 143.204770] FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.204799] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Oct 29 18:59:06 parag-laptop kernel: [ 143.204820] CR2: 0000000000000000 CR3: 000000013dde3000 CR4: 00000000000406f0
Oct 29 18:59:06 parag-laptop kernel: [ 143.204843] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.204866] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct 29 18:59:06 parag-laptop kernel: [ 143.204889] Process events/0 (pid: 9, threadinfo ffff88013f8b4000, task ffff88013f885980)
Oct 29 18:59:06 parag-laptop kernel: [ 143.204917] Stack:
Oct 29 18:59:06 parag-laptop kernel: [ 143.204936] ffff88013f8b5dc0 ffff88013f8b5dc0 0000000000000282 ffffffff8162afb8
Oct 29 18:59:06 parag-laptop kernel: [ 143.204996] <0> ffff88013cb80018 ffff88013cb80088 ffff880028218040 ffff88013f8b5fd8
Oct 29 18:59:06 parag-laptop kernel: [ 143.205085] <0> ffff88013f8b5e10 ffff88013cb80130 ffff880028218040 ffffffffa01390b0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205190] Call Trace:
Oct 29 18:59:06 parag-laptop kernel: [ 143.205215] [<ffffffffa01390b0>] ? cfg80211_conn_work+0x0/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.205242] [<ffffffff8106c86f>] worker_thread+0x17f/0x2c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205265] [<ffffffff810710d0>] ? autoremove_wake_function+0x0/0x40
Oct 29 18:59:06 parag-laptop kernel: [ 143.205289] [<ffffffff8106c6f0>] ? worker_thread+0x0/0x2c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205311] [<ffffffff81070cfe>] kthread+0x8e/0xa0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205334] [<ffffffff81012f2a>] child_rip+0xa/0x20
Oct 29 18:59:06 parag-laptop kernel: [ 143.205356] [<ffffffff81070c70>] ? kthread+0x0/0xa0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205378] [<ffffffff81012f20>] ? child_rip+0x0/0x20
Oct 29 18:59:06 parag-laptop kernel: [ 143.205399] Code: 63 28 4c 89 e7 e8 c0 02 2b e1 48 8b 43 20 f6 40 48 01 74 c6 83 bb 8c 00 00 00 01 75 bd 48 8b 83 90 00 00 00 48 89 df 48 8b 40 08 <8b> 10 41 89 17 0f b7 40 04 66 41 89 47 04 e8 fc ee ff ff 85 c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.206242] RIP [<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.206286] RSP <ffff88013f8b5dc0>
Oct 29 18:59:06 parag-laptop kernel: [ 143.206306] CR2: 0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.206327] ---[ end trace ccb079f99bd67991 ]---
Oct 29 18:59:58 parag-laptop kernel: Kernel logging (proc) stopped.
Disassembly
-----------
00000000000140b0 <cfg80211_conn_work>:
140b0: 55 push %rbp
140b1: 48 89 e5 mov %rsp,%rbp
140b4: 41 57 push %r15
140b6: 4c 8d 7d c0 lea -0x40(%rbp),%r15
140ba: 41 56 push %r14
140bc: 4c 8d b7 d0 fe ff ff lea -0x130(%rdi),%r14
140c3: 41 55 push %r13
140c5: 4d 8d ae a8 00 00 00 lea 0xa8(%r14),%r13
140cc: 41 54 push %r12
140ce: 53 push %rbx
140cf: 48 89 fb mov %rdi,%rbx
140d2: 48 83 ec 48 sub $0x48,%rsp
140d6: e8 00 00 00 00 callq 140db <cfg80211_conn_work+0x2b>
140db: 49 8d 46 18 lea 0x18(%r14),%rax
140df: 48 89 c7 mov %rax,%rdi
140e2: 48 89 45 b0 mov %rax,-0x50(%rbp)
140e6: e8 00 00 00 00 callq 140eb <cfg80211_conn_work+0x3b>
140eb: 49 8d 86 88 00 00 00 lea 0x88(%r14),%rax
140f2: 48 89 45 b8 mov %rax,-0x48(%rbp)
140f6: 48 89 c7 mov %rax,%rdi
140f9: e8 00 00 00 00 callq 140fe <cfg80211_conn_work+0x4e>
140fe: 48 8b 9b 78 ff ff ff mov -0x88(%rbx),%rbx
14105: 48 83 eb 10 sub $0x10,%rbx
14109: eb 15 jmp 14120 <cfg80211_conn_work+0x70>
1410b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
14110: 4c 89 e7 mov %r12,%rdi
14113: e8 00 00 00 00 callq 14118 <cfg80211_conn_work+0x68>
14118: 48 8b 5b 10 mov 0x10(%rbx),%rbx
1411c: 48 83 eb 10 sub $0x10,%rbx
14120: 48 8b 43 10 mov 0x10(%rbx),%rax
14124: 0f 18 08 prefetcht0 (%rax)
14127: 48 8d 43 10 lea 0x10(%rbx),%rax
1412b: 49 39 c5 cmp %rax,%r13
1412e: 0f 84 7c 00 00 00 je 141b0 <cfg80211_conn_work+0x100>
14134: 4c 8d 63 28 lea 0x28(%rbx),%r12
14138: 4c 89 e7 mov %r12,%rdi
1413b: e8 00 00 00 00 callq 14140 <cfg80211_conn_work+0x90>
14140: 48 8b 43 20 mov 0x20(%rbx),%rax
14144: f6 40 48 01 testb $0x1,0x48(%rax)
14148: 74 c6 je 14110 <cfg80211_conn_work+0x60>
1414a: 83 bb 8c 00 00 00 01 cmpl $0x1,0x8c(%rbx)
14151: 75 bd jne 14110 <cfg80211_conn_work+0x60>
14153: 48 8b 83 90 00 00 00 mov 0x90(%rbx),%rax
1415a: 48 89 df mov %rbx,%rdi
1415d: 48 8b 40 08 mov 0x8(%rax),%rax
14161: 8b 10 mov (%rax),%edx
14163: 41 89 17 mov %edx,(%r15)
14166: 0f b7 40 04 movzwl 0x4(%rax),%eax
1416a: 66 41 89 47 04 mov %ax,0x4(%r15)
1416f: e8 fc ee ff ff callq 13070 <cfg80211_conn_do_work>
14174: 85 c0 test %eax,%eax
14176: 74 98 je 14110 <cfg80211_conn_work+0x60>
14178: 48 8b 7b 20 mov 0x20(%rbx),%rdi
1417c: 45 31 c9 xor %r9d,%r9d
1417f: 48 c7 44 24 10 00 00 movq $0x0,0x10(%rsp)
14186: 00 00
14188: c7 44 24 08 00 00 00 movl $0x0,0x8(%rsp)
1418f: 00
14190: c7 04 24 01 00 00 00 movl $0x1,(%rsp)
14197: 45 31 c0 xor %r8d,%r8d
1419a: 31 c9 xor %ecx,%ecx
1419c: 31 d2 xor %edx,%edx
1419e: 4c 89 fe mov %r15,%rsi
141a1: e8 00 00 00 00 callq 141a6 <cfg80211_conn_work+0xf6>
141a6: e9 65 ff ff ff jmpq 14110 <cfg80211_conn_work+0x60>
141ab: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
141b0: 48 8b 7d b8 mov -0x48(%rbp),%rdi
141b4: e8 00 00 00 00 callq 141b9 <cfg80211_conn_work+0x109>
141b9: 49 81 fe 00 f0 ff ff cmp $0xfffffffffffff000,%r14
141c0: 77 27 ja 141e9 <cfg80211_conn_work+0x139>
141c2: 4d 85 f6 test %r14,%r14
141c5: 74 22 je 141e9 <cfg80211_conn_work+0x139>
141c7: 48 8b 7d b0 mov -0x50(%rbp),%rdi
141cb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
141d0: e8 00 00 00 00 callq 141d5 <cfg80211_conn_work+0x125>
141d5: e8 00 00 00 00 callq 141da <cfg80211_conn_work+0x12a>
141da: 48 83 c4 48 add $0x48,%rsp
141de: 5b pop %rbx
141df: 41 5c pop %r12
141e1: 41 5d pop %r13
141e3: 41 5e pop %r14
141e5: 41 5f pop %r15
141e7: c9 leaveq
141e8: c3 retq
141e9: 0f 0b ud2a
141eb: eb fe jmp 141eb <cfg80211_conn_work+0x13b>
141ed: 0f 1f 00 nopl (%rax)
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Jarek Poplawski @ 2009-10-30 11:06 UTC (permalink / raw)
To: Johannes Berg
Cc: Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <1256886023.3555.5.camel@johannes.local>
On 30-10-2009 08:00, Johannes Berg wrote:
> On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:
>
>> I don't think that my technical arguments are pointless.
>>
>> Quite the contrary, I'm pretty confident that addressing my review concerns
>> would result in better RT28x00 / RT30x0 support in the very near future.
>
> So you know how to make the driver better, whine that it doesn't work,
> but don't help out either. Hey, good way to collaborate!
>
>>> It should be pretty obvious by now that the best way to improve things
>>> is to work with the relevant maintainers, not against them. (Unless
>>> you wish your work to be ignored, of course.)
>> I work with a lot of other maintainers. I would say that providing valuable
>> review feedback is also "working with" (at least I would be very happy with
>> such feedback in my projects).
>
> Face it though, people have read your feedback, thought about it, and
> decided to disagree. You seem to have a childish problem with that,
> appealing to higher authority to get your way just makes you look more
> childish.
There are various ways to disagree, and ignoring by John questions
from a merited developer both in this referenced lkml and current
threads looks at least strange (if not offensive) as well.
Jarek P.
^ permalink raw reply
* Re: [PATCH 2.6.32] mac80211: split hardware scan by band
From: Luciano Coelho @ 2009-10-30 11:43 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1256675077.4237.26.camel@johannes.local>
ext Johannes Berg wrote:
> On Tue, 2009-10-27 at 20:59 +0100, Johannes Berg wrote:
>
>> Fix this by splitting up cfg80211 scan requests by
>> band -- recalculating the IEs every time -- and
>> requesting only per-band scans from the driver.
>
> Incidentally, this means that dual-band drivers now absolutely need to
> take a look at the scan channel list that is provided since if they
> ignore it they will end up doing two full scans instead of one. Since
> wl1271 is the only driver this affects right now, and its 5ghz support
> is disabled, this seems ok to me.
Sorry for the late response.
This is fine with me. We added one item to handle this on our 5GHz TODO list.
We're unfortunately not working with 5GHz at the moment, but we'll hopefully do
so in the near future (prioritization and stuff).
I said to you that I would add a FIXME in the code, but I think this is not
really necessary, because 5GHz is not fully working anyway, there is definitely
still some work to be done (and that's why it is disabled).
--
Cheers,
Luca.
^ permalink raw reply
* Re: OOPS in cfg80211_conn_work
From: Johannes Berg @ 2009-10-30 11:50 UTC (permalink / raw)
To: Parag Warudkar; +Cc: LKML, linux-wireless
In-Reply-To: <alpine.DEB.2.00.0910300652350.2223@parag-laptop>
On Fri, 2009-10-30 at 06:57 -0400, Parag Warudkar wrote:
>
> On Fri, 30 Oct 2009, Johannes Berg wrote:
>
> > On Thu, 2009-10-29 at 19:17 -0400, Parag Warudkar wrote:
> > > Oct 29 18:59:06 parag-laptop kernel: [ 143.180037] wlan0:
> > > deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
> > > Oct 29 18:59:06 parag-laptop kernel: [ 143.181137] wlan0: direct
> > > probe to AP 00:16:01:d6:6f:12 (try 1)
> >
> > sorry, I can't read this log. please provide a non-wrapped version
> >
> How does this look? (Sorry sent it in a rush earlier.)
> Below also is a disassembly of cfg80211_conn_work.
Thanks. I was going to ask for disassembly but you preempted me, I like
that :)
Since you say you can easily reproduce this, can you try the patch
below?
johannes
---
net/wireless/sme.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- wireless-testing.orig/net/wireless/sme.c 2009-10-30 12:48:09.000000000 +0100
+++ wireless-testing/net/wireless/sme.c 2009-10-30 12:48:41.000000000 +0100
@@ -165,7 +165,7 @@ void cfg80211_conn_work(struct work_stru
struct cfg80211_registered_device *rdev =
container_of(work, struct cfg80211_registered_device, conn_work);
struct wireless_dev *wdev;
- u8 bssid[ETH_ALEN];
+ u8 bssid_buf[ETH_ALEN], *bssid = NULL;
rtnl_lock();
cfg80211_lock_rdev(rdev);
@@ -181,7 +181,10 @@ void cfg80211_conn_work(struct work_stru
wdev_unlock(wdev);
continue;
}
- memcpy(bssid, wdev->conn->params.bssid, ETH_ALEN);
+ if (wdev->conn->params.bssid) {
+ memcpy(bssid_buf, wdev->conn->params.bssid, ETH_ALEN);
+ bssid = bssid_buf;
+ }
if (cfg80211_conn_do_work(wdev))
__cfg80211_connect_result(
wdev->netdev, bssid,
^ permalink raw reply
* [PATCH] mac80211: also drop qos-nullfunc frames silently
From: Johannes Berg @ 2009-10-30 11:55 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Jouni Malinen
We drop nullfunc frames, but not qos-nullfunc frames,
even though those could be used for PS state control
as well.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/linux/ieee80211.h | 12 +++++++++++-
net/mac80211/rx.c | 15 ++++++++++-----
2 files changed, 21 insertions(+), 6 deletions(-)
--- wireless-testing.orig/include/linux/ieee80211.h 2009-10-30 08:18:15.000000000 +0100
+++ wireless-testing/include/linux/ieee80211.h 2009-10-30 08:19:40.000000000 +0100
@@ -472,7 +472,7 @@ static inline int ieee80211_is_cfendack(
}
/**
- * ieee80211_is_nullfunc - check if FTYPE=IEEE80211_FTYPE_DATA and STYPE=IEEE80211_STYPE_NULLFUNC
+ * ieee80211_is_nullfunc - check if frame is a regular (non-QoS) nullfunc frame
* @fc: frame control bytes in little-endian byteorder
*/
static inline int ieee80211_is_nullfunc(__le16 fc)
@@ -481,6 +481,16 @@ static inline int ieee80211_is_nullfunc(
cpu_to_le16(IEEE80211_FTYPE_DATA | IEEE80211_STYPE_NULLFUNC);
}
+/**
+ * ieee80211_is_qos_nullfunc - check if frame is a QoS nullfunc frame
+ * @fc: frame control bytes in little-endian byteorder
+ */
+static inline int ieee80211_is_qos_nullfunc(__le16 fc)
+{
+ return (fc & cpu_to_le16(IEEE80211_FCTL_FTYPE | IEEE80211_FCTL_STYPE)) ==
+ cpu_to_le16(IEEE80211_FTYPE_DATA | IEEE80211_STYPE_QOS_NULLFUNC);
+}
+
struct ieee80211s_hdr {
u8 flags;
u8 ttl;
--- wireless-testing.orig/net/mac80211/rx.c 2009-10-30 08:18:15.000000000 +0100
+++ wireless-testing/net/mac80211/rx.c 2009-10-30 08:18:29.000000000 +0100
@@ -886,12 +886,17 @@ ieee80211_rx_h_sta_process(struct ieee80
}
}
- /* Drop data::nullfunc frames silently, since they are used only to
- * control station power saving mode. */
- if (ieee80211_is_nullfunc(hdr->frame_control)) {
+ /*
+ * Drop (qos-)data::nullfunc frames silently, since they
+ * are used only to control station power saving mode.
+ */
+ if (ieee80211_is_nullfunc(hdr->frame_control) ||
+ ieee80211_is_qos_nullfunc(hdr->frame_control)) {
I802_DEBUG_INC(rx->local->rx_handlers_drop_nullfunc);
- /* Update counter and free packet here to avoid counting this
- * as a dropped packed. */
+ /*
+ * Update counter and free packet here to avoid
+ * counting this as a dropped packed.
+ */
sta->rx_packets++;
dev_kfree_skb(rx->skb);
return RX_QUEUED;
^ permalink raw reply
* [PATCH] mac80211: remove sent_ps_buffered
From: Johannes Berg @ 2009-10-30 11:56 UTC (permalink / raw)
To: John Linville; +Cc: Jouni Malinen, linux-wireless
This variable is set once, and tested once.
However, the code path that can set it is
mutually exclusive with the code path that
tests it, so the test is always true. Thus
we also don't need to set it either and can
just remove the variable.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/ieee80211_i.h | 1 -
net/mac80211/rx.c | 8 +++-----
2 files changed, 3 insertions(+), 6 deletions(-)
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2009-10-30 11:58:19.000000000 +0100
+++ wireless-testing/net/mac80211/ieee80211_i.h 2009-10-30 11:58:23.000000000 +0100
@@ -176,7 +176,6 @@ struct ieee80211_rx_data {
struct ieee80211_rate *rate;
unsigned int flags;
- int sent_ps_buffered;
int queue;
u32 tkip_iv32;
u16 tkip_iv16;
--- wireless-testing.orig/net/mac80211/rx.c 2009-10-30 11:58:27.000000000 +0100
+++ wireless-testing/net/mac80211/rx.c 2009-10-30 11:59:39.000000000 +0100
@@ -789,7 +789,7 @@ static void ap_sta_ps_start(struct sta_i
#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
}
-static int ap_sta_ps_end(struct sta_info *sta)
+static void ap_sta_ps_end(struct sta_info *sta)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
struct ieee80211_local *local = sdata->local;
@@ -819,8 +819,6 @@ static int ap_sta_ps_end(struct sta_info
"since STA not sleeping anymore\n", sdata->dev->name,
sta->sta.addr, sta->sta.aid, sent - buffered, buffered);
#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
-
- return sent;
}
static ieee80211_rx_result debug_noinline
@@ -879,7 +877,7 @@ ieee80211_rx_h_sta_process(struct ieee80
*/
if (ieee80211_is_data(hdr->frame_control) &&
!ieee80211_has_pm(hdr->frame_control))
- rx->sent_ps_buffered += ap_sta_ps_end(sta);
+ ap_sta_ps_end(sta);
} else {
if (ieee80211_has_pm(hdr->frame_control))
ap_sta_ps_start(sta);
@@ -1147,7 +1145,7 @@ ieee80211_rx_h_ps_poll(struct ieee80211_
if (no_pending_pkts)
sta_info_clear_tim_bit(rx->sta);
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
- } else if (!rx->sent_ps_buffered) {
+ } else {
/*
* FIXME: This can be the result of a race condition between
* us expiring a frame and the station polling for it.
^ permalink raw reply
* Re: [RFC] ath9k: fix listening to idle requests
From: Luis R. Rodriguez @ 2009-10-30 14:38 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Luis Rodriguez
In-Reply-To: <20091030063306.GH4602@vasanth-laptop>
On Thu, Oct 29, 2009 at 11:33 PM, Vasanthakumar Thiagarajan
<vasanth@atheros.com> wrote:
> On Fri, Oct 30, 2009 at 02:22:26AM +0530, Luis Rodriguez wrote:
>> The way idle configuration detection was implemented as
>> busted due to the fact that it assumed the ath9k virtual wiphy,
>> the aphy, would be marked as inactive if it was not used but
>> it turns out an aphy is always active if its the only wiphy
>> present. We need to distinguish between aphy activity and
>> idleness so we now add an idle bool for the aphy and mark
>> it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
>> from mac80211.
>>
>> Previous to all_wiphys_idle would never be true when using
>> only one device so we never really were using
>> IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
>> off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
>> changes depended on all_wiphys_idle being true either to
>> turn the radio on or off. Since it was always false for
>> one device this code was doing nothing.
>>
>> Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>>
>> Vasanth, what do you think?
>
> Still we will have issue when bringing up a sec wiphy while the
> primary wiphy is in idle state. ath9k_start() does not brought up
> the newly created wiphy interface when the state of at least one
> previously created interface is in ACTIVE state. Unless already
> brought up interfaces are put down we hit this situation whenever
> we try to bring up a new secondary wiphy interface. So with this
> patch the actual h/w will remain radio disabled state even after
> a new interface is in active state. We need to bring the h/w into
> active state if all old interfaces are in idle state in
> ath9k_start().
I don't see what prevents a secondary virtual wiphy from getting the
radio started -- perhaps I'm missing something. When a virtual wiphy
needs to become non-idle that'll come from the mac80211 non-idle
config call and that will find that one device is non-idle and hence
start it. Unfortunately I don't have time to test this though so I
cannot be sure this indeed will work.
Luis
^ permalink raw reply
* [PATCH resend] mac80211: remove bogus code
From: Johannes Berg @ 2009-10-30 14:48 UTC (permalink / raw)
To: John Linville; +Cc: Jouni Malinen, linux-wireless
In-Reply-To: <1254261794.30589.24.camel@johannes.local>
It's not right to do something here when returning an
error, and hostapd should never have relied on it as
it only fixes up a small part of the problem anyway.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/cfg.c | 7 -------
1 file changed, 7 deletions(-)
--- wireless-testing.orig/net/mac80211/cfg.c 2009-10-27 09:06:22.000000000 +0100
+++ wireless-testing/net/mac80211/cfg.c 2009-10-27 09:42:05.000000000 +0100
@@ -738,13 +738,6 @@ static int ieee80211_add_station(struct
err = sta_info_insert(sta);
if (err) {
- /* STA has been freed */
- if (err == -EEXIST && layer2_update) {
- /* Need to update layer 2 devices on reassociation */
- sta = sta_info_get(local, mac);
- if (sta)
- ieee80211_send_layer2_update(sta);
- }
rcu_read_unlock();
return err;
}
^ permalink raw reply
* Re: [RFC] mac80211: make ieee80211_find_sta per virtual interface
From: Luis R. Rodriguez @ 2009-10-30 15:02 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Jouni Malinen, Sujith Manoharan,
Vasanthakumar Thiagarajan, Senthil Balasubramanian
In-Reply-To: <1256896722.3555.39.camel@johannes.local>
On Fri, Oct 30, 2009 at 2:58 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Since we have a TODO item to make all station
> management dependent on virtual interfaces, I
> figured I'd start with pushing such a change
> to drivers before more drivers use this kind
> of functionality...
>
> The iwlwifi bits are easy, but I don't know
> what to do about the ath9k bits. Any ideas?
> --- wireless-testing.orig/drivers/net/wireless/ath/ath9k/xmit.c 2009-10-30 10:54:10.000000000 +0100
> +++ wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c 2009-10-30 10:55:48.000000000 +0100
> @@ -282,7 +282,7 @@ static void ath_tx_complete_aggr(struct
>
> rcu_read_lock();
>
> - sta = ieee80211_find_sta(sc->hw, hdr->addr1);
> + sta = ieee80211_find_sta(/*??????*/, hdr->addr1);
Not sure but I just wanted to point out the that the sc->hw above here
was wrong anyway for virtual wiphy support, this should instead
probably look for the aphy with ath_get_virt_hw() as is done with
ath_rx_prepare().
Luis
^ permalink raw reply
* Re: fyi - ath9k virtual wiphy - another thing we would need to synch
From: Luis R. Rodriguez @ 2009-10-30 15:09 UTC (permalink / raw)
To: Jouni.Malinen; +Cc: linux-wireless
In-Reply-To: <43e72e890910291603h1b836cdx378a2a49d7421390@mail.gmail.com>
On Thu, Oct 29, 2009 at 4:03 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> sc->sc_ah->opmode
Oh and where this is used we could probably just use the hw->conf->type
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-10-30 15:14 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <200910292248.42229.bzolnier@gmail.com>
On Thu, Oct 29, 2009 at 10:48:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> > I was simply pointing out that your time would probably be better
> > spent in improving the "proper" ralink wireless drivers but if you
>
> Thanks for the concern. However recent discussions made my realize how
> I should really be spending my time effectively way too well.
>
> > _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
More like "petty"...
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
Yeah, maybe. Or they could just waste someone's time mashing
together some definitions to prematurely turn two header files into
three instead of spending that time on resolving operational issues.
In either case it is a judgment call, and IMHO not your call to make.
> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
>
> I work with a lot of other maintainers. I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).
"Valuable" feedback would be welcome. In fact, your initial feedback
in this case was welcome -- even moreso had it included a patch.
Your arrogant follow-ups and self-righteous indignation, however,
is quite a bit less welcome. Please take it somewhere else.
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 2009-10-28
From: John W. Linville @ 2009-10-30 15:02 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Johannes Berg, Bartlomiej Zolnierkiewicz, Pekka Enberg,
David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091030110616.GB6150@ff.dom.local>
On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
> There are various ways to disagree, and ignoring by John questions
> from a merited developer both in this referenced lkml and current
> threads looks at least strange (if not offensive) as well.
Did you read the thread for which Bartlomiej provided a link earlier?
There were ten responses (only three of them from him) in that thread.
His comments were not ignored, they were rejected.
Ever since Bartlomiej decided to tear himself away from
drivers/staging, he has been nothing but negative -- petty, whining,
indignat, whatever. Just what has he done to merit any special
consideration here? Why should he have any sort of veto over rt2x00?
And of all things on which to take a stand -- how dare the rt2x00 guys
use two header files instead of three? The nerve of those people!!!
Ridiculous...
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
* [PATCH] b43legacy: Fix DMA TX bounce buffer copying
From: Larry Finger @ 2009-10-30 16:58 UTC (permalink / raw)
To: John W Linville; +Cc: bcm43xx-dev, linux-wireless
This patch is adapted from the submission by Michael Buesch <mb@bu3sch.de>
for a bounce-buffer copying problem with b43.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
Full testing of this patch is a problem as the bounce buffer can come into
play only when the test machine has more than 1 GB RAM. When I coded the
original bounce-buffer code for bcm43xx, I had such a machine, but it
died. I tested the patch on a machine with 256 MB and it works. As it
is a line-by-line copy of Michael's patch, it should be OK. In any case, this
is 2.6.33 material.
Larry
---
Index: wireless-testing/drivers/net/wireless/b43legacy/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43legacy/dma.c
+++ wireless-testing/drivers/net/wireless/b43legacy/dma.c
@@ -1240,8 +1240,9 @@ struct b43legacy_dmaring *parse_cookie(s
}
static int dma_tx_fragment(struct b43legacy_dmaring *ring,
- struct sk_buff *skb)
+ struct sk_buff **in_skb)
{
+ struct sk_buff *skb = *in_skb;
const struct b43legacy_dma_ops *ops = ring->ops;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
u8 *header;
@@ -1305,8 +1306,14 @@ static int dma_tx_fragment(struct b43leg
}
memcpy(skb_put(bounce_skb, skb->len), skb->data, skb->len);
+ memcpy(bounce_skb->cb, skb->cb, sizeof(skb->cb));
+ bounce_skb->dev = skb->dev;
+ skb_set_queue_mapping(bounce_skb, skb_get_queue_mapping(skb));
+ info = IEEE80211_SKB_CB(bounce_skb);
+
dev_kfree_skb_any(skb);
skb = bounce_skb;
+ *in_skb = bounce_skb;
meta->skb = skb;
meta->dmaaddr = map_descbuffer(ring, skb->data, skb->len, 1);
if (b43legacy_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
@@ -1360,8 +1367,10 @@ int b43legacy_dma_tx(struct b43legacy_wl
struct sk_buff *skb)
{
struct b43legacy_dmaring *ring;
+ struct ieee80211_hdr *hdr;
int err = 0;
unsigned long flags;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
ring = priority_to_txring(dev, skb_get_queue_mapping(skb));
spin_lock_irqsave(&ring->lock, flags);
@@ -1386,7 +1395,11 @@ int b43legacy_dma_tx(struct b43legacy_wl
goto out_unlock;
}
- err = dma_tx_fragment(ring, skb);
+ /* dma_tx_fragment might reallocate the skb, so invalidate pointers pointing
+ * into the skb data or cb now. */
+ hdr = NULL;
+ info = NULL;
+ err = dma_tx_fragment(ring, &skb);
if (unlikely(err == -ENOKEY)) {
/* Drop this packet, as we don't have the encryption key
* anymore and must not transmit it unencrypted. */
^ permalink raw reply
* [PATCH] libertas if_usb: Fix crash on 64-bit machines
From: David Woodhouse @ 2009-10-30 17:45 UTC (permalink / raw)
To: linville; +Cc: libertas-dev, linux-wireless, dcbw, stern, davem
On a 64-bit kernel, skb->tail is an offset, not a pointer. The libertas
usb driver passes it to usb_fill_bulk_urb() anyway, causing interesting
crashes. Fix that by using skb->data instead.
This highlights a problem with usb_fill_bulk_urb(). It doesn't notice
when dma_map_single() fails and return the error to its caller as it
should. In fact it _can't_ currently return the error, since it returns
void.
So this problem was showing up only at unmap time, after we'd already
suffered memory corruption by doing DMA to a bogus address.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org
---
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index 92bc8c5..3fac4ef 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -508,7 +508,7 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
/* Fill the receive configuration URB and initialise the Rx call back */
usb_fill_bulk_urb(cardp->rx_urb, cardp->udev,
usb_rcvbulkpipe(cardp->udev, cardp->ep_in),
- (void *) (skb->tail + (size_t) IPFIELD_ALIGN_OFFSET),
+ skb->data + IPFIELD_ALIGN_OFFSET,
MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
cardp);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox