提交 f3d340c1 编写于 作者: I Ivo van Doorn 提交者: 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: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
上级 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,14 +1334,7 @@ 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;
rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
rxdesc->flags |= RX_FLAG_DECRYPTED;
else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册