[PATCH RFC] rt2500usb: disable broken HW encryption by default

[PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

Since HW encryption was added to rt2500usb in 2.6.29, the driver does not
work. It has been discussed before but never solved:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
https://bugzilla.redhat.com/show_bug.cgi?id=484888

The problem is caused by this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dddfb478b26e29a2b47f655ec219e743b8111015

Disable HW encryption by default to fix it.


--- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-20 02:17:57.000000000 +0100
+++ linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-22 15:40:39.000000000 +0100
@@ -36,11 +36,11 @@
 #include "rt2500usb.h"
 
 /*
- * Allow hardware encryption to be disabled.
+ * Allow hardware encryption to be enabled.
  */
-static int modparam_nohwcrypt = 0;
-module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
-MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
+static int modparam_hwcrypt = 0;
+module_param_named(hwcrypt, modparam_hwcrypt, bool, S_IRUGO);
+MODULE_PARM_DESC(hwcrypt, "Enable hardware encryption.");
 
 /*
  * Register access.
@@ -1732,7 +1732,7 @@
 	 */
 	__set_bit(DRIVER_REQUIRE_ATIM_QUEUE, &rt2x00dev->flags);
 	__set_bit(DRIVER_REQUIRE_BEACON_GUARD, &rt2x00dev->flags);
-	if (!modparam_nohwcrypt) {
+	if (modparam_hwcrypt) {
 		__set_bit(CONFIG_SUPPORT_HW_CRYPTO, &rt2x00dev->flags);
 		__set_bit(DRIVER_REQUIRE_COPY_IV, &rt2x00dev->flags);
 	}

-- 
Ondrej Zary

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ivo Van Doorn]

On Mon, Mar 22, 2010 at 4:01 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> Since HW encryption was added to rt2500usb in 2.6.29, the driver does not
> work. It has been discussed before but never solved:
> http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
> https://bugzilla.redhat.com/show_bug.cgi?id=484888
>
> The problem is caused by this patch:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dddfb478b26e29a2b47f655ec219e743b8111015
>
> Disable HW encryption by default to fix it.
>
>
> --- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c       2010-03-20 02:17:57.000000000 +0100
> +++ linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c    2010-03-22 15:40:39.000000000 +0100
> @@ -36,11 +36,11 @@
>  #include "rt2500usb.h"
>
>  /*
> - * Allow hardware encryption to be disabled.
> + * Allow hardware encryption to be enabled.
>  */
> -static int modparam_nohwcrypt = 0;
> -module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
> -MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
> +static int modparam_hwcrypt = 0;
> +module_param_named(hwcrypt, modparam_hwcrypt, bool, S_IRUGO);
> +MODULE_PARM_DESC(hwcrypt, "Enable hardware encryption.");

Large patch for something which can be done much simpler. How about:

static int modparam_nohwcrypt = 1

That way the module parameter does not have to be renamed, so current
configurations and documentation do not have to be changed. The name
remains consistent with the other rt2x00 modules (and the other
mac80211 modules for that matter).

But I though it was mentioned that disabling HW crypto didn't solve
the issue due to a second bug in a later kernel?

Ivo

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

On Monday 22 March 2010, Ivo Van Doorn wrote:
> On Mon, Mar 22, 2010 at 4:01 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> > Since HW encryption was added to rt2500usb in 2.6.29, the driver does not
> > work. It has been discussed before but never solved:
> > http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
> > https://bugzilla.redhat.com/show_bug.cgi?id=484888
> >
> > The problem is caused by this patch:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
> >;h=dddfb478b26e29a2b47f655ec219e743b8111015
> >
> > Disable HW encryption by default to fix it.
> >
> >
> > --- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c      
> > 2010-03-20 02:17:57.000000000 +0100 +++
> > linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c    2010-03-22
> > 15:40:39.000000000 +0100 @@ -36,11 +36,11 @@
> >  #include "rt2500usb.h"
> >
> >  /*
> > - * Allow hardware encryption to be disabled.
> > + * Allow hardware encryption to be enabled.
> >  */
> > -static int modparam_nohwcrypt = 0;
> > -module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
> > -MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
> > +static int modparam_hwcrypt = 0;
> > +module_param_named(hwcrypt, modparam_hwcrypt, bool, S_IRUGO);
> > +MODULE_PARM_DESC(hwcrypt, "Enable hardware encryption.");
>
> Large patch for something which can be done much simpler. How about:
>
> static int modparam_nohwcrypt = 1
>
> That way the module parameter does not have to be renamed, so current
> configurations and documentation do not have to be changed. The name
> remains consistent with the other rt2x00 modules (and the other
> mac80211 modules for that matter).

OK, that seems better.

> But I though it was mentioned that disabling HW crypto didn't solve
> the issue due to a second bug in a later kernel?

That was a false positive. Probably because the device was not unplugged
between the tests (and looks like the driver does not initialize the chip completely).
It's not reliable, it sometimes stops working after reboot.



Since HW encryption was added to rt2500usb in 2.6.29, the driver does not
work. It has been discussed before but never solved:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
https://bugzilla.redhat.com/show_bug.cgi?id=484888

The problem is caused by this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dddfb478b26e29a2b47f655ec219e743b8111015

Disable HW encryption by default to fix it.

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>

--- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-20 02:17:57.000000000 +0100
+++ linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-22 16:16:55.000000000 +0100
@@ -36,11 +36,11 @@
 #include "rt2500usb.h"
 
 /*
- * Allow hardware encryption to be disabled.
+ * Allow hardware encryption to be enabled.
  */
-static int modparam_nohwcrypt = 0;
+static int modparam_nohwcrypt = 1;
 module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
-MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
+MODULE_PARM_DESC(nohwcrypt, "Hardware encryption disabled by default, use nohwcrypt=0 to enable.");
 
 /*
  * Register access.

-- 
Ondrej Zary

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ivo Van Doorn]

>> But I though it was mentioned that disabling HW crypto didn't solve
>> the issue due to a second bug in a later kernel?
>
> That was a false positive. Probably because the device was not unplugged
> between the tests (and looks like the driver does not initialize the chip completely).
> It's not reliable, it sometimes stops working after reboot.

Ah well that at least simplifies the problem. I'll have to retest rt2500usb soon
to see why the HW crypto failed. I am sure I had it working for WEP,
WPA and WPA2
before I submitted the patch.

> Since HW encryption was added to rt2500usb in 2.6.29, the driver does not
> work. It has been discussed before but never solved:
> http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
> https://bugzilla.redhat.com/show_bug.cgi?id=484888
>
> The problem is caused by this patch:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dddfb478b26e29a2b47f655ec219e743b8111015
>
> Disable HW encryption by default to fix it.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>
> --- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c       2010-03-20 02:17:57.000000000 +0100
> +++ linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c    2010-03-22 16:16:55.000000000 +0100
> @@ -36,11 +36,11 @@
>  #include "rt2500usb.h"
>
>  /*
> - * Allow hardware encryption to be disabled.
> + * Allow hardware encryption to be enabled.
>  */
> -static int modparam_nohwcrypt = 0;
> +static int modparam_nohwcrypt = 1;
>  module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
> -MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
> +MODULE_PARM_DESC(nohwcrypt, "Hardware encryption disabled by default, use nohwcrypt=0 to enable.");

Actually could you just change the default value and nothing else?
The meaning of the module parameter doesn't change. So the Module
parameter description doesn't need to be updated as far as I am
concerned

Thanks,

Ivo

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

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

On Monday 22 March 2010, Ivo Van Doorn wrote:
> >> But I though it was mentioned that disabling HW crypto didn't solve
> >> the issue due to a second bug in a later kernel?
> >
> > That was a false positive. Probably because the device was not unplugged
> > between the tests (and looks like the driver does not initialize the chip
> > completely). It's not reliable, it sometimes stops working after reboot.
>
> Ah well that at least simplifies the problem. I'll have to retest rt2500usb
> soon to see why the HW crypto failed. I am sure I had it working for WEP,
> WPA and WPA2
> before I submitted the patch.

So let's try to fix it instead of disabling.

First, the unrealiability (keeping HW encryption disabled). With the driver 
loaded but not doing anything more, the register dumps are same for both 
working and non-working case (dump-init.txt).

dump-good-connected.txt is a dump after successful association and DHCP
dump-bad-attempt.txt is a dump after successful association during non-working 
DHCP attempt
dump-bad-after.txt is a dump after DHCP timed out

Here are the differences:

--- dump-good-connected.txt	2010-03-23 10:21:02.000000000 +0100
+++ dump-bad-attempt.txt	2010-03-23 10:21:39.000000000 +0100
@@ -19,19 +19,19 @@
 2 :0x00001700
 3 :0x0000eb31
 4 :0x000031a5
-5 :0x00001a00
-6 :0x0000d992
-7 :0x00006e24
+5 :0x00000000
+6 :0x00000000
+7 :0x00000000
 8 :0x00000980
 9 :0x0000ff1d
-10 :0x00000009
+10 :0x00000014
 11 :0x0000000a
-12 :0x00000156
+12 :0x0000016c
 13 :0x00001111
 14 :0x00001e11
 15 :0x000001ee
 16 :0x00000000
-17 :0x000000aa
+17 :0x000000be
 18 :0x00008450
 19 :0x0000ff00
 20 :0x00000003
@@ -56,7 +56,7 @@
 39 :0x00008687
 40 :0x00000085
 41 :0x00000162
-42 :0x0000000e
+42 :0x0000000a
 43 :0x0000000f
 44 :0x0000140a
 45 :0x00007038
@@ -117,26 +117,26 @@
 100 :0x0000000f
 101 :0x00008204
 102 :0x0000821c
-103 :0x0000112a
+103 :0x00001126
 104 :0x00000000
-105 :0x00000e1b
+105 :0x00000e07
 106 :0x00005400
 107 :0x00000000
 108 :0x00000000
 109 :0x00000000
 110 :0x00000000
 111 :0x00000000
-112 :0x000004c0
-113 :0x0000883b
-114 :0x0000006f
-115 :0x00002c75
+112 :0x00000000
+113 :0x00000dd0
+114 :0x00000048
+115 :0x00000000
 116 :0x00000000
 117 :0x00000000
-118 :0x00000015
+118 :0x00000010
 119 :0x00000000
-120 :0x00000003
-121 :0x00000000
-122 :0x0000005d
+120 :0x00000000
+121 :0x00000001
+122 :0x00000000
 123 :0x00000000
 124 :0x00000000
 125 :0x00000000
@@ -200,13 +200,13 @@
 
 bbp
 0 :0x13
-1 :0xa2
+1 :0xab
 2 :0x04
 3 :0x02
 4 :0x19
 5 :0x0b
-6 :0x00
-7 :0x0e
+6 :0x10
+7 :0x00
 8 :0x00
 9 :0x00
 10 :0x00
@@ -227,7 +227,7 @@
 25 :0x50
 26 :0x08
 27 :0x23
-28 :0x22
+28 :0x18
 29 :0x00
 30 :0x10
 31 :0x2b
@@ -241,25 +241,25 @@
 39 :0xc4
 40 :0x02
 41 :0x60
-42 :0x09
-43 :0x33
-44 :0x22
-45 :0x2b
-46 :0xb4
+42 :0x0b
+43 :0x6f
+44 :0x29
+45 :0x36
+46 :0xa3
 47 :0x0a
 48 :0x04
-49 :0x04
-50 :0x90
+49 :0x00
+50 :0x70
 51 :0x26
-52 :0x04
+52 :0x02
 53 :0x10
 54 :0x18
-55 :0x17
+55 :0x2e
 56 :0x08
 57 :0x10
 58 :0x08
 59 :0x3e
-60 :0x03
+60 :0x02
 61 :0x66
 62 :0x00
 63 :0x00
@@ -286,7 +286,7 @@
 84 :0xc0
 85 :0x10
 86 :0xcf
-87 :0x05
+87 :0x00
 88 :0x00
 89 :0x00
 90 :0x00


-- 
Ondrej Zary

[-- Attachment #2: dump-init.txt --]
[-- Type: text/plain, Size: 3672 bytes --]

kernel: 2.6.34-rc2
driver:	rt2500usb
version:	2.3.0
compiled:	Mar 22 2010 14:59:58
dev_flags: 0x001000c3
rt chip:	2570
rf chip:	0005
revision:	0005

register	base	words	wordsize
csr	1024	128	2
eeprom	0	53	2
bbp	0	96	1
rf	4	4	4

csr
0 :0x00000005
1 :0x00000002
2 :0x00000000
3 :0x00000000
4 :0x00000000
5 :0x00000000
6 :0x00000000
7 :0x00000000
8 :0x00000880
9 :0x00003f1d
10 :0x00000014
11 :0x0000000a
12 :0x0000016c
13 :0x00002121
14 :0x00001e1e
15 :0x000001aa
16 :0x00000a11
17 :0x000001e0
18 :0x0000005a
19 :0x0000ff00
20 :0x00000000
21 :0x00001e46
22 :0x000000a3
23 :0x00000000
24 :0x00000000
25 :0x00000000
26 :0x00000000
27 :0x00000000
28 :0x00000000
29 :0x00000000
30 :0x00000000
31 :0x00000000
32 :0x000000c0
33 :0x0000b162
34 :0x0000007f
35 :0x0000b3af
36 :0x0000b3aa
37 :0x00008c8d
38 :0x00008b8a
39 :0x00008687
40 :0x00000085
41 :0x00000162
42 :0x0000000a
43 :0x00000000
44 :0x0000140a
45 :0x00007038
46 :0x00000c13
47 :0x00000609
48 :0x00000305
49 :0x00000203
50 :0x00000640
51 :0x00000000
52 :0x00000000
53 :0x0000c78f
54 :0x00000000
55 :0x00000000
56 :0x00000000
57 :0x00000000
58 :0x00000000
59 :0x00000000
60 :0x00000000
61 :0x00000000
62 :0x00000000
63 :0x00000000
64 :0x00000000
65 :0x00000000
66 :0x00000000
67 :0x00000000
68 :0x00000000
69 :0x00000000
70 :0x00000000
71 :0x00000000
72 :0x00000000
73 :0x00000000
74 :0x00000000
75 :0x00000000
76 :0x00000000
77 :0x00000000
78 :0x00000000
79 :0x00000000
80 :0x00000000
81 :0x00000000
82 :0x00000000
83 :0x00000000
84 :0x00000000
85 :0x00000000
86 :0x00000000
87 :0x00000000
88 :0x00000000
89 :0x00000000
90 :0x00000000
91 :0x00000000
92 :0x00000000
93 :0x00000000
94 :0x00000000
95 :0x00000000
96 :0x00001221
97 :0x00000003
98 :0x00000002
99 :0x00000000
100 :0x0000000e
101 :0x00008200
102 :0x00008218
103 :0x00009100
104 :0x00000000
105 :0x00000000
106 :0x00005600
107 :0x00000000
108 :0x00000000
109 :0x00000000
110 :0x00000000
111 :0x00000000
112 :0x00000000
113 :0x00000000
114 :0x00000000
115 :0x00000000
116 :0x00000000
117 :0x00000000
118 :0x00000000
119 :0x00000000
120 :0x00000000
121 :0x00000000
122 :0x00000000
123 :0x00000000
124 :0x00000000
125 :0x00000000
126 :0x00000000
127 :0x00000000

eeprom
0 :0x2570
1 :0x0104
2 :0x1700
3 :0xeb31
4 :0x31a5
5 :0xffff
6 :0xffff
7 :0xffff
8 :0xffff
9 :0xffff
10 :0xffff
11 :0x2815
12 :0xfff0
13 :0x02ff
14 :0x1133
15 :0x1518
16 :0x1618
17 :0x3e00
18 :0xffff
19 :0xffff
20 :0xffff
21 :0xffff
22 :0xffff
23 :0xffff
24 :0xffff
25 :0xffff
26 :0xffff
27 :0xffff
28 :0xffff
29 :0xffff
30 :0x1616
31 :0x1716
32 :0x1717
33 :0x1717
34 :0x1818
35 :0x1918
36 :0x1a19
37 :0xffff
38 :0xffff
39 :0xffff
40 :0xffff
41 :0xffff
42 :0xffff
43 :0xffff
44 :0xffff
45 :0xffff
46 :0xffff
47 :0xffff
48 :0x0032
49 :0x6880
50 :0x3850
51 :0x7666
52 :0xfa3e

bbp
0 :0x00
1 :0x00
2 :0x00
3 :0x00
4 :0x00
5 :0x00
6 :0x00
7 :0x00
8 :0x00
9 :0x00
10 :0x00
11 :0x00
12 :0x00
13 :0x00
14 :0x00
15 :0x00
16 :0x00
17 :0x00
18 :0x00
19 :0x00
20 :0x00
21 :0x00
22 :0x00
23 :0x00
24 :0x00
25 :0x00
26 :0x00
27 :0x00
28 :0x00
29 :0x00
30 :0x00
31 :0x00
32 :0x00
33 :0x00
34 :0x00
35 :0x00
36 :0x00
37 :0x00
38 :0x00
39 :0x00
40 :0x00
41 :0x00
42 :0x00
43 :0x00
44 :0x00
45 :0x00
46 :0x00
47 :0x00
48 :0x00
49 :0x00
50 :0x00
51 :0x00
52 :0x00
53 :0x00
54 :0x00
55 :0x00
56 :0x00
57 :0x00
58 :0x00
59 :0x00
60 :0x00
61 :0x00
62 :0x00
63 :0x00
64 :0x00
65 :0x00
66 :0x00
67 :0x00
68 :0x00
69 :0x00
70 :0x00
71 :0x00
72 :0x00
73 :0x00
74 :0x00
75 :0x00
76 :0x00
77 :0x00
78 :0x00
79 :0x00
80 :0x00
81 :0x00
82 :0x00
83 :0x00
84 :0x00
85 :0x00
86 :0x00
87 :0x00
88 :0x00
89 :0x00
90 :0x00
91 :0x00
92 :0x00
93 :0x00
94 :0x00
95 :0x00

rf
0 :0x00000000
1 :0x00000000
2 :0x00000000
3 :0x00000000



[-- Attachment #3: dump-good-connected.txt --]
[-- Type: text/plain, Size: 3672 bytes --]

kernel: 2.6.34-rc2
driver:	rt2500usb
version:	2.3.0
compiled:	Mar 22 2010 14:59:58
dev_flags: 0x001000df
rt chip:	2570
rf chip:	0005
revision:	0005

register	base	words	wordsize
csr	1024	128	2
eeprom	0	53	2
bbp	0	96	1
rf	4	4	4

csr
0 :0x00000005
1 :0x00000004
2 :0x00001700
3 :0x0000eb31
4 :0x000031a5
5 :0x00001a00
6 :0x0000d992
7 :0x00006e24
8 :0x00000980
9 :0x0000ff1d
10 :0x00000009
11 :0x0000000a
12 :0x00000156
13 :0x00001111
14 :0x00001e11
15 :0x000001ee
16 :0x00000000
17 :0x000000aa
18 :0x00008450
19 :0x0000ff00
20 :0x00000003
21 :0x00001e46
22 :0x00000053
23 :0x00000000
24 :0x00000000
25 :0x00000000
26 :0x00000000
27 :0x00000000
28 :0x00000000
29 :0x00000000
30 :0x00000000
31 :0x00000000
32 :0x000000c0
33 :0x0000b162
34 :0x0000007e
35 :0x0000b3af
36 :0x0000b3aa
37 :0x00008c8d
38 :0x00008b8a
39 :0x00008687
40 :0x00000085
41 :0x00000162
42 :0x0000000e
43 :0x0000000f
44 :0x0000140a
45 :0x00007038
46 :0x00000c13
47 :0x00000609
48 :0x00000305
49 :0x00000203
50 :0x00001900
51 :0x0000000b
52 :0x00000003
53 :0x0000e78f
54 :0x00000000
55 :0x00000000
56 :0x00000000
57 :0x00000000
58 :0x00000000
59 :0x00000000
60 :0x00000000
61 :0x00000000
62 :0x00000000
63 :0x00000000
64 :0x00000000
65 :0x00000000
66 :0x00000000
67 :0x00000000
68 :0x00000000
69 :0x00000000
70 :0x00000000
71 :0x00000000
72 :0x00000000
73 :0x00000000
74 :0x00000000
75 :0x00000000
76 :0x00000000
77 :0x00000000
78 :0x00000000
79 :0x00000000
80 :0x00000000
81 :0x00000000
82 :0x00000000
83 :0x00000000
84 :0x00000000
85 :0x00000000
86 :0x00000000
87 :0x00000000
88 :0x00000000
89 :0x00000000
90 :0x00000000
91 :0x00000000
92 :0x00000000
93 :0x00000000
94 :0x00000000
95 :0x00000000
96 :0x00001221
97 :0x00000003
98 :0x00000000
99 :0x00000000
100 :0x0000000f
101 :0x00008204
102 :0x0000821c
103 :0x0000112a
104 :0x00000000
105 :0x00000e1b
106 :0x00005400
107 :0x00000000
108 :0x00000000
109 :0x00000000
110 :0x00000000
111 :0x00000000
112 :0x000004c0
113 :0x0000883b
114 :0x0000006f
115 :0x00002c75
116 :0x00000000
117 :0x00000000
118 :0x00000015
119 :0x00000000
120 :0x00000003
121 :0x00000000
122 :0x0000005d
123 :0x00000000
124 :0x00000000
125 :0x00000000
126 :0x00000000
127 :0x00000000

eeprom
0 :0x2570
1 :0x0104
2 :0x1700
3 :0xeb31
4 :0x31a5
5 :0xffff
6 :0xffff
7 :0xffff
8 :0xffff
9 :0xffff
10 :0xffff
11 :0x2815
12 :0xfff0
13 :0x02ff
14 :0x1133
15 :0x1518
16 :0x1618
17 :0x3e00
18 :0xffff
19 :0xffff
20 :0xffff
21 :0xffff
22 :0xffff
23 :0xffff
24 :0xffff
25 :0xffff
26 :0xffff
27 :0xffff
28 :0xffff
29 :0xffff
30 :0x1616
31 :0x1716
32 :0x1717
33 :0x1717
34 :0x1818
35 :0x1918
36 :0x1a19
37 :0xffff
38 :0xffff
39 :0xffff
40 :0xffff
41 :0xffff
42 :0xffff
43 :0xffff
44 :0xffff
45 :0xffff
46 :0xffff
47 :0xffff
48 :0x0032
49 :0x6880
50 :0x3850
51 :0x7666
52 :0xfa3e

bbp
0 :0x13
1 :0xa2
2 :0x04
3 :0x02
4 :0x19
5 :0x0b
6 :0x00
7 :0x0e
8 :0x00
9 :0x00
10 :0x00
11 :0x04
12 :0x00
13 :0xe0
14 :0x18
15 :0x30
16 :0xac
17 :0x3e
18 :0x18
19 :0xff
20 :0x1e
21 :0x18
22 :0x18
23 :0x08
24 :0x80
25 :0x50
26 :0x08
27 :0x23
28 :0x22
29 :0x00
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 :0x33
44 :0x22
45 :0x2b
46 :0xb4
47 :0x0a
48 :0x04
49 :0x04
50 :0x90
51 :0x26
52 :0x04
53 :0x10
54 :0x18
55 :0x17
56 :0x08
57 :0x10
58 :0x08
59 :0x3e
60 :0x03
61 :0x66
62 :0x00
63 :0x00
64 :0x01
65 :0x03
66 :0x00
67 :0x00
68 :0x00
69 :0x00
70 :0x46
71 :0x00
72 :0x00
73 :0x00
74 :0xd4
75 :0xff
76 :0x19
77 :0x05
78 :0x08
79 :0x00
80 :0x00
81 :0x05
82 :0x14
83 :0x50
84 :0xc0
85 :0x10
86 :0xcf
87 :0x05
88 :0x00
89 :0x00
90 :0x00
91 :0x00
92 :0x00
93 :0x00
94 :0x00
95 :0x00

rf
0 :0x00022010
1 :0x0000089a
2 :0x00062911
3 :0x00000e1b



[-- Attachment #4: dump-bad-attempt.txt --]
[-- Type: text/plain, Size: 3672 bytes --]

kernel: 2.6.34-rc2
driver:	rt2500usb
version:	2.3.0
compiled:	Mar 22 2010 14:59:58
dev_flags: 0x001000df
rt chip:	2570
rf chip:	0005
revision:	0005

register	base	words	wordsize
csr	1024	128	2
eeprom	0	53	2
bbp	0	96	1
rf	4	4	4

csr
0 :0x00000005
1 :0x00000004
2 :0x00001700
3 :0x0000eb31
4 :0x000031a5
5 :0x00000000
6 :0x00000000
7 :0x00000000
8 :0x00000980
9 :0x0000ff1d
10 :0x00000014
11 :0x0000000a
12 :0x0000016c
13 :0x00001111
14 :0x00001e11
15 :0x000001ee
16 :0x00000000
17 :0x000000be
18 :0x00008450
19 :0x0000ff00
20 :0x00000003
21 :0x00001e46
22 :0x00000053
23 :0x00000000
24 :0x00000000
25 :0x00000000
26 :0x00000000
27 :0x00000000
28 :0x00000000
29 :0x00000000
30 :0x00000000
31 :0x00000000
32 :0x000000c0
33 :0x0000b162
34 :0x0000007e
35 :0x0000b3af
36 :0x0000b3aa
37 :0x00008c8d
38 :0x00008b8a
39 :0x00008687
40 :0x00000085
41 :0x00000162
42 :0x0000000a
43 :0x0000000f
44 :0x0000140a
45 :0x00007038
46 :0x00000c13
47 :0x00000609
48 :0x00000305
49 :0x00000203
50 :0x00001900
51 :0x0000000b
52 :0x00000003
53 :0x0000e78f
54 :0x00000000
55 :0x00000000
56 :0x00000000
57 :0x00000000
58 :0x00000000
59 :0x00000000
60 :0x00000000
61 :0x00000000
62 :0x00000000
63 :0x00000000
64 :0x00000000
65 :0x00000000
66 :0x00000000
67 :0x00000000
68 :0x00000000
69 :0x00000000
70 :0x00000000
71 :0x00000000
72 :0x00000000
73 :0x00000000
74 :0x00000000
75 :0x00000000
76 :0x00000000
77 :0x00000000
78 :0x00000000
79 :0x00000000
80 :0x00000000
81 :0x00000000
82 :0x00000000
83 :0x00000000
84 :0x00000000
85 :0x00000000
86 :0x00000000
87 :0x00000000
88 :0x00000000
89 :0x00000000
90 :0x00000000
91 :0x00000000
92 :0x00000000
93 :0x00000000
94 :0x00000000
95 :0x00000000
96 :0x00001221
97 :0x00000003
98 :0x00000000
99 :0x00000000
100 :0x0000000f
101 :0x00008204
102 :0x0000821c
103 :0x00001126
104 :0x00000000
105 :0x00000e07
106 :0x00005400
107 :0x00000000
108 :0x00000000
109 :0x00000000
110 :0x00000000
111 :0x00000000
112 :0x00000000
113 :0x00000dd0
114 :0x00000048
115 :0x00000000
116 :0x00000000
117 :0x00000000
118 :0x00000010
119 :0x00000000
120 :0x00000000
121 :0x00000001
122 :0x00000000
123 :0x00000000
124 :0x00000000
125 :0x00000000
126 :0x00000000
127 :0x00000000

eeprom
0 :0x2570
1 :0x0104
2 :0x1700
3 :0xeb31
4 :0x31a5
5 :0xffff
6 :0xffff
7 :0xffff
8 :0xffff
9 :0xffff
10 :0xffff
11 :0x2815
12 :0xfff0
13 :0x02ff
14 :0x1133
15 :0x1518
16 :0x1618
17 :0x3e00
18 :0xffff
19 :0xffff
20 :0xffff
21 :0xffff
22 :0xffff
23 :0xffff
24 :0xffff
25 :0xffff
26 :0xffff
27 :0xffff
28 :0xffff
29 :0xffff
30 :0x1616
31 :0x1716
32 :0x1717
33 :0x1717
34 :0x1818
35 :0x1918
36 :0x1a19
37 :0xffff
38 :0xffff
39 :0xffff
40 :0xffff
41 :0xffff
42 :0xffff
43 :0xffff
44 :0xffff
45 :0xffff
46 :0xffff
47 :0xffff
48 :0x0032
49 :0x6880
50 :0x3850
51 :0x7666
52 :0xfa3e

bbp
0 :0x13
1 :0xab
2 :0x04
3 :0x02
4 :0x19
5 :0x0b
6 :0x10
7 :0x00
8 :0x00
9 :0x00
10 :0x00
11 :0x04
12 :0x00
13 :0xe0
14 :0x18
15 :0x30
16 :0xac
17 :0x3e
18 :0x18
19 :0xff
20 :0x1e
21 :0x18
22 :0x18
23 :0x08
24 :0x80
25 :0x50
26 :0x08
27 :0x23
28 :0x18
29 :0x00
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 :0x0b
43 :0x6f
44 :0x29
45 :0x36
46 :0xa3
47 :0x0a
48 :0x04
49 :0x00
50 :0x70
51 :0x26
52 :0x02
53 :0x10
54 :0x18
55 :0x2e
56 :0x08
57 :0x10
58 :0x08
59 :0x3e
60 :0x02
61 :0x66
62 :0x00
63 :0x00
64 :0x01
65 :0x03
66 :0x00
67 :0x00
68 :0x00
69 :0x00
70 :0x46
71 :0x00
72 :0x00
73 :0x00
74 :0xd4
75 :0xff
76 :0x19
77 :0x05
78 :0x08
79 :0x00
80 :0x00
81 :0x05
82 :0x14
83 :0x50
84 :0xc0
85 :0x10
86 :0xcf
87 :0x00
88 :0x00
89 :0x00
90 :0x00
91 :0x00
92 :0x00
93 :0x00
94 :0x00
95 :0x00

rf
0 :0x00022010
1 :0x0000089a
2 :0x00062911
3 :0x00000e1b



[-- Attachment #5: dump-bad-after.txt --]
[-- Type: text/plain, Size: 3672 bytes --]

kernel: 2.6.34-rc2
driver:	rt2500usb
version:	2.3.0
compiled:	Mar 22 2010 14:59:58
dev_flags: 0x001000df
rt chip:	2570
rf chip:	0005
revision:	0005

register	base	words	wordsize
csr	1024	128	2
eeprom	0	53	2
bbp	0	96	1
rf	4	4	4

csr
0 :0x00000005
1 :0x00000004
2 :0x00001700
3 :0x0000eb31
4 :0x000031a5
5 :0x00000000
6 :0x00000000
7 :0x00000000
8 :0x00000980
9 :0x0000ff1d
10 :0x00000014
11 :0x0000000a
12 :0x0000016c
13 :0x00001111
14 :0x00001e11
15 :0x000001ee
16 :0x00000000
17 :0x000000be
18 :0x00008450
19 :0x0000ff00
20 :0x00000003
21 :0x00001e46
22 :0x00000053
23 :0x00000000
24 :0x00000000
25 :0x00000000
26 :0x00000000
27 :0x00000000
28 :0x00000000
29 :0x00000000
30 :0x00000000
31 :0x00000000
32 :0x000000c0
33 :0x0000b162
34 :0x0000007e
35 :0x0000b3af
36 :0x0000b3aa
37 :0x00008c8d
38 :0x00008b8a
39 :0x00008687
40 :0x00000085
41 :0x00000162
42 :0x0000000a
43 :0x0000000f
44 :0x0000140a
45 :0x00007038
46 :0x00000c13
47 :0x00000609
48 :0x00000305
49 :0x00000203
50 :0x00001900
51 :0x0000000b
52 :0x00000003
53 :0x0000e78f
54 :0x00000000
55 :0x00000000
56 :0x00000000
57 :0x00000000
58 :0x00000000
59 :0x00000000
60 :0x00000000
61 :0x00000000
62 :0x00000000
63 :0x00000000
64 :0x00000000
65 :0x00000000
66 :0x00000000
67 :0x00000000
68 :0x00000000
69 :0x00000000
70 :0x00000000
71 :0x00000000
72 :0x00000000
73 :0x00000000
74 :0x00000000
75 :0x00000000
76 :0x00000000
77 :0x00000000
78 :0x00000000
79 :0x00000000
80 :0x00000000
81 :0x00000000
82 :0x00000000
83 :0x00000000
84 :0x00000000
85 :0x00000000
86 :0x00000000
87 :0x00000000
88 :0x00000000
89 :0x00000000
90 :0x00000000
91 :0x00000000
92 :0x00000000
93 :0x00000000
94 :0x00000000
95 :0x00000000
96 :0x00001221
97 :0x00000003
98 :0x00000000
99 :0x00000000
100 :0x0000000f
101 :0x00008204
102 :0x0000821c
103 :0x00001100
104 :0x00000000
105 :0x00000e1b
106 :0x00005400
107 :0x00000000
108 :0x00000000
109 :0x00000000
110 :0x00000000
111 :0x00000000
112 :0x00000000
113 :0x00000000
114 :0x00000000
115 :0x00000000
116 :0x00000000
117 :0x00000000
118 :0x00000000
119 :0x00000000
120 :0x00000000
121 :0x00000000
122 :0x00000000
123 :0x00000000
124 :0x00000000
125 :0x00000000
126 :0x00000000
127 :0x00000000

eeprom
0 :0x2570
1 :0x0104
2 :0x1700
3 :0xeb31
4 :0x31a5
5 :0xffff
6 :0xffff
7 :0xffff
8 :0xffff
9 :0xffff
10 :0xffff
11 :0x2815
12 :0xfff0
13 :0x02ff
14 :0x1133
15 :0x1518
16 :0x1618
17 :0x3e00
18 :0xffff
19 :0xffff
20 :0xffff
21 :0xffff
22 :0xffff
23 :0xffff
24 :0xffff
25 :0xffff
26 :0xffff
27 :0xffff
28 :0xffff
29 :0xffff
30 :0x1616
31 :0x1716
32 :0x1717
33 :0x1717
34 :0x1818
35 :0x1918
36 :0x1a19
37 :0xffff
38 :0xffff
39 :0xffff
40 :0xffff
41 :0xffff
42 :0xffff
43 :0xffff
44 :0xffff
45 :0xffff
46 :0xffff
47 :0xffff
48 :0x0032
49 :0x6880
50 :0x3850
51 :0x7666
52 :0xfa3e

bbp
0 :0x13
1 :0xab
2 :0x04
3 :0x02
4 :0x19
5 :0x0b
6 :0x10
7 :0x00
8 :0x00
9 :0x00
10 :0x00
11 :0x04
12 :0x00
13 :0xe0
14 :0x18
15 :0x30
16 :0xac
17 :0x3e
18 :0x18
19 :0xff
20 :0x1e
21 :0x18
22 :0x18
23 :0x08
24 :0x80
25 :0x50
26 :0x08
27 :0x23
28 :0x18
29 :0x00
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 :0x0b
43 :0x6f
44 :0x29
45 :0x36
46 :0xa3
47 :0x0a
48 :0x04
49 :0x00
50 :0x70
51 :0x26
52 :0x02
53 :0x10
54 :0x18
55 :0x2e
56 :0x08
57 :0x10
58 :0x08
59 :0x3e
60 :0x02
61 :0x66
62 :0x00
63 :0x00
64 :0x01
65 :0x03
66 :0x00
67 :0x00
68 :0x00
69 :0x00
70 :0x46
71 :0x00
72 :0x00
73 :0x00
74 :0xd4
75 :0xff
76 :0x19
77 :0x05
78 :0x08
79 :0x00
80 :0x00
81 :0x05
82 :0x14
83 :0x50
84 :0xc0
85 :0x10
86 :0xcf
87 :0x00
88 :0x00
89 :0x00
90 :0x00
91 :0x00
92 :0x00
93 :0x00
94 :0x00
95 :0x00

rf
0 :0x00022010
1 :0x0000089a
2 :0x00062911
3 :0x00000e1b

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ivo Van Doorn]

On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
<linux@rainbow-software.org> wrote:
> On Monday 22 March 2010, Ivo Van Doorn wrote:
>> >> But I though it was mentioned that disabling HW crypto didn't solve
>> >> the issue due to a second bug in a later kernel?
>> >
>> > That was a false positive. Probably because the device was not unplugged
>> > between the tests (and looks like the driver does not initialize the chip
>> > completely). It's not reliable, it sometimes stops working after reboot.
>>
>> Ah well that at least simplifies the problem. I'll have to retest rt2500usb
>> soon to see why the HW crypto failed. I am sure I had it working for WEP,
>> WPA and WPA2
>> before I submitted the patch.
>
> So let's try to fix it instead of disabling.
>
> First, the unrealiability (keeping HW encryption disabled). With the driver
> loaded but not doing anything more, the register dumps are same for both
> working and non-working case (dump-init.txt).
>
> dump-good-connected.txt is a dump after successful association and DHCP
> dump-bad-attempt.txt is a dump after successful association during non-working
> DHCP attempt
> dump-bad-after.txt is a dump after DHCP timed out

With association working, but DHCP failing it most likely means that
somehow the frame was malformatted.
The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
And that is commonly the source of
problems, because what has to be done depends heavily on the encryption type.

So could you verify which of the encryption types (WEP,WPA,WPA2) is
failing or working? That would give a starting
position on which bytes might be corrupted.

Ivo

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
>
> <linux@rainbow-software.org> wrote:
> > On Monday 22 March 2010, Ivo Van Doorn wrote:
> >> >> But I though it was mentioned that disabling HW crypto didn't solve
> >> >> the issue due to a second bug in a later kernel?
> >> >
> >> > That was a false positive. Probably because the device was not
> >> > unplugged between the tests (and looks like the driver does not
> >> > initialize the chip completely). It's not reliable, it sometimes stops
> >> > working after reboot.
> >>
> >> Ah well that at least simplifies the problem. I'll have to retest
> >> rt2500usb soon to see why the HW crypto failed. I am sure I had it
> >> working for WEP, WPA and WPA2
> >> before I submitted the patch.
> >
> > So let's try to fix it instead of disabling.
> >
> > First, the unrealiability (keeping HW encryption disabled). With the
> > driver loaded but not doing anything more, the register dumps are same
> > for both working and non-working case (dump-init.txt).
> >
> > dump-good-connected.txt is a dump after successful association and DHCP
> > dump-bad-attempt.txt is a dump after successful association during
> > non-working DHCP attempt
> > dump-bad-after.txt is a dump after DHCP timed out
>
> With association working, but DHCP failing it most likely means that
> somehow the frame was malformatted.
> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
> And that is commonly the source of
> problems, because what has to be done depends heavily on the encryption
> type.
>
> So could you verify which of the encryption types (WEP,WPA,WPA2) is
> failing or working? That would give a starting
> position on which bytes might be corrupted.

I was testing only with WPA2 before. I did some more testing today. The results:

No encryption - works always
WEP - sometimes works, sometimes not - same with and without HW encryption
WPA - sometimes works, sometimes not - same with and without HW encryption
WPA2 - never works with HW encryption
     - sometimes works, sometimes not without HW encryptionn

So it seems that there are two problems:
 1. random problems with any encryption
 2. WPA2 is broken with HW encryption

When the "random" problem appears, this appears in dmesg:
wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
wlan1: authenticated
wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=2)
wlan1: associated
phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
No probe response from AP 00:13:d4:0f:f3:17 after 500ms, disconnecting.

Disabling call to rt2500usb_set_state() in rt2500usb_set_device_state() seems
to fix problem 1. After this change, WEP and WPA work always regardless of
HW encryption (and WPA2 works always without it).

-- 
Ondrej Zary

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ivo Van Doorn]

On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> On Tuesday 23 March 2010, Ivo Van Doorn wrote:
>> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
>>
>> <linux@rainbow-software.org> wrote:
>> > On Monday 22 March 2010, Ivo Van Doorn wrote:
>> >> >> But I though it was mentioned that disabling HW crypto didn't solve
>> >> >> the issue due to a second bug in a later kernel?
>> >> >
>> >> > That was a false positive. Probably because the device was not
>> >> > unplugged between the tests (and looks like the driver does not
>> >> > initialize the chip completely). It's not reliable, it sometimes stops
>> >> > working after reboot.
>> >>
>> >> Ah well that at least simplifies the problem. I'll have to retest
>> >> rt2500usb soon to see why the HW crypto failed. I am sure I had it
>> >> working for WEP, WPA and WPA2
>> >> before I submitted the patch.
>> >
>> > So let's try to fix it instead of disabling.
>> >
>> > First, the unrealiability (keeping HW encryption disabled). With the
>> > driver loaded but not doing anything more, the register dumps are same
>> > for both working and non-working case (dump-init.txt).
>> >
>> > dump-good-connected.txt is a dump after successful association and DHCP
>> > dump-bad-attempt.txt is a dump after successful association during
>> > non-working DHCP attempt
>> > dump-bad-after.txt is a dump after DHCP timed out
>>
>> With association working, but DHCP failing it most likely means that
>> somehow the frame was malformatted.
>> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
>> And that is commonly the source of
>> problems, because what has to be done depends heavily on the encryption
>> type.
>>
>> So could you verify which of the encryption types (WEP,WPA,WPA2) is
>> failing or working? That would give a starting
>> position on which bytes might be corrupted.
>
> I was testing only with WPA2 before. I did some more testing today. The results:
>
> No encryption - works always
> WEP - sometimes works, sometimes not - same with and without HW encryption
> WPA - sometimes works, sometimes not - same with and without HW encryption
> WPA2 - never works with HW encryption
>     - sometimes works, sometimes not without HW encryptionn
>
> So it seems that there are two problems:
>  1. random problems with any encryption
>  2. WPA2 is broken with HW encryption
>
> When the "random" problem appears, this appears in dmesg:
> wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
> wlan1: authenticated
> wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
> wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=2)
> wlan1: associated
> phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
> phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
> No probe response from AP 00:13:d4:0f:f3:17 after 500ms, disconnecting.
>
> Disabling call to rt2500usb_set_state() in rt2500usb_set_device_state() seems
> to fix problem 1. After this change, WEP and WPA work always regardless of
> HW encryption (and WPA2 works always without it).

Ok, lets focus on the HW crypto for now.

If WPA2 fails, then the WPA2 specific code for IV/EIV/ICV isn't
working. Most likely
the device either doesn't send all data back to the driver (while the
driver does expect it)
or it adds additional data which the driver doesn't expect. (See
rt2x00crypto.c for the frame
manipulation during HW crypto).

Could you check the full packet data of a DHCP request with and
without HW crypto?
That might give a clue about what the hardware is sending for extra data.

Ivo

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary <linux@rainbow-software.org> 
wrote:
> > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> >> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
> >>
> >> <linux@rainbow-software.org> wrote:
> >> > On Monday 22 March 2010, Ivo Van Doorn wrote:
> >> >> >> But I though it was mentioned that disabling HW crypto didn't
> >> >> >> solve the issue due to a second bug in a later kernel?
> >> >> >
> >> >> > That was a false positive. Probably because the device was not
> >> >> > unplugged between the tests (and looks like the driver does not
> >> >> > initialize the chip completely). It's not reliable, it sometimes
> >> >> > stops working after reboot.
> >> >>
> >> >> Ah well that at least simplifies the problem. I'll have to retest
> >> >> rt2500usb soon to see why the HW crypto failed. I am sure I had it
> >> >> working for WEP, WPA and WPA2
> >> >> before I submitted the patch.
> >> >
> >> > So let's try to fix it instead of disabling.
> >> >
> >> > First, the unrealiability (keeping HW encryption disabled). With the
> >> > driver loaded but not doing anything more, the register dumps are same
> >> > for both working and non-working case (dump-init.txt).
> >> >
> >> > dump-good-connected.txt is a dump after successful association and
> >> > DHCP dump-bad-attempt.txt is a dump after successful association
> >> > during non-working DHCP attempt
> >> > dump-bad-after.txt is a dump after DHCP timed out
> >>
> >> With association working, but DHCP failing it most likely means that
> >> somehow the frame was malformatted.
> >> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
> >> And that is commonly the source of
> >> problems, because what has to be done depends heavily on the encryption
> >> type.
> >>
> >> So could you verify which of the encryption types (WEP,WPA,WPA2) is
> >> failing or working? That would give a starting
> >> position on which bytes might be corrupted.
> >
> > I was testing only with WPA2 before. I did some more testing today. The
> > results:
> >
> > No encryption - works always
> > WEP - sometimes works, sometimes not - same with and without HW
> > encryption WPA - sometimes works, sometimes not - same with and without
> > HW encryption WPA2 - never works with HW encryption
> >     - sometimes works, sometimes not without HW encryptionn
> >
> > So it seems that there are two problems:
> >  1. random problems with any encryption
> >  2. WPA2 is broken with HW encryption
> >
> > When the "random" problem appears, this appears in dmesg:
> > wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
> > wlan1: authenticated
> > wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
> > wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=2)
> > wlan1: associated
> > phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state
> > 3 (-16). phy0 -> rt2500usb_set_device_state: Error - Device failed to
> > enter state 3 (-16). No probe response from AP 00:13:d4:0f:f3:17 after
> > 500ms, disconnecting.
> >
> > Disabling call to rt2500usb_set_state() in rt2500usb_set_device_state()
> > seems to fix problem 1. After this change, WEP and WPA work always
> > regardless of HW encryption (and WPA2 works always without it).
>
> Ok, lets focus on the HW crypto for now.
>
> If WPA2 fails, then the WPA2 specific code for IV/EIV/ICV isn't
> working. Most likely
> the device either doesn't send all data back to the driver (while the
> driver does expect it)
> or it adds additional data which the driver doesn't expect. (See
> rt2x00crypto.c for the frame
> manipulation during HW crypto).
>
> Could you check the full packet data of a DHCP request with and
> without HW crypto?
> That might give a clue about what the hardware is sending for extra data.

