Message-Id: <201003231609.57505.linux@rainbow-software.org>
Date:	Tue, 23 Mar 2010 16:09:56 +0100
From:	Ondrej Zary <linux@...nbow-software.org>
To:	Ivo Van Doorn <ivdoorn@...il.com>
Cc:	rt2x00 Users List <users@...x00.serialmonkey.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW  encryption by default

On Tuesday 23 March 2010, Ivo Van Doorn wrote:
> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary
>
> <linux@...nbow-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists