ieee80211 and devices which decrypt in hardware

ieee80211 and devices which decrypt in hardware

[Daniel Drake]

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 normal structure of a WEP-encrypted frame is:

1. 802.11 header (including WEP bit)
2. IV (4 bytes)
3. Encrypted data

The structure of a frame coming from the zd1211 device where the frame 
has been decrypted in hardware is:

1. 802.11 header (including WEP bit)
2. IV (4 bytes)
3. Decrypted data

We pass this up to ieee80211_rx as usual, but things don't work right. 
ieee80211 converts the frame to an ethernet frame as usual, but includes 
the WEP IV as the first 4 bytes of the data. (Instead, I want it to skip 
over the IV, successful decryption has already been verified)

This is easy enough to fix with another ieee80211 flag or something like 
that, but I am wondering why it already works for existing drivers which 
decrypt in hardware. When doing hardware decryption, does the Intel 
hardware really cut out the 4 byte IV and shift the rest of the data so 
that it continues immediately on from the header? Seems like a 
complicated operation to do in hardware (although I don't really know 
much about hw design...)

Daniel

Re: ieee80211 and devices which decrypt in hardware

[Michael Buesch]

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 confirm how the Intel hardware behaves here that would be useful...
> 
> The normal structure of a WEP-encrypted frame is:
> 
> 1. 802.11 header (including WEP bit)
> 2. IV (4 bytes)
> 3. Encrypted data
4. ICV
5. FCS

> The structure of a frame coming from the zd1211 device where the frame 
> has been decrypted in hardware is:
> 
> 1. 802.11 header (including WEP bit)
> 2. IV (4 bytes)
> 3. Decrypted data

Does it strip ICV and FCS?

> We pass this up to ieee80211_rx as usual, but things don't work right. 
> ieee80211 converts the frame to an ethernet frame as usual, but includes 
> the WEP IV as the first 4 bytes of the data. (Instead, I want it to skip 
> over the IV, successful decryption has already been verified)
> 
> This is easy enough to fix with another ieee80211 flag or something like 
> that, but I am wondering why it already works for existing drivers which 
> decrypt in hardware. When doing hardware decryption, does the Intel 
> hardware really cut out the 4 byte IV and shift the rest of the data so 
> that it continues immediately on from the header? Seems like a 
> complicated operation to do in hardware (although I don't really know 
> much about hw design...)

in bcm43xx-softmac we use memmove to move the wireless header 4 bytes
up and after that strip the first 4 bytes of the skb.
I don't think there is another easy way to handle this. You'd have
to modify the stack and softmac. And this would probably result in more
overhead than the simple memove of 24 bytes.

-- 
Greetings Michael.

Re: ieee80211 and devices which decrypt in hardware

[Daniel Drake]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

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 move the wireless header 4 bytes
> up and after that strip the first 4 bytes of the skb.
> I don't think there is another easy way to handle this. You'd have
> to modify the stack and softmac. And this would probably result in more
> overhead than the simple memove of 24 bytes.

softmac doesn't need modifying, and the ieee80211 modification is very 
simple. See the attached patch. ieee80211 could also be modified very 
easily to drop the ICV.

Surely this is nicer than adding IEEE802.11 header parsing code to 
zd1211rw rx path (currently there is none, which is nice) and a memmove?

Daniel


[-- Attachment #2: ieee80211-rx-strip-iv.patch --]
[-- Type: text/x-patch, Size: 553 bytes --]

Index: linux/net/ieee80211/ieee80211_rx.c
===================================================================
--- linux.orig/net/ieee80211/ieee80211_rx.c
+++ linux/net/ieee80211/ieee80211_rx.c
@@ -655,6 +655,11 @@ int ieee80211_rx(struct ieee80211_device
 		goto rx_dropped;
 	}
 
+	/* 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;
+
 	/* skb: hdr + (possible reassembled) full plaintext payload */
 
 	payload = skb->data + hdrlen;

Re: ieee80211 and devices which decrypt in hardware

[Daniel Drake]

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, special value for ieee->host_decrypt, etc.

Daniel

Re: ieee80211 and devices which decrypt in hardware

[Johannes Berg]

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 there are devices that leave the protected bit
set but do strip the IV/ICV...

johannes

Re: ieee80211 and devices which decrypt in hardware

[Michael Buesch]

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 we should also 
> handle that.

You should skb_trim it, or otherwise it will be included in the
payload, which will result in various weird bugs.

-- 
Greetings Michael.