public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Zary <linux@rainbow-software.org>
To: Ivo Van Doorn <ivdoorn@gmail.com>
Cc: rt2x00 Users List <users@rt2x00.serialmonkey.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW  encryption by default
Date: Tue, 23 Mar 2010 16:09:56 +0100	[thread overview]
Message-ID: <201003231609.57505.linux@rainbow-software.org> (raw)
In-Reply-To: <a32f33a41003230236q348c8aeata724042a9c3d9537@mail.gmail.com>

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

  reply	other threads:[~2010-03-23 15:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22 15:01 [PATCH RFC] rt2500usb: disable broken HW encryption by default Ondrej Zary
2010-03-22 15:10 ` [rt2x00-users] " Ivo Van Doorn
2010-03-22 15:30   ` Ondrej Zary
2010-03-22 15:40     ` Ivo Van Doorn
2010-03-23  9:27       ` Ondrej Zary
2010-03-23  9:36         ` Ivo Van Doorn
2010-03-23 15:09           ` Ondrej Zary [this message]
2010-03-23 15:15             ` Ivo Van Doorn
2010-03-24 13:12               ` Ondrej Zary
2010-03-24 13:24                 ` Ivo Van Doorn
2010-03-24 14:52                   ` Ondrej Zary
2010-03-26 11:05                     ` Ondrej Zary
2010-03-23 15:41             ` Gertjan van Wingerde
2010-03-24 13:10               ` Ondrej Zary
2010-03-24 22:07               ` [PATCH] rt2500usb: improve powersaving reliability Ondrej Zary
2010-03-24 22:15                 ` Ivo van Doorn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201003231609.57505.linux@rainbow-software.org \
    --to=linux@rainbow-software.org \
    --cc=ivdoorn@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=users@rt2x00.serialmonkey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox