Return-path: Received: from nbd.name ([46.4.11.11]:47100 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755735Ab2BBM2n (ORCPT ); Thu, 2 Feb 2012 07:28:43 -0500 Message-ID: <4F2A8173.7050603@openwrt.org> (sfid-20120202_132846_851087_34D79569) Date: Thu, 02 Feb 2012 13:28:35 +0100 From: Felix Fietkau MIME-Version: 1.0 To: Mohammed Shafi CC: "John W. Linville" , Laurent Bonnans , linux-wireless@vger.kernel.org Subject: Re: References: <20120201162730.GA29685@tuxdriver.com> <4F2970B3.4090203@openwrt.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 2012-02-02 6:37 AM, Mohammed Shafi wrote: > Hi Felix, > > On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau wrote: >> On 2012-02-01 5:27 PM, John W. Linville wrote: >>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote: >>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi >>>> wrote: >>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans wrote: >>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on >>>> >> some APs on my laptop with an AR9285 Wireless card. >>>> >> >>>> >> dhcp works fine on an open wifi network but receives no response on a >>>> >> wep network I use. I haven't been able to test it on a third network >>>> >> for now. >>>> > >>>> > reverting "ath9k_hw: fix interpretation of the rx KeyMiss flag" does >>>> > helps. i need to analyze >>>> > if it exposes some real issue which need to be fixed. >>>> > >>>> >>>> this seems to be a problem in WEP alone, where the key miss is always >>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to >>>> decrypt, but fails due to ICV mismatch. >>> >>> OK...any way to differentiate this case at that point in the code? >>> >>> John >> Please try this patch: >> >> --- >> --- a/drivers/net/wireless/ath/ath9k/recv.c >> +++ b/drivers/net/wireless/ath/ath9k/recv.c >> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c >> (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC | >> ATH9K_RXERR_KEYMISS)); >> >> + /* >> + * First 4 slots are reserved for WEP, and for packets using them, >> + * ATH9K_RXERR_KEYMISS can be reported even though decryption was >> + * successful, since no MAC address based key cache lookup was >> + * performed. >> + */ >> + if (rx_stats->rs_keyix < 4) >> + rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS; >> + >> if (!rx_stats->rs_datalen) >> return false; >> /* > > > unfortunately as the rx_keyix is always 'INVALID' (as obtained from > the descriptor) this check does not seems to help You're right. I read up on what the other codebases do here, and I have a better patch here: --- a/drivers/net/wireless/ath/ath9k/recv.c +++ b/drivers/net/wireless/ath/ath9k/recv.c @@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC | ATH9K_RXERR_KEYMISS)); + /* + * Key miss events are only relevant for pairwise keys where the + * descriptor does contain a valid key index. This has been observed + * mostly with CCMP encryption. + */ + if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID) + rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS; + if (!rx_stats->rs_datalen) return false; /*