Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default

[Ondrej Zary <linux@rainbow-software.org>]

On Wednesday 24 March 2010, Ondrej Zary wrote:
> On Wednesday 24 March 2010, Ivo Van Doorn wrote:
> > On Wed, Mar 24, 2010 at 2:12 PM, Ondrej Zary <linux@rainbow-software.org>
>
> wrote:
> > > 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.
> >
> > You won't get the useful stuff from monitor mode.
> > You have to enable rt2x00 debugfs support, to find a framedump file in
> > the rt2x00 debugfs folder.
> >
> > You should use the framedump tool from:
> > http://kernel.org/pub/linux/kernel/people/ivd/tools/
> >
> > To get the frame dumps in nicely formatted lines for analysis.
>
> Thanks, here are the dump files:
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt
>
> I don't know how wifi encryption works so I don't know what to look for.

Some more news. Tested with another AP (Asus WL-300g with DD-WRT) with various 
WPA2 settings (TKIP, AES, TKIP+AES). TKIP works. AES works. TKIP+AES does 
not.

-- 
Ondrej Zary