rt61pci/rt73usb: Hardware decryption IV/EIV
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
Quoted 3 lines
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
Quoted 7 lines · Johannes Berg
Quoted 3 lines
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
Quoted 8 lines
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
Quoted 11 lines · Johannes Berg
Quoted 8 lines
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
Quoted 10 lines · Ivo van Doorn
Quoted 9 lines · Johannes Berg
Quoted 8 lines
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. ;)
Quoted 7 lines
Quoted 2 lines
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
Quoted 19 lines · Johannes Berg
Quoted 10 lines · Ivo van Doorn
Quoted 9 lines · Johannes Berg
Quoted 8 lines
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. ;)Quoted 7 lines
Quoted 2 lines
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. ;)
Quoted 4 lines
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
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
Quoted 8 lines
*however* with the "reserved" descriptor field added to the tail of the frame, made the device come to live again. The
rx_handlers_dropcounter 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