rt2500pci 2.0.9 not working

rt2500pci 2.0.9 not working

[Marcus Better]

I just tried the rt2500pci driver version 2.0.9 from the wireless-2.6 tree.
It does not work. There is no connection, and "iwlist scan" produces no
scan results.

I'm successfully using version 2.0.7 from wireless-dev (2.6.23-rc3 i386) on
this LG laptop.

Marcus

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Marcus Better wrote:

> I just tried the rt2500pci driver version 2.0.9 from the wireless-2.6
> tree. It does not work.

Neither does 2.0.10 from the current wireless-2.6 "everything" branch. I see scan results now but cannot associate with the access point using WEP.

Here are some logs:

Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - Start initialization from EEPROM...
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x0f, value: 0x30.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x11, value: 0x26.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x15, value: 0x18.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x16, value: 0x18.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x35, value: 0x10.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x36, value: 0x10.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x3d, value: 0x6a.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x3e, value: 0x10.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x23, value: 0x50.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x29, value: 0x60.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x36, value: 0x18.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x3e, value: 0x00.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - ...End initialization from EEPROM.
Oct 10 10:26:27 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 10 10:26:27 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 10 10:26:27 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 6, CWmax: 10, Aifs: 2.
Oct 10 10:26:27 better kernel: wlan0: Initial auth_alg=0
Oct 10 10:26:27 better kernel: wlan0: authenticate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: RX authentication from 00:14:6c:a7:60:10 (alg=0 transaction=2 status=0)
Oct 10 10:26:27 better kernel: wlan0: authenticated
Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
Oct 10 10:26:27 better kernel: wlan0: association with AP 00:14:6c:a7:60:10 timed out

Thanks,

Marcus

Re: rt2500pci 2.0.9 not working

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Wed, 2007-10-10 at 11:06 +0200, Marcus Better wrote:

> Neither does 2.0.10 from the current wireless-2.6 "everything" branch.
> I see scan results now but cannot associate with the access point
> using WEP.

Can you try that patch from Matthias Nissler ("[PATCH] mac80211: Defer
setting of RX_FLAG_DECRYPTED.")?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Johannes Berg wrote:
> Can you try that patch from Matthias Nissler ("[PATCH] mac80211: Defer
> setting of RX_FLAG_DECRYPTED.")?

It's already in the tree I used.

Marcus

Re: rt2500pci 2.0.9 not working

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Wed, 2007-10-10 at 11:43 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > Can you try that patch from Matthias Nissler ("[PATCH] mac80211: Defer
> > setting of RX_FLAG_DECRYPTED.")?
> 
> It's already in the tree I used.

Hm, right, noticed that it was merged right after sending this. Reason
19 seems totally unrelated to crypto:
WLAN_STATUS_ASSOC_DENIED_NOSHORTPREAMBLE = 19

Looking at the code... Ahh, I see. You've selected the B mode instead of
G and the AP requires G. I think my "[PATCH] mac80211: fix set_channel
regression" will fix this for you.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Johannes Berg wrote:
> Looking at the code... Ahh, I see. You've selected the B mode instead of
> G and the AP requires G. I think my "[PATCH] mac80211: fix set_channel
> regression" will fix this for you.

No, I still get the same result.

Marcus

Re: rt2500pci 2.0.9 not working

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Wed, 2007-10-10 at 12:56 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > Looking at the code... Ahh, I see. You've selected the B mode instead of
> > G and the AP requires G. I think my "[PATCH] mac80211: fix set_channel
> > regression" will fix this for you.
> 
> No, I still get the same result.

The same error 19? That's weird because if you select a G mode we do
advertise short slot/short preamble.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Johannes Berg wrote:
> The same error 19?

Precisely. I'm quite sure it did recompile ieee80211_ioctl.c after I applied
your patch, and I've double-checked that I installed the correct kernel...

Oct 10 12:53:59 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured
TX ring 0 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 10 12:53:59 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured
TX ring 1 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 10 12:53:59 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured
TX ring 7 - CWmin: 6, CWmax: 10, Aifs: 2.
Oct 10 12:53:59 better kernel: wlan0: Initial auth_alg=0
Oct 10 12:53:59 better kernel: wlan0: authenticate with AP 00:14:6c:a7:60:10
Oct 10 12:53:59 better kernel: wlan0: RX authentication from
00:14:6c:a7:60:10 (alg=0 transaction=2 status=0)
Oct 10 12:53:59 better kernel: wlan0: authenticated
Oct 10 12:53:59 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 12:53:59 better kernel: wlan0: invalid aid value 0; bits 15:14 not
set
Oct 10 12:53:59 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10
(capab=0x431 status=19 aid=0)
Oct 10 12:53:59 better kernel: wlan0: AP denied association (code=19)
Oct 10 12:53:59 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 12:53:59 better kernel: wlan0: invalid aid value 0; bits 15:14 not
set
Oct 10 12:53:59 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10
(capab=0x431 status=19 aid=0)
Oct 10 12:53:59 better kernel: wlan0: AP denied association (code=19)
Oct 10 12:53:59 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 12:53:59 better kernel: wlan0: invalid aid value 0; bits 15:14 not
set
Oct 10 12:53:59 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10
(capab=0x431 status=19 aid=0)
Oct 10 12:53:59 better kernel: wlan0: AP denied association (code=19)
Oct 10 12:53:59 better kernel: wlan0: association with AP 00:14:6c:a7:60:10
timed out

> That's weird because if you select a G mode we do 
> advertise short slot/short preamble.

Can I select the mode from the command line?

Marcus

Re: rt2500pci 2.0.9 not working

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

First a note: could you please send me copies of mail using
reply-to-all? I frequently simply skim over mailing lists and just
almost missed your mail. I don't do that with my inbox...

> Precisely. I'm quite sure it did recompile ieee80211_ioctl.c after I applied
> your patch, and I've double-checked that I installed the correct kernel...

:)


> > That's weird because if you select a G mode we do 
> > advertise short slot/short preamble.
> 
> Can I select the mode from the command line?

No, but you can comment out the B mode registration in rt2500pci and see
if that helps.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Johannes Berg wrote:
> First a note: could you please send me copies of mail using
> reply-to-all?

Yes, sorry, I was using Gmane and Knode, and one of them seems to munge
the other recipients.

> No, but you can comment out the B mode registration in rt2500pci and see
> if that helps.

I have very limited time to find out how to do that, but will gladly try a
patch...

Thanks,

Marcus

Re: rt2500pci 2.0.9 not working

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Thu, 2007-10-11 at 11:05 +0200, Marcus Better wrote:

> > No, but you can comment out the B mode registration in rt2500pci and see
> > if that helps.
> 
> I have very limited time to find out how to do that, but will gladly try a
> patch...

Me neither. It seems to be in rt2x00dev.c, Ivo can you help maybe? Just
for debugging. I'd have thought that adding the 'break' statement would
fix it.

Alternatively, could you print out the selected mode in
ieee80211_ioctl.c:ieee80211_set_channel?

something like
printk(KERN_DEBUG "selected mode %d\n", local->oper_hw_mode->mode);
printk(KERN_DEBUG "select channel %d\n", local->oper_channel);

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt2500pci 2.0.9 not working

[Ivo van Doorn]

On Thursday 11 October 2007, Johannes Berg wrote:
> On Thu, 2007-10-11 at 11:05 +0200, Marcus Better wrote:
> 
> > > No, but you can comment out the B mode registration in rt2500pci and see
> > > if that helps.
> > 
> > I have very limited time to find out how to do that, but will gladly try a
> > patch...
> 
> Me neither. It seems to be in rt2x00dev.c, Ivo can you help maybe? Just
> for debugging. I'd have thought that adding the 'break' statement would
> fix it.

Patch added below.

> Alternatively, could you print out the selected mode in
> ieee80211_ioctl.c:ieee80211_set_channel?
> 
> something like
> printk(KERN_DEBUG "selected mode %d\n", local->oper_hw_mode->mode);
> printk(KERN_DEBUG "select channel %d\n", local->oper_channel);

---

diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 360f03a..89470c0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -866,9 +866,9 @@ static int rt2x00lib_probe_hw_modes(struct rt2x00_dev *rt2x00dev,
 	    ieee80211_register_hwmode(hw, &hwmodes[HWMODE_G]))
 		goto exit_free_rates;
 
-	if (spec->num_modes > HWMODE_B &&
+	/*if (spec->num_modes > HWMODE_B &&
 	    ieee80211_register_hwmode(hw, &hwmodes[HWMODE_B]))
-		goto exit_free_rates;
+		goto exit_free_rates;*/
 
 	if (spec->num_modes > HWMODE_A &&
 	    ieee80211_register_hwmode(hw, &hwmodes[HWMODE_A]))
 

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Ivo van Doorn wrote:
> Patch added below.

Kind-of works. I can connect but only at 1 Mb according to iwconfig.

>> printk(KERN_DEBUG "selected mode %d\n", local->oper_hw_mode->mode);
>> printk(KERN_DEBUG "select channel %d\n", local->oper_channel);

Oct 12 10:47:23 better kernel: selected mode 2
Oct 12 10:47:23 better kernel: select channel -539241232

Marcus

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Marcus Better wrote:
> Kind-of works. I can connect but only at 1 Mb according to iwconfig.

Now I see that I got the same result even with driver version 2.0.7. I can
change it with iwconfig though. Is this normal?

Marcus

Re: rt2500pci 2.0.9 not working

[Larry Finger]

Marcus Better wrote:
> Marcus Better wrote:
>> Kind-of works. I can connect but only at 1 Mb according to iwconfig.
> 
> Now I see that I got the same result even with driver version 2.0.7. I can
> change it with iwconfig though. Is this normal?

In mac80211, the association and authentication steps are always done at 1 Mb to maximize the
likelihood of that step succeeding. Once communication is established, the rate-setting mechanism in
rc80211_simple will adjust the rate to what it considers the highest value that works. You always
have the option of forcing a higher value with iwconfig at the risk of increasing the error rate.

Larry

Re: rt2500pci 2.0.9 not working

[Marcus Better]

Larry Finger wrote:
> is established, the rate-setting mechanism in rc80211_simple will adjust
> the rate to what it considers the highest value that works.

I get download rates of about 9 Mbit, but iwconfig still says the bit rate
is 1 Mbit, which seems a bit strange.

Marcus

Re: rt2500pci 2.0.9 not working

[Adam Baker]

Marcus Better <marcus@...> writes:

> 
> I get download rates of about 9 Mbit, but iwconfig still says the bit rate
> is 1 Mbit, which seems a bit strange.
> 
The rate reported by iwconfig is the upstream rate. The rates won't necessarily
be the same up and downstream.

Re: rt2500pci 2.0.9 not working

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

On Fri, 2007-10-12 at 11:04 +0200, Marcus Better wrote:

> Oct 12 10:47:23 better kernel: selected mode 2

That's G. What do you get without this patch but with my 'break' patch?

> Oct 12 10:47:23 better kernel: select channel -539241232

That's weird. Humm. What exactly are you printing there and is it really
a pointer 0xdfdbd4f0?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[PATCH v2] mac80211: fix set_channel regression

[Johannes Berg]

Adam Baker reported that the prism2 ioctl removal changed behaviour
in that now the selection order was the other way around as before.
New API is planned but not done yet, so for now just use the first
matching channel in any mode as was previous behaviour with an unset
next_mode.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
Michael Wu just pointed out the error in my previous patch. I missed the
outer loop, we need to break from it as well.

 net/mac80211/ieee80211_ioctl.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- wireless-dev.orig/net/mac80211/ieee80211_ioctl.c	2007-10-10 12:29:49.330680979 +0200
+++ wireless-dev/net/mac80211/ieee80211_ioctl.c	2007-10-12 21:22:20.838530346 +0200
@@ -305,9 +305,12 @@ int ieee80211_set_channel(struct ieee802
 			    ((chan->chan == channel) || (chan->freq == freq))) {
 				local->oper_channel = chan;
 				local->oper_hw_mode = mode;
-				set++;
+				set = 1;
+				break;
 			}
 		}
+		if (set)
+			break;
 	}
 
 	if (set) {

Re: [PATCH v2] mac80211: fix set_channel regression

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Friday 12 October 2007 15:24, Johannes Berg wrote:
> Adam Baker reported that the prism2 ioctl removal changed behaviour
> in that now the selection order was the other way around as before.
> New API is planned but not done yet, so for now just use the first
> matching channel in any mode as was previous behaviour with an unset
> next_mode.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>

Tested and working here.

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH v2] mac80211: fix set_channel regression

[Marcus Better]

Johannes Berg wrote:
> Michael Wu just pointed out the error in my previous patch. I missed the
> outer loop, we need to break from it as well.

The new patch doesn't seem to solve the problem either. I get the same
association failure as before.

Marcus

Re: [PATCH v2] mac80211: fix set_channel regression

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Mon, 2007-10-15 at 09:04 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > Michael Wu just pointed out the error in my previous patch. I missed the
> > outer loop, we need to break from it as well.
> 
> The new patch doesn't seem to solve the problem either. I get the same
> association failure as before.

Can you add back your printk patch and check what type 'channel' was and
maybe print channel->channel?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH v2] mac80211: fix set_channel regression

