[rt2x00-users] rt2800usb: Michael MIC failure?
Gertjan van Wingerde
gwingerde at gmail.com
Sat Jan 22 10:41:42 EST 2011
On 01/21/11 16:53, Helmut Schaa wrote:
> Am Freitag, 21. Januar 2011 schrieb Johannes Stezenbach:
>> On Fri, Jan 21, 2011 at 12:24:37PM +0100, Johannes Stezenbach wrote:
>>> On Thu, Jan 20, 2011 at 09:52:38PM +0100, Gertjan van Wingerde wrote:
>>>> On 20 jan. 2011, at 19:35, Johannes Stezenbach <js at sig21.net> wrote:
>>>>> On Thu, Jan 20, 2011 at 06:20:11PM +0100, Helmut Schaa wrote:
>>>>>> Try disabling hw_crypto?
>>>>> I should've thought about this my self... will try tomorrow.
>>>> This is indeed a "known" problem with the hwcrypt implementation of rt2800
>>>> (both usb and pci).
>>>> I have checked for the obvious issues in programming the hw registers with
>>>> the key information, but haven't found anything yet.
>>> OK. FWIW, I just tested with nohwcrypt=1 and it works.
>> After some debugging, it seems the hardware reports
>> RX_CRYPTO_SUCCESS status but mac80211 generates the error.
>> The following change fixes it, but since I've no idea
>> about the crypto stuff I thought I'd ask before spending time
>> to create a proper patch. If this change is correct, rt2800pci
>> likely has the same issue.
>> @@ -552,7 +554,7 @@ static void rt2800usb_fill_rxdone(struct queue_entry *entry,
>> * any fields with the EIV/IV data either, so they can't
>> * be restored by rt2x00lib.
>> - rxdesc->flags |= RX_FLAG_IV_STRIPPED;
>> + rxdesc->flags |= RX_FLAG_IV_STRIPPED | RX_FLAG_MMIC_STRIPPED;
>> if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
>> rxdesc->flags |= RX_FLAG_DECRYPTED;
>> The legacy driver has a function STACheckTkipMICValue() which checks the
>> MIC on Rx frames, but it seems it is only called for fragmented frames
>> which have RXD_W0_DECRYPTED unset. So I guess when RXD_W0_DECRYPTED
>> is set, the MMIC is stripped.
> Good catch. I haven't reviewed this but your description sounds feasible.
Good catch indeed. I checked this myself and this indeed fixes the problem.
We don't have to report the Michael MIC to mac80211 if we check it ourselves
(which is what the hardware does for us), so your approach is perfectly
I have created a patch that fixes this issue in the manner suggested by you
(with a comment as to why we don't have to report the Michael MIC) and will
submit it once this patch has been validated by the others that reported the
More information about the users