How do I access the full packets? I tried using another machine with "iwconfig 
wlan0 mode monitor" and tcpdump. It captured many packets and I'm unable to 
identify the interesting ones.

-- 
Ondrej Zary

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ivo Van Doorn]

On Wed, Mar 24, 2010 at 2:12 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> On Tuesday 23 March 2010, Ivo Van Doorn wrote:
>> On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary <linux@rainbow-software.org>
> wrote:
>> > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
>> >> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
>> >>
>> >> <linux@rainbow-software.org> wrote:
>> >> > On Monday 22 March 2010, Ivo Van Doorn wrote:
>> >> >> >> But I though it was mentioned that disabling HW crypto didn't
>> >> >> >> solve the issue due to a second bug in a later kernel?
>> >> >> >
>> >> >> > That was a false positive. Probably because the device was not
>> >> >> > unplugged between the tests (and looks like the driver does not
>> >> >> > initialize the chip completely). It's not reliable, it sometimes
>> >> >> > stops working after reboot.
>> >> >>
>> >> >> Ah well that at least simplifies the problem. I'll have to retest
>> >> >> rt2500usb soon to see why the HW crypto failed. I am sure I had it
>> >> >> working for WEP, WPA and WPA2
>> >> >> before I submitted the patch.
>> >> >
>> >> > So let's try to fix it instead of disabling.
>> >> >
>> >> > First, the unrealiability (keeping HW encryption disabled). With the
>> >> > driver loaded but not doing anything more, the register dumps are same
>> >> > for both working and non-working case (dump-init.txt).
>> >> >
>> >> > dump-good-connected.txt is a dump after successful association and
>> >> > DHCP dump-bad-attempt.txt is a dump after successful association
>> >> > during non-working DHCP attempt
>> >> > dump-bad-after.txt is a dump after DHCP timed out
>> >>
>> >> With association working, but DHCP failing it most likely means that
>> >> somehow the frame was malformatted.
>> >> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
>> >> And that is commonly the source of
>> >> problems, because what has to be done depends heavily on the encryption
>> >> type.
>> >>
>> >> So could you verify which of the encryption types (WEP,WPA,WPA2) is
>> >> failing or working? That would give a starting
>> >> position on which bytes might be corrupted.
>> >
>> > I was testing only with WPA2 before. I did some more testing today. The
>> > results:
>> >
>> > No encryption - works always
>> > WEP - sometimes works, sometimes not - same with and without HW
>> > encryption WPA - sometimes works, sometimes not - same with and without
>> > HW encryption WPA2 - never works with HW encryption
>> >     - sometimes works, sometimes not without HW encryptionn
>> >
>> > So it seems that there are two problems:
>> >  1. random problems with any encryption
>> >  2. WPA2 is broken with HW encryption
>> >
>> > When the "random" problem appears, this appears in dmesg:
>> > wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
>> > wlan1: authenticated
>> > wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
>> > wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=2)
>> > wlan1: associated
>> > phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state
>> > 3 (-16). phy0 -> rt2500usb_set_device_state: Error - Device failed to
>> > enter state 3 (-16). No probe response from AP 00:13:d4:0f:f3:17 after
>> > 500ms, disconnecting.
>> >
>> > Disabling call to rt2500usb_set_state() in rt2500usb_set_device_state()
>> > seems to fix problem 1. After this change, WEP and WPA work always
>> > regardless of HW encryption (and WPA2 works always without it).
>>
>> Ok, lets focus on the HW crypto for now.
>>
>> If WPA2 fails, then the WPA2 specific code for IV/EIV/ICV isn't
>> working. Most likely
>> the device either doesn't send all data back to the driver (while the
>> driver does expect it)
>> or it adds additional data which the driver doesn't expect. (See
>> rt2x00crypto.c for the frame
>> manipulation during HW crypto).
>>
>> Could you check the full packet data of a DHCP request with and
>> without HW crypto?
>> That might give a clue about what the hardware is sending for extra data.
>
> How do I access the full packets? I tried using another machine with "iwconfig
> wlan0 mode monitor" and tcpdump. It captured many packets and I'm unable to
> identify the interesting ones.

