rt61pci/rt73usb: Hardware decryption IV/EIV

rt61pci/rt73usb: Hardware decryption IV/EIV

[Ivo van Doorn]

Hi,

I am working on the Hardware encryption/decryption in rt61pci/rt73usb,
and I am currently hitting a wall on the IV/EIV part.

To make mac80211 I am inserting the IV/EIV data right after the ieee80211 header,
but as soon as I do that, all data frames magically disappear in mac80211.
Without the IV/EIV data the frames are getting through correctly (i.e. I can ping my AP)
And yes, I am setting the RX_FLAG_IV_STRIPPED flag when the IV is gone, and clear
it when the IV is present. :)

This is what is currently happening in the driver part:

1) If decryptor indicates a cipher was used during RX, assume decryption took place
2) read IV/EIV data from decriptor
3) set RX_FLAG_IV_STRIPPED
4) check decryption status and set RX_FLAG_DECRYPTED if decryption succeeded

After that the following happens in rt2x00pci:
		iv_len = ((!!rxdesc.iv) * 4) + ((!!rxdesc.eiv) * 4);

		if (1 && (rxdesc.flags & RX_FLAG_IV_STRIPPED) && iv_len) {
			skb_put(entry->skb, rxdesc.size + iv_len);
			/* Copy ieee80211 header */
			memcpy(entry->skb->data, priv_rx->data, header_size);
			/* Copy IV/EIV data */
			if (iv_len >= 4)
				memcpy(entry->skb->data + header_size,
				       &rxdesc.iv, 4);
			if (iv_len >= 8)
				memcpy(entry->skb->data + header_size + 4,
				       &rxdesc.eiv, 4);
			/* Copy payload */
			memcpy(entry->skb->data + header_size + iv_len,
			       priv_rx->data + header_size,
			       rxdesc.size - header_size);
			/* Update frame length to include IV/EIV */
			rxdesc.size += iv_len;
			rxdesc.flags &= ~RX_FLAG_IV_STRIPPED;
		}

But when this code runs, the frame will somewhere disappear in mac80211.
I noticed that when I didn't insert the IV into the frame the debugfs counter
rx_handlers_drop remains relatively low (max 5 after a minute or so).
But when the IV is inserted this counter starts counting up with a speed
that might patch the number of pings I am sending out. (note that ping never
returns any results, not even a timeout).

After adding tons of debuglines in the RX path in mac80211 I find the following:

ieee80211_data_to_8023(struct ieee80211_rx_data *rx)
{
	<snip>
	case IEEE80211_FCTL_FROMDS:
		/* DA BSSID SA */
		memcpy(dst, hdr->addr1, ETH_ALEN);
		memcpy(src, hdr->addr3, ETH_ALEN);

		if (sdata->vif.type != IEEE80211_IF_TYPE_STA ||
		    (is_multicast_ether_addr(dst) &&
		     !compare_ether_addr(src, dev->dev_addr)))
			return -1;
		break;
	<snip>
}

The increase of the rx_handlers_drop counter is caused by this if statement,
printing out the frames for which the IV was inserted, and which frames were
dropped here, I get the following:

 PRE: 00:0c:f6:1e:43:4c 00:16:b6:12:5e:5c
 PRE: ff:ff:ff:ff:ff:ff 00:0c:f6:1e:43:4c
 wlan3: dropped FromDS frame (DST=ff:ff:ff:ff:ff:ff SRC=00:0c:f6:1e:43:4c)
 PRE: 00:0c:f6:1e:43:4c 00:16:b6:12:5e:5c
 PRE: ff:ff:ff:ff:ff:ff 00:0c:f6:1e:43:4c
 wlan3: dropped FromDS frame (DST=ff:ff:ff:ff:ff:ff SRC=00:0c:f6:1e:43:4c)
 PRE: 00:0c:f6:1e:43:4c 00:16:b6:12:5e:5c
 PRE: ff:ff:ff:ff:ff:ff 00:0c:f6:1e:43:4c
 wlan3: dropped FromDS frame (DST=ff:ff:ff:ff:ff:ff SRC=00:0c:f6:1e:43:4c)
 PRE: 00:0c:f6:1e:43:4c 00:16:b6:12:5e:5c
 PRE: ff:ff:ff:ff:ff:ff 00:0c:f6:1e:43:4c
 wlan3: dropped FromDS frame (DST=ff:ff:ff:ff:ff:ff SRC=00:0c:f6:1e:43:4c)
 PRE: 00:0c:f6:1e:43:4c 00:16:b6:12:5e:5c
 PRE: ff:ff:ff:ff:ff:ff 00:0c:f6:1e:43:4c
 wlan3: dropped FromDS frame (DST=ff:ff:ff:ff:ff:ff SRC=00:0c:f6:1e:43:4c)

All lines prefixed with "PRE" are printed in rt2x00 for each frame for which
the IV/EIV data was inserted, and the lines prefixed with "wlan3" are the
frames which were dropped in ieee80211_data_to_8023().

So now I am stuck, I see that the frames are dropped for a reason, and
obviously those are not the frames part of the ping. But I think it is very
strange these frames only show up when the IV/EIV data is being inserted.

Does anybody have any hint on where I should start looking about where
these frames come from, or what the cause might be of the disappearing frames?

Thanks,

Ivo

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Johannes Berg]

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


> Does anybody have any hint on where I should start looking about where
> these frames come from, or what the cause might be of the disappearing frames?

What are the protection bits in the header? I'd have to look at the key
selection code again I think. What about the ICV, are you adding that
too at the end?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Ivo van Doorn]

On Friday 02 May 2008, Johannes Berg wrote:
> 
> > Does anybody have any hint on where I should start looking about where
> > these frames come from, or what the cause might be of the disappearing frames?
> 
> What are the protection bits in the header? I'd have to look at the key
> selection code again I think. What about the ICV, are you adding that
> too at the end?

Now there you mention something. Looking at the Legacy driver, they only mention
ICV during the TX, but never during RX. I did find that the MMIC is appended at the
end of the frame, which is good, but they never do anything that looks like the
stripping of the ICV data...
So I assume it is stripped in the hardware, but no descriptor definition indicates
a ICV field like there is for IV and EIV. Unless.... they do have a 32bits "reserved" field
located directly after the IV/EIV fields.. makes one curious if that accidently contains ICV data. ;)

I'll add some debugging to dump more information about the header,
and what the contents is of that reserved field.

Thanks :)

Ivo

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Johannes Berg]

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


> Now there you mention something. Looking at the Legacy driver, they only mention
> ICV during the TX, but never during RX. I did find that the MMIC is appended at the
> end of the frame, which is good, but they never do anything that looks like the
> stripping of the ICV data...
> So I assume it is stripped in the hardware, but no descriptor definition indicates
> a ICV field like there is for IV and EIV. Unless.... they do have a 32bits "reserved" field
> located directly after the IV/EIV fields.. makes one curious if that accidently contains ICV data. ;)

Heh. Maybe the hardware actually does replay protection so it doesn't
matter?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Ivo van Doorn]

On Friday 02 May 2008, Johannes Berg wrote:
> 
> > Now there you mention something. Looking at the Legacy driver, they only mention
> > ICV during the TX, but never during RX. I did find that the MMIC is appended at the
> > end of the frame, which is good, but they never do anything that looks like the
> > stripping of the ICV data...
> > So I assume it is stripped in the hardware, but no descriptor definition indicates
> > a ICV field like there is for IV and EIV. Unless.... they do have a 32bits "reserved" field
> > located directly after the IV/EIV fields.. makes one curious if that accidently contains ICV data. ;)
> 
> Heh. Maybe the hardware actually does replay protection so it doesn't
> matter?

The comments in the legacy driver indicates the IV/EIV data was provided for replay attack checking,
and I do see a lot of ReplayCounters being memcpy'ed and memcmp() in the driver.
What is missing is the intialization of those counters to anything other then 0, and
the actual usage of the IV/EIV data in the Rx descriptor. ;)

Ivo

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Johannes Berg]

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

On Fri, 2008-05-02 at 22:59 +0200, Ivo van Doorn wrote:
> On Friday 02 May 2008, Johannes Berg wrote:
> > 
> > > Now there you mention something. Looking at the Legacy driver, they only mention
> > > ICV during the TX, but never during RX. I did find that the MMIC is appended at the
> > > end of the frame, which is good, but they never do anything that looks like the
> > > stripping of the ICV data...
> > > So I assume it is stripped in the hardware, but no descriptor definition indicates
> > > a ICV field like there is for IV and EIV. Unless.... they do have a 32bits "reserved" field
> > > located directly after the IV/EIV fields.. makes one curious if that accidently contains ICV data. ;)
> > 
> > Heh. Maybe the hardware actually does replay protection so it doesn't
> > matter?
> 
> The comments in the legacy driver indicates the IV/EIV data was provided for replay attack checking,
> and I do see a lot of ReplayCounters being memcpy'ed and memcmp() in the driver.
> What is missing is the intialization of those counters to anything other then 0, and
> the actual usage of the IV/EIV data in the Rx descriptor. ;)

Heh. Actually, yes, if the device does ICV checking then replay
detection can be easily done in software w/o the ICV, but mac80211
doesn't support that. You could probably just implement it in the driver
though.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Ivo van Doorn]

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

On Friday 02 May 2008, Johannes Berg wrote:
> On Fri, 2008-05-02 at 22:59 +0200, Ivo van Doorn wrote:
> > On Friday 02 May 2008, Johannes Berg wrote:
> > > 
> > > > Now there you mention something. Looking at the Legacy driver, they only mention
> > > > ICV during the TX, but never during RX. I did find that the MMIC is appended at the
> > > > end of the frame, which is good, but they never do anything that looks like the
> > > > stripping of the ICV data...
> > > > So I assume it is stripped in the hardware, but no descriptor definition indicates
> > > > a ICV field like there is for IV and EIV. Unless.... they do have a 32bits "reserved" field
> > > > located directly after the IV/EIV fields.. makes one curious if that accidently contains ICV data. ;)
> > > 
> > > Heh. Maybe the hardware actually does replay protection so it doesn't
> > > matter?
> > 
> > The comments in the legacy driver indicates the IV/EIV data was provided for replay attack checking,
> > and I do see a lot of ReplayCounters being memcpy'ed and memcmp() in the driver.
> > What is missing is the intialization of those counters to anything other then 0, and
> > the actual usage of the IV/EIV data in the Rx descriptor. ;)
> 
> Heh. Actually, yes, if the device does ICV checking then replay
> detection can be easily done in software w/o the ICV, but mac80211
> doesn't support that. You could probably just implement it in the driver
> though.

Well the ICV is checked in the hardware,
the hardware has the following RX status messages:
	RX_CRYPTO_SUCCESS = 0,
	RX_CRYPTO_FAIL_ICV = 1,
	RX_CRYPTO_FAIL_MIC = 2,
	RX_CRYPTO_FAIL_KEY = 3,

I have added the following debugline to rt2x00 for all frames which the insert IV routine is running:
			printk(KERN_DEBUG "RX: fc: %04x, sc: %04x, a1: %s, a2: %s, a3: %s\n",
				hdr->frame_control, hdr->seq_ctrl,
				print_mac(addr1, hdr->addr1),
				print_mac(addr2, hdr->addr2),
				print_mac(addr3, hdr->addr3));

*however* with the "reserved" descriptor field added to the tail of the frame,
made the device come to live again. The rx_handlers_drop counter now stays at the
usual level of 3, and pings are getting through.
I haven't checked if the descriptor field actually contains any data, but then again
mac80211 doesn't check the value either (with WEP anyway). ;)
So either the descriptor field is indeed the ICV,
or just appending 4 random bytes at the end of the frame did the trick.
Somehow I think the second idea has the highest probability. :S

Ivo

[-- Attachment #2: log --]
[-- Type: text/plain, Size: 10267 bytes --]

May  2 23:07:27 localhost RX: fc: 4208, sc: 6f50, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:29 localhost RX: fc: 4208, sc: 70e0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:0e:a6:7f:0b:56
May  2 23:07:31 localhost RX: fc: 4208, sc: 7330, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:31 localhost RX: fc: 4208, sc: 73d0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:31 localhost RX: fc: 4208, sc: 7410, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:31 localhost RX: fc: 4208, sc: 7420, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:31 localhost RX: fc: 4208, sc: 7550, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:31 localhost RX: fc: 4208, sc: 7580, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:31 localhost RX: fc: 4208, sc: 75b0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 79a0, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 79b0, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 79c0, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 79d0, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 79e0, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 79f0, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 7a00, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 7a10, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 7a20, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:35 localhost RX: fc: 4208, sc: 7a30, a1: 01:00:5e:7f:ff:fa, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:37 localhost RX: fc: 4208, sc: 7b80, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:37 localhost RX: fc: 4208, sc: 7b90, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:37 localhost RX: fc: 4208, sc: 7ba0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:37 localhost RX: fc: 4208, sc: 7bb0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:37 localhost RX: fc: 4208, sc: 7bc0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:37 localhost RX: fc: 4208, sc: 7bd0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:38 localhost RX: fc: 4208, sc: 7ca0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:38 localhost RX: fc: 4208, sc: 7cb0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:38 localhost RX: fc: 4208, sc: 7cc0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:38 localhost RX: fc: 4208, sc: 7cd0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:39 localhost RX: fc: 4208, sc: 7d90, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:39 localhost RX: fc: 4208, sc: 7da0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:39 localhost RX: fc: 4208, sc: 7db0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:39 localhost RX: fc: 4208, sc: 7dc0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 80a0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 80d0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 80f0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 8100, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 8110, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 81f0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 8200, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:40 localhost RX: fc: 4208, sc: 8210, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:41 localhost RX: fc: 4208, sc: 8390, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:41 localhost RX: fc: 4208, sc: 83b0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:41 localhost RX: fc: 4208, sc: 8430, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:41 localhost RX: fc: 4208, sc: 8440, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:41 localhost RX: fc: 4208, sc: 8460, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:41 localhost RX: fc: 4208, sc: 8480, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:42 localhost RX: fc: 4208, sc: 86e0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:42 localhost RX: fc: 4208, sc: 86f0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:42 localhost RX: fc: 4208, sc: 8700, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:42 localhost RX: fc: 4208, sc: 8710, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:43 localhost RX: fc: 4208, sc: 87c0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:43 localhost RX: fc: 4208, sc: 87d0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:43 localhost RX: fc: 4208, sc: 87e0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:43 localhost RX: fc: 4208, sc: 87f0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:48 localhost RX: fc: 4208, sc: 8c60, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:53 localhost RX: fc: 4208, sc: 8f90, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:53 localhost RX: fc: 4208, sc: 8fa0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:53 localhost RX: fc: 4208, sc: 8fb0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:53 localhost RX: fc: 4208, sc: 8fc0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:53 localhost RX: fc: 4208, sc: 8fd0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:54 localhost RX: fc: 4208, sc: 9090, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:54 localhost RX: fc: 4208, sc: 90a0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:54 localhost RX: fc: 4208, sc: 90b0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:54 localhost RX: fc: 4208, sc: 90c0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:55 localhost RX: fc: 4208, sc: 9170, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:55 localhost RX: fc: 4208, sc: 9180, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:55 localhost RX: fc: 4208, sc: 9190, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:55 localhost RX: fc: 4208, sc: 91a0, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:56 localhost RX: fc: 4208, sc: 9250, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:56 localhost RX: fc: 4208, sc: 9260, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:56 localhost RX: fc: 4208, sc: 9280, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:56 localhost RX: fc: 4208, sc: 9290, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:57 localhost RX: fc: 4208, sc: 9330, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:57 localhost RX: fc: 4208, sc: 9340, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:57 localhost RX: fc: 4208, sc: 9350, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:57 localhost RX: fc: 4208, sc: 9360, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:58 localhost RX: fc: 4208, sc: 9410, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:58 localhost RX: fc: 4208, sc: 9420, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:58 localhost RX: fc: 4208, sc: 9430, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:58 localhost RX: fc: 4208, sc: 9440, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:59 localhost RX: fc: 4208, sc: 94f0, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:59 localhost RX: fc: 4208, sc: 9500, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:59 localhost RX: fc: 4208, sc: 9510, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:07:59 localhost RX: fc: 4208, sc: 9520, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:08:04 localhost RX: fc: 4208, sc: 9840, a1: ff:ff:ff:ff:ff:ff, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c
May  2 23:08:09 localhost RX: fc: 4208, sc: 9b60, a1: 00:0c:f6:1e:43:4c, a2: 00:16:b6:12:5e:5c, a3: 00:16:b6:12:5e:5c 

Re: rt61pci/rt73usb: Hardware decryption IV/EIV

[Ivo van Doorn]

> *however* with the "reserved" descriptor field added to the tail of the frame,
> made the device come to live again. The rx_handlers_drop counter now stays at the
> usual level of 3, and pings are getting through.
> I haven't checked if the descriptor field actually contains any data, but then again
> mac80211 doesn't check the value either (with WEP anyway). ;)
> So either the descriptor field is indeed the ICV,
> or just appending 4 random bytes at the end of the frame did the trick.
> Somehow I think the second idea has the highest probability. :S

Hmm, looking at the data coming from the hardware,
one would really think the third column looks random enough
to have something to do with encryption. ;)

RX: 00744ef3 00000000 511beb8f
RX: 00bc6056 00000000 9ba5d723
RX: 00384c30 00000000 32f2d121
RX: 00a57027 00000000 9278a11c
RX: 008ff83d 00000000 8f9cd735
RX: 00c4d0a6 00000000 efa740b8
RX: 00dbe43e 00000000 0383ed8d
RX: 00d3b2cd 00000000 367d1648
RX: 00029e40 00000000 de4c3589
RX: 00a1cea7 00000000 825a88cc
RX: 006d325c 00000000 e1f7be5d
RX: 00ca0a8b 00000000 32165233
RX: 003a6811 00000000 635ab7db
RX: 00c7224c 00000000 9d19d071
RX: 009992c5 00000000 577bc5e3
RX: 0059da01 00000000 c2a4e66e
RX: 00ff7459 00000000 f3c6e38b
RX: 00d1b68f 00000000 511beb8f
RX: 00073a8a 00000000 e1f7be5d

Ivo