On Thu, 2006-11-16 at 09:21 -0800, Jouni Malinen wrote: > Hmm.. I think I need to see the patch for doing this before being able > to decide whether I'd like this or not.. Michael MIC is a bit > unfortunate design since it happens at MSDU, not MPDU level. Because of > this, most hardware designs have to do something special when > fragmentation is used. If the fragmentation is done in the stack, it may > be difficult to move the Michael MIC operations into the driver since > they need to happen before fragmentation (which would be done in the > stack in this case)..
Oh, good point. Will need to think about this more. But right now, if that MMIC flag is set (i.e. hw does MMIC), we still do MMIC for fragmented frames. And there's actually a bug here I think: if hw does MMIC, how can the driver tell not to do it on those frames it's getting as fragments? > Other than this special case, it sounds reasonable to keep most of the > small hardware design changes hidden in the driver code as long as the > functions that are exported from the stack are the same ones that the > stack would be using anyway (i.e., not having to maintain two versions > of the same code). Of course, for this TKIP stuff I'd only export those functions the drivers will need and remove the flags, for software crypto (in stack) they'd still be used as-is. johannes
signature.asc
Description: This is a digitally signed message part
