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:12:37 +0100 |
| |
On Tuesday 23 March 2010, Ivo Van Doorn wrote: > On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary <linux@rainbow-software.org> 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). > > Ok, lets focus on the HW crypto for now. > > If WPA2 fails, then the WPA2 specific code for IV/EIV/ICV isn't > working. Most likely > the device either doesn't send all data back to the driver (while the > driver does expect it) > or it adds additional data which the driver doesn't expect. (See > rt2x00crypto.c for the frame > manipulation during HW crypto). > > Could you check the full packet data of a DHCP request with and > without HW crypto? > That might give a clue about what the hardware is sending for extra data.
How do I access the full packets? I tried using another machine with "iwconfig wlan0 mode monitor" and tcpdump. It captured many packets and I'm unable to identify the interesting ones.
-- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |