Search Linux Wireless

Re:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
> Hi Felix,
> 
> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <nbd@xxxxxxxxxxx> 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
>>>> <shafi.wireless@xxxxxxxxx> wrote:
>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@xxxxxxxxx> 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;
         /*

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux