On Sat, 2011-04-09 at 12:34 +0200, Christian Lamparter wrote:
> Currently, mac80211 handles MIC failures differently
> depending on whenever they are detected by the stack's
> own software crypto or when are handed down from the
> driver.
>
> This patch tries to unify both by moving the special
> "driver" branch out of mac80211 rx hotpath and into
> into the software crypto part. This has also the
> advantage that we can run a few more sanity checks
> on the data and verify of example that the key type
> was indeed TKIP.
In principle that seems fine with me.
> BTW: why does the "driver" path check for _auth frames?
I have no idea, seems pointless.
> diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
> index f1765de..a2c18b6 100644
> --- a/net/mac80211/wpa.c
> +++ b/net/mac80211/wpa.c
> @@ -87,33 +87,35 @@ ieee80211_rx_h_michael_mic_verify(struct ieee80211_rx_data *rx)
> struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
>
> + if (!ieee80211_has_protected(hdr->frame_control) ||
> + !ieee80211_is_data_present(hdr->frame_control)) {
> + return RX_CONTINUE;
> + }
No braces necessary. But is this check correct? What if the driver
_completely_ pretends that the frame wasn't encrypted? Do we strictly
require that it leaves the protected bit set?
johannes
--
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
