Commit f3d340c1 authored by Ivo van Doorn's avatar Ivo van Doorn Committed by John W. Linville

Fix rt2500usb HW crypto: TKIP

rt2500usb doesn't strip the IV/ICV data from received frames,
so we don't need to set the RX_FLAG_IV_STRIPPED flag.
We do need to set the RX_FLAG_MMIC_STRIPPED flag for all
encryption types since the MMIC has been removed from the frame.

After this patch TKIP Hardware crypto works for rt2500usb.
WEP and AES are still failing.
Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
parent b55eae33
......@@ -376,11 +376,11 @@ static int rt2500usb_config_key(struct rt2x00_dev *rt2x00dev,
/*
* The driver does not support the IV/EIV generation
* in hardware. However it doesn't support the IV/EIV
* inside the ieee80211 frame either, but requires it
* to be provided seperately for the descriptor.
* rt2x00lib will cut the IV/EIV data out of all frames
* given to us by mac80211, but we must tell mac80211
* in hardware. However it demands the data to be provided
* both seperately as well as inside the frame.
* We already provided the CONFIG_CRYPTO_COPY_IV to rt2x00lib
* to ensure rt2x00lib will not strip the data from the
* frame after the copy, now we must tell mac80211
* to generate the IV/EIV data.
*/
key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
......@@ -1334,13 +1334,6 @@ static void rt2500usb_fill_rxdone(struct queue_entry *entry,
/* ICV is located at the end of frame */
/*
* Hardware has stripped IV/EIV data from 802.11 frame during
* decryption. It has provided the data seperately but rt2x00lib
* should decide if it should be reinserted.
*/
rxdesc->flags |= RX_FLAG_IV_STRIPPED;
if (rxdesc->cipher != CIPHER_TKIP)
rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
rxdesc->flags |= RX_FLAG_DECRYPTED;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment