All of lore.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: 17+ 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-31 21:39                       ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.