Messages in this thread | | | From | Ondrej Zary <> | Subject | Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default | Date | Wed, 24 Mar 2010 14:10:22 +0100 |
| |
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
| |