On Thursday 14 September 2006 00:35, Daniel Drake wrote:
> Michael Buesch wrote:
> > Does it strip ICV and FCS?
>
> The driver always strips FCS (unconditionally).
>
> The device does not strip ICV even when hardware decryption is in use,
> it gets included at the end of the frame, and I guess w
On Wed, 2006-09-13 at 18:35 -0400, Daniel Drake wrote:
> + /* If the device does decryption but leaves the IV in place then we:
> +* need to kill it. */:
> + if (!can_be_decrypted && (fc & IEEE80211_FCTL_PROTECTED)):
> + hdrlen += 4;:
That might work, unless
Daniel Drake wrote:
adding IEEE802.11 header parsing code to
zd1211rw rx path (currently there is none, which is nice)
Oops, that's obviously a lie. Anyway, I still think it's easier/better
to do in the stack, would you agree? That just leaves questions about
whether it should be a new flag,
Michael Buesch wrote:
Does it strip ICV and FCS?
The driver always strips FCS (unconditionally).
The device does not strip ICV even when hardware decryption is in use,
it gets included at the end of the frame, and I guess we should also
handle that.
in bcm43xx-softmac we use memmove to mo
On Wednesday 13 September 2006 04:51, Daniel Drake wrote:
> Hi,
>
> I'm working on support for hardware-based frame decryption in zd1211rw.
> While doing so I encountered some strange behaviour in ieee80211 which
> I'm wondering if someone can clarify. Alternatively if someone could
> just conf
Hi,
I'm working on support for hardware-based frame decryption in zd1211rw.
While doing so I encountered some strange behaviour in ieee80211 which
I'm wondering if someone can clarify. Alternatively if someone could
just confirm how the Intel hardware behaves here that would be useful...
The
