From: Gertjan van Wingerde <gwingerde@gmail.com>
To: rt2x00 Users List <users@rt2x00.serialmonkey.com>
Cc: Ondrej Zary <linux@rainbow-software.org>,
Ivo Van Doorn <ivdoorn@gmail.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:41:14 +0100 [thread overview]
Message-ID: <4BA8E11A.2020300@gmail.com> (raw)
In-Reply-To: <201003231609.57505.linux@rainbow-software.org>
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.
next prev parent reply other threads:[~2010-03-23 15:41 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
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 [this message]
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=4BA8E11A.2020300@gmail.com \
--to=gwingerde@gmail.com \
--cc=ivdoorn@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rainbow-software.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