[Marcus Better]

Johannes Berg wrote:
> On Mon, 2007-10-15 at 09:04 +0200, Marcus Better wrote:
>> The new patch doesn't seem to solve the problem either. I get the same
>> association failure as before.

Update: on my second recompile (after adding the printks) it started
working. I'm not sure why it failed the first time.

However there is a huge performance regression. "tptest" shows a TCP
throughput of under 300 kbit for the driver version 2.0.9 (current
wireless-2.6), compared to 7 Mbit for version 2.0.7 (with kernel
2.6.23-rc3). The UDP speed was also affected but not as much, down from
around 5-10 Mbit to 1 Mbit.

> Can you add back your printk patch and check what type 'channel' was and
> maybe print channel->channel?

With the printks below I get the following:

Oct 15 13:14:43 better kernel: selected mode 2
Oct 15 13:14:43 better kernel: selected channel 8

Thanks,

Marcus

--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -314,6 +314,8 @@ int ieee80211_set_channel(struct ieee80211_local
*local, int
        }

        if (set) {
+               printk(KERN_DEBUG "selected mode %d\n",
local->oper_hw_mode->mod
+               printk(KERN_DEBUG "selected channel %d\n",
local->oper_channel->
                if (local->sta_scanning)
                        ret = 0;
                else

Re: [PATCH v2] mac80211: fix set_channel regression

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Mon, 2007-10-15 at 13:37 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > On Mon, 2007-10-15 at 09:04 +0200, Marcus Better wrote:
> >> The new patch doesn't seem to solve the problem either. I get the same
> >> association failure as before.
> 
> Update: on my second recompile (after adding the printks) it started
> working. I'm not sure why it failed the first time.

Buggy recompile? No idea really.

> However there is a huge performance regression. "tptest" shows a TCP
> throughput of under 300 kbit for the driver version 2.0.9 (current
> wireless-2.6), compared to 7 Mbit for version 2.0.7 (with kernel
> 2.6.23-rc3). The UDP speed was also affected but not as much, down from
> around 5-10 Mbit to 1 Mbit.

I don't think this would be related to mac80211, I'll let Ivo handle the
rest of this.

> > Can you add back your printk patch and check what type 'channel' was and
> > maybe print channel->channel?
> 
> With the printks below I get the following:
> 
> Oct 15 13:14:43 better kernel: selected mode 2
> Oct 15 13:14:43 better kernel: selected channel 8

Looks good, 2 is G mode.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH v2] mac80211: fix set_channel regression

[Ivo van Doorn]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

> > However there is a huge performance regression. "tptest" shows a TCP
> > throughput of under 300 kbit for the driver version 2.0.9 (current
> > wireless-2.6), compared to 7 Mbit for version 2.0.7 (with kernel
> > 2.6.23-rc3). The UDP speed was also affected but not as much, down from
> > around 5-10 Mbit to 1 Mbit.
> 
> I don't think this would be related to mac80211, I'll let Ivo handle the
> rest of this.

Could you enable debugfs and use attached debugfs script to create a dump
of the rt2x00 registers. Preferably a dump of both the rt2x00 2.0.7 and 2.0.9 versions.

Ivo

[-- Attachment #2: debugfsdump --]
[-- Type: application/x-shellscript, Size: 460 bytes --]

Re: [PATCH v2] mac80211: fix set_channel regression

[Marcus Better]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

[CC list trimmed.]

Ivo van Doorn wrote:
> Could you enable debugfs and use attached debugfs script to create a dump
> of the rt2x00 registers. Preferably a dump of both the rt2x00 2.0.7 and
> 2.0.9 versions.

Here's a dump with 2.0.10 from current wireless-2.6 (kernel 2.6.23) to
start with. However I forgot to include your mode setting patch so it
doesn't associate. More to follow later.

Marcus

[-- Attachment #2: debugfsdump.2.0.10 --]
[-- Type: text/plain, Size: 4517 bytes --]

BBP:
0 0x12
1 0xf8
2 0x02
3 0x02
4 0x19
5 0x0b
6 0x10
7 0x00
8 0x00
9 0x00
10 0x00
11 0x04
12 0x00
13 0x70
14 0x1e
15 0x30
16 0xac
17 0x50
18 0x18
19 0xff
20 0x1e
21 0x18
22 0x18
23 0x08
24 0x70
25 0x40
26 0x08
27 0x23
28 0x18
29 0x18
30 0x10
31 0x2b
32 0xb9
33 0x55
34 0x12
35 0x50
36 0x11
37 0x05
38 0x00
39 0xc4
40 0x02
41 0x60
42 0x09
43 0x00
44 0x4e
45 0x00
46 0x5f
47 0x0a
48 0x04
49 0x02
50 0x78
51 0x45
52 0x2e
53 0x10
54 0x18
55 0x7c
56 0x08
57 0x10
58 0x08
59 0x02
60 0x01
61 0x6a
62 0x00
63 0x00
CSR:
0 0x00000004
1 0x00000004
2 0x00000000
3 0x1df00d00
4 0x0000a739
5 0xa76c1400
6 0x00001060
7 0x00000000
8 0x000fff86
9 0x00000980
10 0x37b18000
11 0x070414a5
12 0x3e803e80
13 0x000000a0
14 0x0000000b
15 0x00000000
16 0xf08b2c16
17 0x0000009d
18 0x001e000a
19 0x013a0032
20 0x000005a0
21 0x00000020
22 0x00000000
23 0x00000000
24 0x00000000
25 0x01605b62
26 0x0c010c2c
27 0x37b28000
28 0x379b5000
29 0x37b20000
30 0x379b1000
31 0x00000000
32 0x0000007e
33 0x00000c2c
34 0x37b18000
35 0x000003b8
36 0xb3aab3af
37 0x86870885
38 0x8c8d8b8a
39 0x0000000f
40 0x00000000
41 0x00000000
42 0x0000009c
43 0x00000246
44 0x00000022
45 0x0003ffff
46 0x00000000
47 0x00000000
48 0x00000000
49 0x3f3b3100
50 0x00020002
51 0x00000002
52 0x00020002
53 0x00000002
54 0x000001fe
55 0x1ab83f21
56 0x00213223
57 0x00000518
58 0x9a009a11
59 0x00000000
60 0x00003f00
61 0x14063611
62 0x00031e46
63 0x0000c78f
64 0x37b18084
65 0x37b28000
66 0x37b201e4
67 0x379b5000
68 0x00000020
69 0x00000000
70 0x00000001
71 0x000000aa
72 0x00000001
73 0x00000001
74 0x00000000
75 0x0002974b
76 0x000500f0
77 0x00000040
78 0x000000f0
79 0x00700400
80 0x00380401
81 0x00140402
82 0x000a8403
83 0x7038140a
84 0x1d21252d
85 0x1919191d
86 0x37b28000
87 0x821a8202
88 0x00000003
89 0x00000000
90 0x00000000
91 0x00000000
92 0x76543210
EEPROM:
0 0x2560
1 0xffff
2 0x0d00
3 0x1df0
4 0xa739
5 0x0201
6 0x1814
7 0x0601
8 0x0000
9 0x6146
10 0x18e8
11 0x0000
12 0x0002
13 0x0000
14 0xffff
15 0xffff
16 0x1d6a
17 0xfff0
18 0xffff
19 0x0f30
20 0x1126
21 0x1518
22 0x1618
23 0x3510
24 0x3610
25 0x3d6a
26 0x3e10
27 0x2350
28 0x2960
29 0x3618
30 0x3e00
31 0xffff
32 0xffff
33 0xffff
34 0xffff
35 0x1818
36 0x1818
37 0x1718
38 0x1717
39 0x1717
40 0x1818
41 0x1717
42 0xffff
43 0xffff
44 0xffff
45 0xffff
46 0xffff
47 0xffff
48 0xffff
49 0xffff
50 0xffff
51 0xffff
52 0xffff
53 0xffff
54 0xffff
55 0xffff
56 0xffff
57 0xffff
58 0xffff
59 0xffff
60 0xffff
61 0xffff
62 0xff6d
63 0x0102
64 0x0000
65 0x0000
66 0x0000
67 0x0000
68 0x0000
69 0x0000
70 0x0000
71 0x0000
72 0x0000
73 0x0000
74 0x0000
75 0x0000
76 0x0000
77 0x0000
78 0x0000
79 0x0000
80 0x0000
81 0x0000
82 0x0000
83 0x0000
84 0x0000
85 0x0000
86 0x0000
87 0x0000
88 0x0000
89 0x0000
90 0x0000
91 0x0000
92 0x0000
93 0x0000
94 0x0000
95 0x0000
96 0x0000
97 0x0000
98 0x0000
99 0x0000
100 0x0000
101 0x0000
102 0x0000
103 0x0000
104 0x0000
105 0x0000
106 0x0000
107 0x0000
108 0x0000
109 0x0000
110 0x0000
111 0x0000
112 0x0000
113 0x0000
114 0x0000
115 0x0000
116 0x0000
117 0x0000
118 0x0000
119 0x0000
120 0x0000
121 0x0000
122 0x0000
123 0x0000
124 0x0000
125 0x0000
126 0x0000
127 0x0000
128 0x2560
129 0xffff
130 0x0d00
131 0x1df0
132 0xa739
133 0x0201
134 0x1814
135 0x0601
136 0x0000
137 0x6146
138 0x18e8
139 0x0000
140 0x0002
141 0x0000
142 0xffff
143 0xffff
144 0x1d6a
145 0xffff
146 0xffff
147 0x0f30
148 0x1126
149 0x1518
150 0x1618
151 0x3510
152 0x3610
153 0x3d6a
154 0x3e10
155 0x2350
156 0x2960
157 0x3618
158 0x3e00
159 0xffff
160 0xffff
161 0xffff
162 0xffff
163 0x1818
164 0x1818
165 0x1718
166 0x1717
167 0x1717
168 0x1818
169 0x1717
170 0xffff
171 0xffff
172 0xffff
173 0xffff
174 0xffff
175 0xffff
176 0xffff
177 0xffff
178 0xffff
179 0xffff
180 0xffff
181 0xffff
182 0xffff
183 0xffff
184 0xffff
185 0xffff
186 0xffff
187 0xffff
188 0xffff
189 0xffff
190 0xff6d
191 0x0102
192 0x0000
193 0x0000
194 0x0000
195 0x0000
196 0x0000
197 0x0000
198 0x0000
199 0x0000
200 0x0000
201 0x0000
202 0x0000
203 0x0000
204 0x0000
205 0x0000
206 0x0000
207 0x0000
208 0x0000
209 0x0000
210 0x0000
211 0x0000
212 0x0000
213 0x0000
214 0x0000
215 0x0000
216 0x0000
217 0x0000
218 0x0000
219 0x0000
220 0x0000
221 0x0000
222 0x0000
223 0x0000
224 0x0000
225 0x0000
226 0x0000
227 0x0000
228 0x0000
229 0x0000
230 0x0000
231 0x0000
232 0x0000
233 0x0000
234 0x0000
235 0x0000
236 0x0000
237 0x0000
238 0x0000
239 0x0000
240 0x0000
241 0x0000
242 0x0000
243 0x0000
244 0x0000
245 0x0000
246 0x0000
247 0x0000
248 0x0000
249 0x0000
250 0x0000
251 0x0000
252 0x0000
253 0x0000
254 0x0000
255 0x0000

Re: [PATCH v2] mac80211: fix set_channel regression

[Marcus Better]

Hi,

Ivo van Doorn wrote:
> Could you enable debugfs and use attached debugfs script to create a
> dump of the rt2x00 registers.

If you still need the debug dump for 2.0.7 (the latest working version),
can you show me how to get hold of a source tree with that version? I have
both the wireless-2.6 and rt2x00 git trees, but seem to have trouble
locating the right revision, perhaps because the tree was rebased.

Thanks,

Marcus

Re: [PATCH v2] mac80211: fix set_channel regression

[Ivo van Doorn]

Hi,

> Ivo van Doorn wrote:
> > Could you enable debugfs and use attached debugfs script to create a
> > dump of the rt2x00 registers.
> 
> If you still need the debug dump for 2.0.7 (the latest working version),
> can you show me how to get hold of a source tree with that version? I have
> both the wireless-2.6 and rt2x00 git trees, but seem to have trouble
> locating the right revision, perhaps because the tree was rebased.

I'm afraid that is a bit of a problem, rt2x00 was merged into linus' tree as
a complete patch of version 2.0.8. This means the complete versioning of
2.0.7 has been lost.
The only possible way would be toying with cvs and copying the files
from there. But that is in no what a guarentee for success.

However I can recommend using 2.0.11 the following patches:
http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=8927e4ea2933f5f276a7bb505a6b240156a9238f
http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=32a8da711c3b03a88487dbe48e57c489b5a3031c

Both caused problems with packet throughput. So those might have
resolved the problem you reported.

Ivo

Re: [PATCH v2] mac80211: fix set_channel regression

[Marcus Better]

[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]

Ivo van Doorn wrote:
> However I can recommend using 2.0.11 the following patches:

I tried the full 2.0.11. It still has throughput problems. TCP throughput is 
300 kbit/s (tptest and HTTP download). However UDP throughput is 10 Mbit/s 
according to tptest (and that may be limited by the bandwidth to the test 
server).

Attaching the debugfs dump.

Marcus

[-- Attachment #1.2: debugfsdump.2.0.11 --]
[-- Type: text/plain, Size: 4518 bytes --]

BBP:
0 0x12
1 0xf8
2 0x1a
3 0x02
4 0x19
5 0x09
6 0x00
7 0x0e
8 0x00
9 0x00
10 0x00
11 0x04
12 0x03
13 0x48
14 0x1e
15 0x30
16 0xac
17 0x50
18 0x18
19 0xff
20 0x1e
21 0x18
22 0x18
23 0x08
24 0x70
25 0x40
26 0x08
27 0x23
28 0x18
29 0x18
30 0x10
31 0x2b
32 0xb9
33 0x55
34 0x12
35 0x50
36 0x11
37 0x05
38 0x00
39 0xc4
40 0x02
41 0x60
42 0x0f
43 0x2b
44 0x6c
45 0x41
46 0x14
47 0x0a
48 0x04
49 0x02
50 0xa8
51 0x44
52 0x2e
53 0x10
54 0x18
55 0x7d
56 0x08
57 0x10
58 0x08
59 0x02
60 0x01
61 0x6a
62 0x00
63 0x00
CSR:
0 0x00000004
1 0x00000004
2 0x00000000
3 0x1df00d00
4 0x0000a739
5 0xa76c1400
6 0x00001060
7 0x00000000
8 0x000fff86
9 0x00000980
10 0x37b38000
11 0x070414a5
12 0x3e803e80
13 0x000000a0
14 0x0000000b
15 0x00000000
16 0xd7cd6ecc
17 0x00000115
18 0x001e000a
19 0x013a0032
20 0x000005a0
21 0x00000030
22 0x00000000
23 0x00000000
24 0x00000000
25 0x01605b1a
26 0x0c010c2c
27 0x37b48000
28 0x37b1f000
29 0x37b40000
30 0x37b1e000
31 0x00000000
32 0x0000007e
33 0x00000c2c
34 0x37b38000
35 0x000003b8
36 0xb3aab3af
37 0x86870885
38 0x8c8d8b8a
39 0x0000015f
40 0x0000000a
41 0x00000000
42 0x0000009c
43 0x0000354e
44 0x0000043c
45 0x0003ffff
46 0x00000001
47 0x00000000
48 0x00000000
49 0x3f3b3100
50 0x00020002
51 0x00000002
52 0x00020002
53 0x00000002
54 0x000001fe
55 0x1ab83f21
56 0x00213223
57 0x00000218
58 0x9a009a11
59 0x00000000
60 0x00001150
61 0x14063611
62 0x00031e46
63 0x0000c78f
64 0x37b381e4
65 0x37b48134
66 0x37b40160
67 0x37b1f000
68 0x00000020
69 0x00000009
70 0x00005d80
71 0x000000aa
72 0x00000001
73 0x00000001
74 0x00000000
75 0x0000e472
76 0x000500f0
77 0x00000040
78 0x000000f0
79 0x00700408
80 0x00380409
81 0x0014040a
82 0x000a840b
83 0x7038140a
84 0x1d21252d
85 0x1919191d
86 0x37b48000
87 0x821a8202
88 0x00000003
89 0x00000000
90 0x00000000
91 0x00000000
92 0x76543210
EEPROM:
0 0x2560
1 0xffff
2 0x0d00
3 0x1df0
4 0xa739
5 0x0201
6 0x1814
7 0x0601
8 0x0000
9 0x6146
10 0x18e8
11 0x0000
12 0x0002
13 0x0000
14 0xffff
15 0xffff
16 0x1d6a
17 0xfff0
18 0xffff
19 0x0f30
20 0x1126
21 0x1518
22 0x1618
23 0x3510
24 0x3610
25 0x3d6a
26 0x3e10
27 0x2350
28 0x2960
29 0x3618
30 0x3e00
31 0xffff
32 0xffff
33 0xffff
34 0xffff
35 0x1818
36 0x1818
37 0x1718
38 0x1717
39 0x1717
40 0x1818
41 0x1717
42 0xffff
43 0xffff
44 0xffff
45 0xffff
46 0xffff
47 0xffff
48 0xffff
49 0xffff
50 0xffff
51 0xffff
52 0xffff
53 0xffff
54 0xffff
55 0xffff
56 0xffff
57 0xffff
58 0xffff
59 0xffff
60 0xffff
61 0xffff
62 0xff6d
63 0x0102
64 0x0000
65 0x0000
66 0x0000
67 0x0000
68 0x0000
69 0x0000
70 0x0000
71 0x0000
72 0x0000
73 0x0000
74 0x0000
75 0x0000
76 0x0000
77 0x0000
78 0x0000
79 0x0000
80 0x0000
81 0x0000
82 0x0000
83 0x0000
84 0x0000
85 0x0000
86 0x0000
87 0x0000
88 0x0000
89 0x0000
90 0x0000
91 0x0000
92 0x0000
93 0x0000
94 0x0000
95 0x0000
96 0x0000
97 0x0000
98 0x0000
99 0x0000
100 0x0000
101 0x0000
102 0x0000
103 0x0000
104 0x0000
105 0x0000
106 0x0000
107 0x0000
108 0x0000
109 0x0000
110 0x0000
111 0x0000
112 0x0000
113 0x0000
114 0x0000
115 0x0000
116 0x0000
117 0x0000
118 0x0000
119 0x0000
120 0x0000
121 0x0000
122 0x0000
123 0x0000
124 0x0000
125 0x0000
126 0x0000
127 0x0000
128 0x2560
129 0xffff
130 0x0d00
131 0x1df0
132 0xa739
133 0x0201
134 0x1814
135 0x0601
136 0x0000
137 0x6146
138 0x18e8
139 0x0000
140 0x0002
141 0x0000
142 0xffff
143 0xffff
144 0x1d6a
145 0xffff
146 0xffff
147 0x0f30
148 0x1126
149 0x1518
150 0x1618
151 0x3510
152 0x3610
153 0x3d6a
154 0x3e10
155 0x2350
156 0x2960
157 0x3618
158 0x3e00
159 0xffff
160 0xffff
161 0xffff
162 0xffff
163 0x1818
164 0x1818
165 0x1718
166 0x1717
167 0x1717
168 0x1818
169 0x1717
170 0xffff
171 0xffff
172 0xffff
173 0xffff
174 0xffff
175 0xffff
176 0xffff
177 0xffff
178 0xffff
179 0xffff
180 0xffff
181 0xffff
182 0xffff
183 0xffff
184 0xffff
185 0xffff
186 0xffff
187 0xffff
188 0xffff
189 0xffff
190 0xff6d
191 0x0102
192 0x0000
193 0x0000
194 0x0000
195 0x0000
196 0x0000
197 0x0000
198 0x0000
199 0x0000
200 0x0000
201 0x0000
202 0x0000
203 0x0000
204 0x0000
205 0x0000
206 0x0000
207 0x0000
208 0x0000
209 0x0000
210 0x0000
211 0x0000
212 0x0000
213 0x0000
214 0x0000
215 0x0000
216 0x0000
217 0x0000
218 0x0000
219 0x0000
220 0x0000
221 0x0000
222 0x0000
223 0x0000
224 0x0000
225 0x0000
226 0x0000
227 0x0000
228 0x0000
229 0x0000
230 0x0000
231 0x0000
232 0x0000
233 0x0000
234 0x0000
235 0x0000
236 0x0000
237 0x0000
238 0x0000
239 0x0000
240 0x0000
241 0x0000
242 0x0000
243 0x0000
244 0x0000
245 0x0000
246 0x0000
247 0x0000
248 0x0000
249 0x0000
250 0x0000
251 0x0000
252 0x0000
253 0x0000
254 0x0000
255 0x0000

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[PATCH] mac80211: reorder association debug output

[Johannes Berg]

There's no reason to warn about an invalid AID field when the
association was denied.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
Odd messages in your log btw:

> Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
> Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
> Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
> Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
> Oct 10 10:26:27 better kernel: wlan0: association with AP 00:14:6c:a7:60:10 timed out

We never use the AID value in this case...

 net/mac80211/ieee80211_sta.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

--- wireless-dev.orig/net/mac80211/ieee80211_sta.c	2007-10-10 11:57:36.290680979 +0200
+++ wireless-dev/net/mac80211/ieee80211_sta.c	2007-10-10 12:00:31.490680979 +0200
@@ -1195,15 +1195,11 @@ static void ieee80211_rx_mgmt_assoc_resp
 	capab_info = le16_to_cpu(mgmt->u.assoc_resp.capab_info);
 	status_code = le16_to_cpu(mgmt->u.assoc_resp.status_code);
 	aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
-	if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
-		printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
-		       "set\n", dev->name, aid);
-	aid &= ~(BIT(15) | BIT(14));
 
 	printk(KERN_DEBUG "%s: RX %sssocResp from " MAC_FMT " (capab=0x%x "
 	       "status=%d aid=%d)\n",
 	       dev->name, reassoc ? "Rea" : "A", MAC_ARG(mgmt->sa),
-	       capab_info, status_code, aid);
+	       capab_info, status_code, aid & ~(BIT(15) | BIT(14)));
 
 	if (status_code != WLAN_STATUS_SUCCESS) {
 		printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
@@ -1215,6 +1211,11 @@ static void ieee80211_rx_mgmt_assoc_resp
 		return;
 	}
 
+	if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
+		printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
+		       "set\n", dev->name, aid);
+	aid &= ~(BIT(15) | BIT(14));
+
 	pos = mgmt->u.assoc_resp.variable;
 	if (ieee802_11_parse_elems(pos, len - (pos - (u8 *) mgmt), &elems)
 	    == ParseFailed) {

Re: [PATCH] mac80211: reorder association debug output

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 278 bytes --]

On Wednesday 10 October 2007 06:03, Johannes Berg wrote:
> There's no reason to warn about an invalid AID field when the
> association was denied.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
Acked-by: Michael Wu <flamingice@sourmilk.net>

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[PATCH] Add get_unaligned to ieee80211_get_radiotap_len

[John W. Linville]

From: warmcat <andy@warmcat.com>

ieee80211_get_radiotap_len() tries to dereference radiotap length without
taking care that it is completely unaligned and get_unaligned()
is required.

Signed-off-by: Andy Green <andy@warmcat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 net/mac80211/ieee80211.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index ff2172f..9b9d716 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -350,7 +350,7 @@ static int ieee80211_get_radiotap_len(struct sk_buff *skb)
 	struct ieee80211_radiotap_header *hdr =
 		(struct ieee80211_radiotap_header *) skb->data;
 
-	return le16_to_cpu(hdr->it_len);
+	return le16_to_cpu(get_unaligned(&hdr->it_len));
 }
 
 #ifdef CONFIG_MAC80211_LOWTX_FRAME_DUMP
-- 
1.5.2.4

[PATCH] Improve sanity checks on injected packets

[John W. Linville]

From: warmcat <andy@warmcat.com>

Michael Wu noticed that the skb length checking is not taken care of enough when
a packet is presented on the Monitor interface for injection.

This patch improves the sanity checking and removes fake offsets placed
into the skb network and transport header.

Signed-off-by: Andy Green <andy@warmcat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 net/mac80211/ieee80211.c |   48 ++++++++++++++++++++++++++-------------------
 1 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 9b9d716..ad73a40 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -1680,46 +1680,54 @@ int ieee80211_monitor_start_xmit(struct sk_buff *skb,
 	struct ieee80211_tx_packet_data *pkt_data;
 	struct ieee80211_radiotap_header *prthdr =
 		(struct ieee80211_radiotap_header *)skb->data;
-	u16 len;
+	u16 len_rthdr;
 
-	/*
-	 * there must be a radiotap header at the
-	 * start in this case
-	 */
-	if (unlikely(prthdr->it_version)) {
-		/* only version 0 is supported */
-		dev_kfree_skb(skb);
-		return NETDEV_TX_OK;
-	}
+	/* check for not even having the fixed radiotap header part */
+	if (unlikely(skb->len < sizeof(struct ieee80211_radiotap_header)))
+		goto fail; /* too short to be possibly valid */
+
+	/* is it a header version we can trust to find length from? */
+	if (unlikely(prthdr->it_version))
+		goto fail; /* only version 0 is supported */
+
+	/* then there must be a radiotap header with a length we can use */
+	len_rthdr = ieee80211_get_radiotap_len(skb);
+
+	/* does the skb contain enough to deliver on the alleged length? */
+	if (unlikely(skb->len < len_rthdr))
+		goto fail; /* skb too short for claimed rt header extent */
 
 	skb->dev = local->mdev;
 
 	pkt_data = (struct ieee80211_tx_packet_data *)skb->cb;
 	memset(pkt_data, 0, sizeof(*pkt_data));
+	/* needed because we set skb device to master */
 	pkt_data->ifindex = dev->ifindex;
+
 	pkt_data->mgmt_iface = 0;
 	pkt_data->do_not_encrypt = 1;
 
-	/* above needed because we set skb device to master */
-
 	/*
 	 * fix up the pointers accounting for the radiotap
 	 * header still being in there.  We are being given
 	 * a precooked IEEE80211 header so no need for
 	 * normal processing
 	 */
-	len = le16_to_cpu(get_unaligned(&prthdr->it_len));
-	skb_set_mac_header(skb, len);
-	skb_set_network_header(skb, len + sizeof(struct ieee80211_hdr));
-	skb_set_transport_header(skb, len + sizeof(struct ieee80211_hdr));
-
+	skb_set_mac_header(skb, len_rthdr);
 	/*
-	 * pass the radiotap header up to
-	 * the next stage intact
+	 * these are just fixed to the end of the rt area since we
+	 * don't have any better information and at this point, nobody cares
 	 */
-	dev_queue_xmit(skb);
+	skb_set_network_header(skb, len_rthdr);
+	skb_set_transport_header(skb, len_rthdr);
 
+	/* pass the radiotap header up to the next stage intact */
+	dev_queue_xmit(skb);
 	return NETDEV_TX_OK;
+
+fail:
+	dev_kfree_skb(skb);
+	return NETDEV_TX_OK; /* meaning, we dealt with the skb */
 }
 
 
-- 
1.5.2.4

[PATCH] mac80211: filter locally-originated multicast frames

[John W. Linville]

From: John W. Linville <linville@tuxdriver.com>

In STA mode, the AP will echo our traffic.  This includes multicast
traffic.

Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 net/mac80211/ieee80211.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index ad73a40..9e0da6e 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -2844,9 +2844,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
 		memcpy(dst, hdr->addr1, ETH_ALEN);
 		memcpy(src, hdr->addr3, ETH_ALEN);
 
-		if (sdata->type != IEEE80211_IF_TYPE_STA) {
+		if (sdata->type != IEEE80211_IF_TYPE_STA ||
+		    (is_multicast_ether_addr(dst) &&
+		     !compare_ether_addr(src, dev->dev_addr)))
 			return TXRX_DROP;
-		}
 		break;
 	case 0:
 		/* DA SA BSSID */
-- 
1.5.2.4

[PATCH] libertas: fix endianness breakage

[John W. Linville]

From: Al Viro <viro@ftp.linux.org.uk>

	wep->keytype[] is u8

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 drivers/net/wireless/libertas/cmd.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index 4a8f5dc..86fff8d 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -185,14 +185,12 @@ static int wlan_cmd_802_11_set_wep(wlan_private * priv,
 
 			switch (pkey->len) {
 			case KEY_LEN_WEP_40:
-				wep->keytype[i] =
-					cpu_to_le16(cmd_type_wep_40_bit);
+				wep->keytype[i] = cmd_type_wep_40_bit;
 				memmove(&wep->keymaterial[i], pkey->key,
 				        pkey->len);
 				break;
 			case KEY_LEN_WEP_104:
-				wep->keytype[i] =
-					cpu_to_le16(cmd_type_wep_104_bit);
+				wep->keytype[i] = cmd_type_wep_104_bit;
 				memmove(&wep->keymaterial[i], pkey->key,
 				        pkey->len);
 				break;
-- 
1.5.2.4

[PATCH] libertas: more endianness breakage

[John W. Linville]

From: Al Viro <viro@ftp.linux.org.uk>

	domain->header.len is le16 and has just been assigned
cpu_to_le16(arithmetical expression).  And all fields of adapter->logmsg
are __le32; not a single 16-bit among them...
	That's incremental to the previous one

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 drivers/net/wireless/libertas/11d.c  |    2 +-
 drivers/net/wireless/libertas/wext.c |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/libertas/11d.c b/drivers/net/wireless/libertas/11d.c
index 4cf0ff7..0560270 100644
--- a/drivers/net/wireless/libertas/11d.c
+++ b/drivers/net/wireless/libertas/11d.c
@@ -562,7 +562,7 @@ int libertas_cmd_802_11d_domain_info(wlan_private * priv,
 		       nr_subband * sizeof(struct ieeetypes_subbandset));
 
 		cmd->size = cpu_to_le16(sizeof(pdomaininfo->action) +
-					     domain->header.len +
+					     le16_to_cpu(domain->header.len) +
 					     sizeof(struct mrvlietypesheader) +
 					     S_DS_GEN);
 	} else {
diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
index 2fcc3bf..873c405 100644
--- a/drivers/net/wireless/libertas/wext.c
+++ b/drivers/net/wireless/libertas/wext.c
@@ -973,7 +973,7 @@ static struct iw_statistics *wlan_get_wireless_stats(struct net_device *dev)
 	/* Quality by TX errors */
 	priv->wstats.discard.retries = priv->stats.tx_errors;
 
-	tx_retries = le16_to_cpu(adapter->logmsg.retry);
+	tx_retries = le32_to_cpu(adapter->logmsg.retry);
 
 	if (tx_retries > 75)
 		tx_qual = (90 - tx_retries) * POOR / 15;
@@ -989,10 +989,10 @@ static struct iw_statistics *wlan_get_wireless_stats(struct net_device *dev)
 		    (PERFECT - VERY_GOOD) / 50 + VERY_GOOD;
 	quality = min(quality, tx_qual);
 
-	priv->wstats.discard.code = le16_to_cpu(adapter->logmsg.wepundecryptable);
-	priv->wstats.discard.fragment = le16_to_cpu(adapter->logmsg.rxfrag);
+	priv->wstats.discard.code = le32_to_cpu(adapter->logmsg.wepundecryptable);
+	priv->wstats.discard.fragment = le32_to_cpu(adapter->logmsg.rxfrag);
 	priv->wstats.discard.retries = tx_retries;
-	priv->wstats.discard.misc = le16_to_cpu(adapter->logmsg.ackfailure);
+	priv->wstats.discard.misc = le32_to_cpu(adapter->logmsg.ackfailure);
 
 	/* Calculate quality */
 	priv->wstats.qual.qual = max(quality, (u32)100);
-- 
1.5.2.4

[PATCH] ieee80211: fix TKIP QoS bug

[John W. Linville]

From: Johannes Berg <johannes@sipsolutions.net>

The commit 65b6a277 titled "ieee80211: Fix header->qos_ctl endian issue"
*introduced* an endianness bug. Partially revert it.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 net/ieee80211/ieee80211_crypt_tkip.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ieee80211/ieee80211_crypt_tkip.c b/net/ieee80211/ieee80211_crypt_tkip.c
index 5a48d8e..7f11dd9 100644
--- a/net/ieee80211/ieee80211_crypt_tkip.c
+++ b/net/ieee80211/ieee80211_crypt_tkip.c
@@ -584,7 +584,7 @@ static void michael_mic_hdr(struct sk_buff *skb, u8 * hdr)
 	if (stype & IEEE80211_STYPE_QOS_DATA) {
 		const struct ieee80211_hdr_3addrqos *qoshdr =
 			(struct ieee80211_hdr_3addrqos *)skb->data;
-		hdr[12] = qoshdr->qos_ctl & cpu_to_le16(IEEE80211_QCTL_TID);
+		hdr[12] = le16_to_cpu(qoshdr->qos_ctl) & IEEE80211_QCTL_TID;
 	} else
 		hdr[12] = 0;		/* priority */
 
-- 
1.5.2.4

[PATCH] mac80211: reorder association debug output

[John W. Linville]

From: Johannes Berg <johannes@sipsolutions.net>

There's no reason to warn about an invalid AID field when the
association was denied.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
 net/mac80211/ieee80211_sta.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 0d99b68..ae74c79 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -1174,15 +1174,11 @@ static void ieee80211_rx_mgmt_assoc_resp(struct net_device *dev,
 	capab_info = le16_to_cpu(mgmt->u.assoc_resp.capab_info);
 	status_code = le16_to_cpu(mgmt->u.assoc_resp.status_code);
 	aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
-	if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
-		printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
-		       "set\n", dev->name, aid);
-	aid &= ~(BIT(15) | BIT(14));
 
 	printk(KERN_DEBUG "%s: RX %sssocResp from " MAC_FMT " (capab=0x%x "
 	       "status=%d aid=%d)\n",
 	       dev->name, reassoc ? "Rea" : "A", MAC_ARG(mgmt->sa),
-	       capab_info, status_code, aid);
+	       capab_info, status_code, aid & ~(BIT(15) | BIT(14)));
 
 	if (status_code != WLAN_STATUS_SUCCESS) {
 		printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
@@ -1192,6 +1188,11 @@ static void ieee80211_rx_mgmt_assoc_resp(struct net_device *dev,
 		return;
 	}
 
+	if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
+		printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
+		       "set\n", dev->name, aid);
+	aid &= ~(BIT(15) | BIT(14));
+
 	pos = mgmt->u.assoc_resp.variable;
 	if (ieee802_11_parse_elems(pos, len - (pos - (u8 *) mgmt), &elems)
 	    == ParseFailed) {
-- 
1.5.2.4

Re: [PATCH] mac80211: reorder association debug output

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]


On Fri, 2007-10-26 at 17:04 -0400, John W. Linville wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> 
> There's no reason to warn about an invalid AID field when the
> association was denied.

I don't really see a reason to have this in stable, do we really want
that? And if so, we should roll in the fix for the warning :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] mac80211: reorder association debug output

[John W. Linville]

On Fri, Oct 26, 2007 at 11:10:39PM +0200, Johannes Berg wrote:
> 
> On Fri, 2007-10-26 at 17:04 -0400, John W. Linville wrote:
> > From: Johannes Berg <johannes@sipsolutions.net>
> > 
> > There's no reason to warn about an invalid AID field when the
> > association was denied.
> 
> I don't really see a reason to have this in stable, do we really want

Perhaps not.  I'm still not totally clear on the "stable" criteria
(probably my own fault).

Anyway, this probably got caught-up in a "what recent fixes still
apply to 2.6.23" sweep.  Still, I don't see why this wouldn't be
desirable for someone running 2.6.23?

> that? And if so, we should roll in the fix for the warning :)

I was trying to "clear the baffles" before rolling-out the more
recent fixes.  If this patch isn't rejected for stable then it might
be worth waiting for the warning fix patch pushed yesterday.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH] mac80211: reorder association debug output

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]


> Anyway, this probably got caught-up in a "what recent fixes still
> apply to 2.6.23" sweep.  Still, I don't see why this wouldn't be
> desirable for someone running 2.6.23?

No drivers in 2.6.23 anyway and Intel ships their own mac80211. Why
should we care at all?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] mac80211: reorder association debug output

[John W. Linville]

On Fri, Oct 26, 2007 at 11:44:38PM +0200, Johannes Berg wrote:
> 
> > Anyway, this probably got caught-up in a "what recent fixes still
> > apply to 2.6.23" sweep.  Still, I don't see why this wouldn't be
> > desirable for someone running 2.6.23?
> 
> No drivers in 2.6.23 anyway and Intel ships their own mac80211. Why
> should we care at all?

rtl8187 is in 2.6.23.

-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH] mac80211: reorder association debug output

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]



> > No drivers in 2.6.23 anyway and Intel ships their own mac80211. Why
> > should we care at all?
> 
> rtl8187 is in 2.6.23.

Oops, I stand corrected. Still I don't think that the message patch is
worth doing in stable, although the regression potential is pretty much
nil.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] mac80211: reorder association debug output

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Saturday 27 October 2007 08:58:55 Johannes Berg wrote:
> Oops, I stand corrected. Still I don't think that the message patch is
> worth doing in stable, although the regression potential is pretty much
> nil.
>
According to the stable kernel rules, this fix doesn't look appropriate. 
(though it is practically zero risk) Also, the sta_bss_list changes do not 
qualify due to "It cannot be bigger than 100 lines, with context". The 
radiotap get_unaligned patch doesn't qualify - it's not important enough. The 
IE parsing fix is also too big. I'm not certain that the SSID scanning patch 
qualifies either.. from the patch's POV, it's adding a feature. So, the way 
I'm reading things, no mac80211 patches seem to qualify according to stable 
kernel rules.

FWIW, I think 
[PATCH] mac80211: reorder association debug output
[PATCH] mac80211: honor IW_SCAN_THIS_ESSID in siwscan ioctl (plus fix)
[PATCH] mac80211: make ieee802_11_parse_elems return void
do enough good that they should be pushed to stable. The IE parsing fix is a 
little big but it's trivial, reordering the debug output is safe and reduces 
confusion, and the SSID scanning patch makes it easier to connect to hidden 
APs. In addition, the SSID len match patch should also be pushed to stable 
since I think it's a one line, fairly obvious patch that fixes a problem in 
auto AP selection that can prevent association.

-Michael Wu

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]