Using bcm43xx-softmac, my log gets full of messages that look like:
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected: STA=00:14:bf:85:49:fa
Are there any objections to the following patch to eliminate these messages from TKIP and CCMP?
Index: wireless-2.6/net/ieee80211/ieee80211_crypt_tkip.c
===================================================================
--- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_tkip.c
+++ wireless-2.6/net/ieee80211/ieee80211_crypt_tkip.c
@@ -439,11 +439,7 @@ static int ieee80211_tkip_decrypt(struct
pos = skb->data + hdr_len;
keyidx = pos[3];
if (!(keyidx & (1 << 5))) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG "TKIP: received packet without ExtIV"
- " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2));
- }
- return -2;
+ return -2; /* received packet without ExtIV */
}
keyidx >>= 6;
if (tkey->key_idx != keyidx) {
Index: wireless-2.6/net/ieee80211/ieee80211_crypt_ccmp.c
===================================================================
--- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_ccmp.c
+++ wireless-2.6/net/ieee80211/ieee80211_crypt_ccmp.c
@@ -306,11 +306,7 @@ static int ieee80211_ccmp_decrypt(struct
pos = skb->data + hdr_len;
keyidx = pos[3];
if (!(keyidx & (1 << 5))) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG "CCMP: received packet without ExtIV"
- " flag from " MAC_FMT "\n", MAC_ARG(hdr->addr2));
- }
- return -2;
+ return -2; /* received packet without ExtIV */
}
keyidx >>= 6;
Larry
On 07-04-06 21:33 Jouni Malinen wrote:
> I would expect most wlan designs to do FCS error filtering in hardware,
> so this could be just lack of configuring something differently or
> dropping frames based on one of the RX flags. If the exact mechanism for
> this is not known, I would recommend validating FCS in software prior to
> processing the its contents (or trying to decrypt it for that matter).
Just for clarification: ZD1211 does the FCS check in hardware, but
reports the packet to the host with an error bit set, so the
driver needs to filter the packet out.
--
Uli Kunitz
On Fri, Apr 06, 2007 at 06:53:34PM -0500, Larry Finger wrote:
> Using bcm43xx-softmac, my log gets full of messages that look like:
>
> Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected:
> STA=00:14:bf:85:49:fa
Does the driver properly filter out FCS errors? If not, the proper fix
is to fix the driver to do that. If yes, I'm quite surprised that you
see these messages so frequently.
> Are there any objections to the following patch to eliminate these messages
> from TKIP and CCMP?
Your patch is not changing this particular error that you showed.. Was
that on purpose? I would be okay with removing the ICV error message
since it has a separate counter, _assuming_ this can be shown to not be
caused by a driver that does not filter out FCS errors.
> Index: wireless-2.6/net/ieee80211/ieee80211_crypt_tkip.c
> ===================================================================
> --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_tkip.c
> +++ wireless-2.6/net/ieee80211/ieee80211_crypt_tkip.c
> @@ -439,11 +439,7 @@ static int ieee80211_tkip_decrypt(struct
> pos = skb->data + hdr_len;
> keyidx = pos[3];
> if (!(keyidx & (1 << 5))) {
> - if (net_ratelimit()) {
> - printk(KERN_DEBUG "TKIP: received packet without
> ExtIV"
> - " flag from " MAC_FMT "\n",
> MAC_ARG(hdr->addr2));
> - }
> - return -2;
> + return -2; /* received packet without ExtIV */
> }
Have you ever seen this message? I would be against this change unless
an error counter is added here. I do not remember anyone having
complained about this particular message, so I would just leave this
as-is.
> Index: wireless-2.6/net/ieee80211/ieee80211_crypt_ccmp.c
> @@ -306,11 +306,7 @@ static int ieee80211_ccmp_decrypt(struct
> pos = skb->data + hdr_len;
> keyidx = pos[3];
> if (!(keyidx & (1 << 5))) {
> - if (net_ratelimit()) {
> - printk(KERN_DEBUG "CCMP: received packet without
> ExtIV"
> - " flag from " MAC_FMT "\n",
> MAC_ARG(hdr->addr2));
> - }
> - return -2;
> + return -2; /* received packet without ExtIV */
Hmm.. This does not apply to the version I have (which actually has
dot11RSNAStatsCCMPFormatErrors counter here).. Without the counter, I
would be against removing this and even with the counter, I would not
remove this unless someone has actually reported this particular message
showing up in logs frequently.
So far, these messages in TKIP/CCMP have found number of issues in
various implementation doing things incorrectly and as such, I would not
recommend removing them unless they can clearly be showed to be causing
problems which cannot be fixed by doing a proper fix (e.g., FCS
validation, duplicate filtering, etc. at the driver level).
--
Jouni Malinen PGP id EFC895FA
On Sunday 08 April 2007 10:10, Johannes Berg wrote:
> On Fri, 2007-04-06 at 23:16 -0500, Larry Finger wrote:
>
> > As far as I can tell, FCS errors are not filtered.
>
> Actually, they are filtered by the firmware and never passed up to the
> driver unless you set the "rx invalid frames" bit in the mac control
> field. Since the driver never sets that except with some of the module
> parameters (or is that modparm bcm43xx-mac80211 only?) the FCS on all
> frames passed up should be fine.
FCS corrupted frames are always filtered in bcm43xx. There's a
hack module parameter to pass them up in monitor mode in bcm43xx-mac80211.
--
Greetings Michael.
On Fri, 2007-04-06 at 23:16 -0500, Larry Finger wrote:
> As far as I can tell, FCS errors are not filtered.
Actually, they are filtered by the firmware and never passed up to the
driver unless you set the "rx invalid frames" bit in the mac control
field. Since the driver never sets that except with some of the module
parameters (or is that modparm bcm43xx-mac80211 only?) the FCS on all
frames passed up should be fine.
johannes
Jouni Malinen wrote:
> On Fri, Apr 06, 2007 at 06:53:34PM -0500, Larry Finger wrote:
>> Using bcm43xx-softmac, my log gets full of messages that look like:
>>
>> Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected:
>> STA=00:14:bf:85:49:fa
>
> Does the driver properly filter out FCS errors? If not, the proper fix
> is to fix the driver to do that. If yes, I'm quite surprised that you
> see these messages so frequently.
According to Johannes Berg and Michael Buesch, the bcm43xx firmware filters the frames with FCS
errors before they even get to the driver. I'm still looking to see if I can find a way to filter
the offending packets further to keep them from getting to ieee80211.
Thanks,
Larry
Jouni Malinen wrote:
> On Fri, Apr 06, 2007 at 06:53:34PM -0500, Larry Finger wrote:
>> Using bcm43xx-softmac, my log gets full of messages that look like:
>>
>> Apr 6 18:06:55 larrylap kernel: TKIP: ICV error detected:
>> STA=00:14:bf:85:49:fa
>
> Does the driver properly filter out FCS errors? If not, the proper fix
> is to fix the driver to do that. If yes, I'm quite surprised that you
> see these messages so frequently.
As far as I can tell, FCS errors are not filtered. I looked at other wireless drivers, and I can see
where zd1211rw filters them, but I have not yet figured out what routine sets the error bits. Once I
have that and filter them, I'll see if the log messages stop.
Thanks for the advice,
Larry
On Fri, Apr 06, 2007 at 11:16:54PM -0500, Larry Finger wrote:
> As far as I can tell, FCS errors are not filtered. I looked at other
> wireless drivers, and I can see where zd1211rw filters them, but I have not
> yet figured out what routine sets the error bits. Once I have that and
> filter them, I'll see if the log messages stop.
OK, that would certainly explain large number of TKIP/CCMP errors. It is
quite normal to get packet error rate of 5-10% and FCS error detection
should take care of most of the incorrect frames that get through
without causing some other format error to reject them.
I would expect most wlan designs to do FCS error filtering in hardware,
so this could be just lack of configuring something differently or
dropping frames based on one of the RX flags. If the exact mechanism for
this is not known, I would recommend validating FCS in software prior to
processing the its contents (or trying to decrypt it for that matter).
--
Jouni Malinen PGP id EFC895FA