You won't get the useful stuff from monitor mode.
You have to enable rt2x00 debugfs support, to find a framedump file in
the rt2x00 debugfs folder.

You should use the framedump tool from:
http://kernel.org/pub/linux/kernel/people/ivd/tools/

To get the frame dumps in nicely formatted lines for analysis.

Ivo

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

On Wednesday 24 March 2010, Ivo Van Doorn wrote:
> On Wed, Mar 24, 2010 at 2:12 PM, Ondrej Zary <linux@rainbow-software.org> 
wrote:
> > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> >> On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary
> >> <linux@rainbow-software.org>
> >
> > wrote:
> >> > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> >> >> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
> >> >>
> >> >> <linux@rainbow-software.org> wrote:
> >> >> > On Monday 22 March 2010, Ivo Van Doorn wrote:
> >> >> >> >> But I though it was mentioned that disabling HW crypto didn't
> >> >> >> >> solve the issue due to a second bug in a later kernel?
> >> >> >> >
> >> >> >> > That was a false positive. Probably because the device was not
> >> >> >> > unplugged between the tests (and looks like the driver does not
> >> >> >> > initialize the chip completely). It's not reliable, it sometimes
> >> >> >> > stops working after reboot.
> >> >> >>
> >> >> >> Ah well that at least simplifies the problem. I'll have to retest
> >> >> >> rt2500usb soon to see why the HW crypto failed. I am sure I had it
> >> >> >> working for WEP, WPA and WPA2
> >> >> >> before I submitted the patch.
> >> >> >
> >> >> > So let's try to fix it instead of disabling.
> >> >> >
> >> >> > First, the unrealiability (keeping HW encryption disabled). With
> >> >> > the driver loaded but not doing anything more, the register dumps
> >> >> > are same for both working and non-working case (dump-init.txt).
> >> >> >
> >> >> > dump-good-connected.txt is a dump after successful association and
> >> >> > DHCP dump-bad-attempt.txt is a dump after successful association
> >> >> > during non-working DHCP attempt
> >> >> > dump-bad-after.txt is a dump after DHCP timed out
> >> >>
> >> >> With association working, but DHCP failing it most likely means that
> >> >> somehow the frame was malformatted.
> >> >> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
> >> >> And that is commonly the source of
> >> >> problems, because what has to be done depends heavily on the
> >> >> encryption type.
> >> >>
> >> >> So could you verify which of the encryption types (WEP,WPA,WPA2) is
> >> >> failing or working? That would give a starting
> >> >> position on which bytes might be corrupted.
> >> >
> >> > I was testing only with WPA2 before. I did some more testing today.
> >> > The results:
> >> >
> >> > No encryption - works always
> >> > WEP - sometimes works, sometimes not - same with and without HW
> >> > encryption WPA - sometimes works, sometimes not - same with and
> >> > without HW encryption WPA2 - never works with HW encryption
> >> >     - sometimes works, sometimes not without HW encryptionn
> >> >
> >> > So it seems that there are two problems:
> >> >  1. random problems with any encryption
> >> >  2. WPA2 is broken with HW encryption
> >> >
> >> > When the "random" problem appears, this appears in dmesg:
> >> > wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
> >> > wlan1: authenticated
> >> > wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
> >> > wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0
> >> > aid=2) wlan1: associated
> >> > phy0 -> rt2500usb_set_device_state: Error - Device failed to enter
> >> > state 3 (-16). phy0 -> rt2500usb_set_device_state: Error - Device
> >> > failed to enter state 3 (-16). No probe response from AP
> >> > 00:13:d4:0f:f3:17 after 500ms, disconnecting.
> >> >
> >> > Disabling call to rt2500usb_set_state() in
> >> > rt2500usb_set_device_state() seems to fix problem 1. After this
> >> > change, WEP and WPA work always regardless of HW encryption (and WPA2
> >> > works always without it).
> >>
> >> Ok, lets focus on the HW crypto for now.
> >>
> >> If WPA2 fails, then the WPA2 specific code for IV/EIV/ICV isn't
> >> working. Most likely
> >> the device either doesn't send all data back to the driver (while the
> >> driver does expect it)
> >> or it adds additional data which the driver doesn't expect. (See
> >> rt2x00crypto.c for the frame
> >> manipulation during HW crypto).
> >>
> >> Could you check the full packet data of a DHCP request with and
> >> without HW crypto?
> >> That might give a clue about what the hardware is sending for extra
> >> data.
> >
> > How do I access the full packets? I tried using another machine with
> > "iwconfig wlan0 mode monitor" and tcpdump. It captured many packets and
> > I'm unable to identify the interesting ones.
>
> You won't get the useful stuff from monitor mode.
> You have to enable rt2x00 debugfs support, to find a framedump file in
> the rt2x00 debugfs folder.
>
> You should use the framedump tool from:
> http://kernel.org/pub/linux/kernel/people/ivd/tools/
>
> To get the frame dumps in nicely formatted lines for analysis.

