From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756232Ab0CXNYH (ORCPT ); Wed, 24 Mar 2010 09:24:07 -0400 Received: from mail-bw0-f209.google.com ([209.85.218.209]:43560 "EHLO mail-bw0-f209.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756212Ab0CXNYE convert rfc822-to-8bit (ORCPT ); Wed, 24 Mar 2010 09:24:04 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WHbFDkGrO/0AyTshq4htAxl05b60HqtZs1Cq5Zx7Pi5UUsECuslR+Aazzm4aAK5lv0 d1C0N/mGWyjAzzNRKBG47VEjOel5S6lNm0GL01weDAFLB7rC4y8ltiXtlkU64t7FS1Xr nFBzVa4QNOyjwGOUFJCTeX3rqM0b2YzozLwbY= MIME-Version: 1.0 In-Reply-To: <201003241412.38128.linux@rainbow-software.org> References: <201003221601.36559.linux@rainbow-software.org> <201003231609.57505.linux@rainbow-software.org> <201003241412.38128.linux@rainbow-software.org> Date: Wed, 24 Mar 2010 14:24:00 +0100 Message-ID: Subject: Re: [rt2x00-users] [PATCH RFC] rt2500usb: disable broken HW encryption by default From: Ivo Van Doorn To: Ondrej Zary Cc: rt2x00 Users List , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 24, 2010 at 2:12 PM, Ondrej Zary wrote: > On Tuesday 23 March 2010, Ivo Van Doorn wrote: >> On Tue, Mar 23, 2010 at 4:09 PM, Ondrej Zary > wrote: >> > On Tuesday 23 March 2010, Ivo Van Doorn wrote: >> >> On Tue, Mar 23, 2010 at 10:27 AM, Ondrej Zary >> >> >> >> 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. Ivo