On Mon, 2011-04-11 at 18:16 +0200, Christian Lamparter wrote:
> > > + if (!ieee80211_has_protected(hdr->frame_control) ||
> > > + !ieee80211_is_data_present(hdr->frame_control)) {
> > > + return RX_CONTINUE;
> > > + }
> >
> > 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?
>
> OnT: It looks like this patch might also help to relieve ath9k & ath9k_htc of
> some workarounds. see: 56363ddeeed "ath9k: fix spurious MIC failure reports".
> (ath5k seems to be fine though?!)
Yeah, it looks like if we do it in the TKIP path we could revert that.
> BTW: what to do about this?
> - if (rx->sdata->vif.type == NL80211_IFTYPE_AP && keyidx) {
> - /*
> - * APs with pairwise keys should never receive Michael MIC
> - * errors for non-zero keyidx because these are reserved for
> - * group keys and only the AP is sending real multicast
> - * frames in the BSS.
> - */
> - return; [Drop Unusable]
> - }
> for now, I've kept the code. But I'm not quite sure why, at least
> I couldn't find the passage in the spec that says "GTK MIC failures in AP mode
> can be ignored" [Although, 8.5.1 (see "196 hole")& 8.3.2.3 (last sentence)
> hint in this direction]?
Well, hmm? APs never receive anything with a key that has a non-zero at
all, since pairwise keys have key index 0 and group keys are never used
for RX.
Also, I think we should run some actual TKIP testing :-)
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