Thanks, here are the dump files:
http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt

I don't know how wifi encryption works so I don't know what to look for.

-- 
Ondrej Zary

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

On Wednesday 24 March 2010, Ondrej Zary wrote:
> On Wednesday 24 March 2010, Ivo Van Doorn wrote:
> > On Wed, Mar 24, 2010 at 2:12 PM, Ondrej Zary <linux@rainbow-software.org>
>
> wrote:
> > > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> > >> On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary
> > >> <linux@rainbow-software.org>
> > >
> > > wrote:
> > >> > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> > >> >> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
> > >> >>
> > >> >> <linux@rainbow-software.org> wrote:
> > >> >> > On Monday 22 March 2010, Ivo Van Doorn wrote:
> > >> >> >> >> But I though it was mentioned that disabling HW crypto didn't
> > >> >> >> >> solve the issue due to a second bug in a later kernel?
> > >> >> >> >
> > >> >> >> > That was a false positive. Probably because the device was not
> > >> >> >> > unplugged between the tests (and looks like the driver does
> > >> >> >> > not initialize the chip completely). It's not reliable, it
> > >> >> >> > sometimes stops working after reboot.
> > >> >> >>
> > >> >> >> Ah well that at least simplifies the problem. I'll have to
> > >> >> >> retest rt2500usb soon to see why the HW crypto failed. I am sure
> > >> >> >> I had it working for WEP, WPA and WPA2
> > >> >> >> before I submitted the patch.
> > >> >> >
> > >> >> > So let's try to fix it instead of disabling.
> > >> >> >
> > >> >> > First, the unrealiability (keeping HW encryption disabled). With
> > >> >> > the driver loaded but not doing anything more, the register dumps
> > >> >> > are same for both working and non-working case (dump-init.txt).
> > >> >> >
> > >> >> > dump-good-connected.txt is a dump after successful association
> > >> >> > and DHCP dump-bad-attempt.txt is a dump after successful
> > >> >> > association during non-working DHCP attempt
> > >> >> > dump-bad-after.txt is a dump after DHCP timed out
> > >> >>
> > >> >> With association working, but DHCP failing it most likely means
> > >> >> that somehow the frame was malformatted.
> > >> >> The code for HW crypto alters the frame (alters IV/EIV/ICV data
> > >> >> etc). And that is commonly the source of
> > >> >> problems, because what has to be done depends heavily on the
> > >> >> encryption type.
> > >> >>
> > >> >> So could you verify which of the encryption types (WEP,WPA,WPA2) is
> > >> >> failing or working? That would give a starting
> > >> >> position on which bytes might be corrupted.
> > >> >
> > >> > I was testing only with WPA2 before. I did some more testing today.
> > >> > The results:
> > >> >
> > >> > No encryption - works always
> > >> > WEP - sometimes works, sometimes not - same with and without HW
> > >> > encryption WPA - sometimes works, sometimes not - same with and
> > >> > without HW encryption WPA2 - never works with HW encryption
> > >> >     - sometimes works, sometimes not without HW encryptionn
> > >> >
> > >> > So it seems that there are two problems:
> > >> >  1. random problems with any encryption
> > >> >  2. WPA2 is broken with HW encryption
> > >> >
> > >> > When the "random" problem appears, this appears in dmesg:
> > >> > wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
> > >> > wlan1: authenticated
> > >> > wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
> > >> > wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0
> > >> > aid=2) wlan1: associated
> > >> > phy0 -> rt2500usb_set_device_state: Error - Device failed to enter
> > >> > state 3 (-16). phy0 -> rt2500usb_set_device_state: Error - Device
> > >> > failed to enter state 3 (-16). No probe response from AP
> > >> > 00:13:d4:0f:f3:17 after 500ms, disconnecting.
> > >> >
> > >> > Disabling call to rt2500usb_set_state() in
> > >> > rt2500usb_set_device_state() seems to fix problem 1. After this
> > >> > change, WEP and WPA work always regardless of HW encryption (and
> > >> > WPA2 works always without it).
> > >>
> > >> Ok, lets focus on the HW crypto for now.
> > >>
> > >> If WPA2 fails, then the WPA2 specific code for IV/EIV/ICV isn't
> > >> working. Most likely
> > >> the device either doesn't send all data back to the driver (while the
> > >> driver does expect it)
> > >> or it adds additional data which the driver doesn't expect. (See
> > >> rt2x00crypto.c for the frame
> > >> manipulation during HW crypto).
> > >>
> > >> Could you check the full packet data of a DHCP request with and
> > >> without HW crypto?
> > >> That might give a clue about what the hardware is sending for extra
> > >> data.
> > >
> > > How do I access the full packets? I tried using another machine with
> > > "iwconfig wlan0 mode monitor" and tcpdump. It captured many packets and
> > > I'm unable to identify the interesting ones.
> >
> > You won't get the useful stuff from monitor mode.
> > You have to enable rt2x00 debugfs support, to find a framedump file in
> > the rt2x00 debugfs folder.
> >
> > You should use the framedump tool from:
> > http://kernel.org/pub/linux/kernel/people/ivd/tools/
> >
> > To get the frame dumps in nicely formatted lines for analysis.
>
> Thanks, here are the dump files:
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt
>
> I don't know how wifi encryption works so I don't know what to look for.

Some more news. Tested with another AP (Asus WL-300g with DD-WRT) with various 
WPA2 settings (TKIP, AES, TKIP+AES). TKIP works. AES works. TKIP+AES does 
not.

-- 
Ondrej Zary

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Gertjan van Wingerde]

On 03/23/10 16:09, Ondrej Zary wrote:
> On Tuesday 23 March 2010, Ivo Van Doorn wrote:
>> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
>>
>> <linux@rainbow-software.org> wrote:
>>> On Monday 22 March 2010, Ivo Van Doorn wrote:
>>>>>> But I though it was mentioned that disabling HW crypto didn't solve
>>>>>> the issue due to a second bug in a later kernel?
>>>>>
>>>>> That was a false positive. Probably because the device was not
>>>>> unplugged between the tests (and looks like the driver does not
>>>>> initialize the chip completely). It's not reliable, it sometimes stops
>>>>> working after reboot.
>>>>
>>>> Ah well that at least simplifies the problem. I'll have to retest
>>>> rt2500usb soon to see why the HW crypto failed. I am sure I had it
>>>> working for WEP, WPA and WPA2
>>>> before I submitted the patch.
>>>
>>> So let's try to fix it instead of disabling.
>>>
>>> First, the unrealiability (keeping HW encryption disabled). With the
>>> driver loaded but not doing anything more, the register dumps are same
>>> for both working and non-working case (dump-init.txt).
>>>
>>> dump-good-connected.txt is a dump after successful association and DHCP
>>> dump-bad-attempt.txt is a dump after successful association during
>>> non-working DHCP attempt
>>> dump-bad-after.txt is a dump after DHCP timed out
>>
>> With association working, but DHCP failing it most likely means that
>> somehow the frame was malformatted.
>> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
>> And that is commonly the source of
>> problems, because what has to be done depends heavily on the encryption
>> type.
>>
>> So could you verify which of the encryption types (WEP,WPA,WPA2) is
>> failing or working? That would give a starting
>> position on which bytes might be corrupted.
> 
> I was testing only with WPA2 before. I did some more testing today. The results:
> 
> No encryption - works always
> WEP - sometimes works, sometimes not - same with and without HW encryption
> WPA - sometimes works, sometimes not - same with and without HW encryption
> WPA2 - never works with HW encryption
>      - sometimes works, sometimes not without HW encryptionn
> 
> So it seems that there are two problems:
>  1. random problems with any encryption
>  2. WPA2 is broken with HW encryption
> 
> When the "random" problem appears, this appears in dmesg:
> wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
> wlan1: authenticated
> wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
> wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=2)
> wlan1: associated
> phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
> phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
> No probe response from AP 00:13:d4:0f:f3:17 after 500ms, disconnecting.
> 
> Disabling call to rt2500usb_set_state() in rt2500usb_set_device_state() seems
> to fix problem 1. After this change, WEP and WPA work always regardless of
> HW encryption (and WPA2 works always without it).
> 

For this last issue, could you check with powersaving disabled. Just execute
iwconfig wlan1 power off before associating.

The powersaving code looks a bit odd here, and we've had issues with this in the
other rt2x00 drivers as well.

---
Gertjan.

Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary]

On Tuesday 23 March 2010, Gertjan van Wingerde wrote:
> On 03/23/10 16:09, Ondrej Zary wrote:
> > On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> >> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
> >>
> >> <linux@rainbow-software.org> wrote:
> >>> On Monday 22 March 2010, Ivo Van Doorn wrote:
> >>>>>> But I though it was mentioned that disabling HW crypto didn't solve
> >>>>>> the issue due to a second bug in a later kernel?
> >>>>>
> >>>>> That was a false positive. Probably because the device was not
> >>>>> unplugged between the tests (and looks like the driver does not
> >>>>> initialize the chip completely). It's not reliable, it sometimes
> >>>>> stops working after reboot.
> >>>>
> >>>> Ah well that at least simplifies the problem. I'll have to retest
> >>>> rt2500usb soon to see why the HW crypto failed. I am sure I had it
> >>>> working for WEP, WPA and WPA2
> >>>> before I submitted the patch.
> >>>
> >>> So let's try to fix it instead of disabling.
> >>>
> >>> First, the unrealiability (keeping HW encryption disabled). With the
> >>> driver loaded but not doing anything more, the register dumps are same
> >>> for both working and non-working case (dump-init.txt).
> >>>
> >>> dump-good-connected.txt is a dump after successful association and DHCP
> >>> dump-bad-attempt.txt is a dump after successful association during
> >>> non-working DHCP attempt
> >>> dump-bad-after.txt is a dump after DHCP timed out
> >>
> >> With association working, but DHCP failing it most likely means that
> >> somehow the frame was malformatted.
> >> The code for HW crypto alters the frame (alters IV/EIV/ICV data etc).
> >> And that is commonly the source of
> >> problems, because what has to be done depends heavily on the encryption
> >> type.
> >>
> >> So could you verify which of the encryption types (WEP,WPA,WPA2) is
> >> failing or working? That would give a starting
> >> position on which bytes might be corrupted.
> >
> > I was testing only with WPA2 before. I did some more testing today. The
> > results:
> >
> > No encryption - works always
> > WEP - sometimes works, sometimes not - same with and without HW
> > encryption WPA - sometimes works, sometimes not - same with and without
> > HW encryption WPA2 - never works with HW encryption
> >      - sometimes works, sometimes not without HW encryptionn
> >
> > So it seems that there are two problems:
> >  1. random problems with any encryption
> >  2. WPA2 is broken with HW encryption
> >
> > When the "random" problem appears, this appears in dmesg:
> > wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
> > wlan1: authenticated
> > wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
> > wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=2)
> > wlan1: associated
> > phy0 -> rt2500usb_set_device_state: Error - Device failed to enter state
> > 3 (-16). phy0 -> rt2500usb_set_device_state: Error - Device failed to
> > enter state 3 (-16). No probe response from AP 00:13:d4:0f:f3:17 after
> > 500ms, disconnecting.
> >
> > Disabling call to rt2500usb_set_state() in rt2500usb_set_device_state()
> > seems to fix problem 1. After this change, WEP and WPA work always
> > regardless of HW encryption (and WPA2 works always without it).
>
> For this last issue, could you check with powersaving disabled. Just
> execute iwconfig wlan1 power off before associating.

Yes, you're right - executing "iwconfig wlan1 power off" before "ifup wlan1"
causes it to work always. Also when I don't execute it before ifup and it
fails, executing it fixes the problem.

> The powersaving code looks a bit odd here, and we've had issues with this
> in the other rt2x00 drivers as well.

Added some debugging code. 
Working case:
Mar 24 13:43:05 kiosk kernel: set_state=3
Mar 24 13:43:05 kiosk kernel: state=3, bbp_state=0, rf_state=0
Mar 24 13:43:05 kiosk kernel: state=3, bbp_state=1, rf_state=1
Mar 24 13:43:05 kiosk kernel: state=3, bbp_state=3, rf_state=3
Mar 24 13:43:05 kiosk kernel: set_state ok
Mar 24 13:43:05 kiosk kernel: set_state=3
Mar 24 13:43:05 kiosk kernel: state=3, bbp_state=3, rf_state=3
Mar 24 13:43:05 kiosk kernel: set_state ok
Mar 24 13:43:06 kiosk kernel: wlan1: deauthenticating from 00:13:d4:0f:f3:17 by local choice (reason=3)
Mar 24 13:43:06 kiosk kernel: wlan1: authenticate with 00:13:d4:0f:f3:17 (try 1)
Mar 24 13:43:06 kiosk kernel: wlan1: authenticated
Mar 24 13:43:06 kiosk kernel: wlan1: associate with 00:13:d4:0f:f3:17 (try 1)
Mar 24 13:43:06 kiosk kernel: wlan1: RX AssocResp from 00:13:d4:0f:f3:17 (capab=0x411 status=0 aid=1)
Mar 24 13:43:06 kiosk kernel: wlan1: associated
Mar 24 13:43:07 kiosk kernel: set_state=1
Mar 24 13:43:07 kiosk kernel: state=1, bbp_state=1, rf_state=1
Mar 24 13:43:07 kiosk kernel: set_state ok

Non-working case:
Mar 24 13:43:09 kiosk kernel: set_state=3
Mar 24 13:43:09 kiosk kernel: state=3, bbp_state=1, rf_state=1
Mar 24 13:43:09 kiosk kernel: state=3, bbp_state=1, rf_state=1
Mar 24 13:43:09 kiosk kernel: state=3, bbp_state=1, rf_state=1
Mar 24 13:43:09 kiosk kernel: state=3, bbp_state=1, rf_state=1
Mar 24 13:43:09 kiosk kernel: state=3, bbp_state=1, rf_state=1
Mar 24 13:43:09 kiosk kernel: set_state failed
Mar 24 13:43:09 kiosk kernel: phy1 -> rt2500usb_set_device_state: Error - Device failed to enter state 3 (-16).
Mar 24 13:43:12 kiosk kernel: No probe response from AP 00:13:d4:0f:f3:17 after 500ms, disconnecting.

Seems that the bpp_state and rf_state are stuck. Waiting longer (tried 10*REGISTER_BUSY_COUNT) does not help.

-- 
Ondrej Zary

[PATCH] rt2500usb: improve powersaving reliability

[Ondrej Zary]

According to my debugging, retrying 5 times (REGISTER_BUSY_COUNT) does not
provide enough time for the device to enter the required state. Sometimes,
the device needs 12 to 15 retries. Increase it to 20 to be sure.

This improves powersaving reliability but one problem still remains: power
state change sometimes fails completely - the bpp_state and rf_state get
stuck and cannot be changed anymore.

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>

--- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-20 02:17:57.000000000 +0100
+++ linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-24 22:55:53.000000000 +0100
@@ -968,7 +968,7 @@ static int rt2500usb_set_state(struct rt
 	 * We must wait until the register indicates that the
 	 * device has entered the correct state.
 	 */
-	for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
+	for (i = 0; i < 20; i++) {
 		rt2500usb_register_read(rt2x00dev, MAC_CSR17, &reg2);
 		bbp_state = rt2x00_get_field16(reg2, MAC_CSR17_BBP_CURR_STATE);
 		rf_state = rt2x00_get_field16(reg2, MAC_CSR17_RF_CURR_STATE);


-- 
Ondrej Zary

Re: [PATCH] rt2500usb: improve powersaving reliability

[Ivo van Doorn]

On Wednesday 24 March 2010, Ondrej Zary wrote:
> According to my debugging, retrying 5 times (REGISTER_BUSY_COUNT) does not
> provide enough time for the device to enter the required state. Sometimes,
> the device needs 12 to 15 retries. Increase it to 20 to be sure.
> 
> This improves powersaving reliability but one problem still remains: power
> state change sometimes fails completely - the bpp_state and rf_state get
> stuck and cannot be changed anymore.

Gertjan has disabled powersaving in rt2500usb until this can be sorted out.
I think for now that would be the way to go. This patch might be needed anyway,
but I'll let GertJan decide on that one.

My only comment about the fix itself is that the REGISTER_BUSY_COUNT should
be updated. rt2500usb is not the only one which suffers from the timeout, so those
might profit from the extra delay as well.

> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> 
> --- linux-2.6.34-rc2-orig/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-20 02:17:57.000000000 +0100
> +++ linux-2.6.34-rc2/drivers/net/wireless/rt2x00/rt2500usb.c	2010-03-24 22:55:53.000000000 +0100
> @@ -968,7 +968,7 @@ static int rt2500usb_set_state(struct rt
>  	 * We must wait until the register indicates that the
>  	 * device has entered the correct state.
>  	 */
> -	for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
> +	for (i = 0; i < 20; i++) {
>  		rt2500usb_register_read(rt2x00dev, MAC_CSR17, &reg2);
>  		bbp_state = rt2x00_get_field16(reg2, MAC_CSR17_BBP_CURR_STATE);
>  		rf_state = rt2x00_get_field16(reg2, MAC_CSR17_RF_CURR_STATE);
> 
>