[PATCH] hush noisy ieee80211 CCMP printks

Don't swamp syslog with
CCMP: decrypt failed: STA=00:12:17:3a:e2:c7
and 
CCMP: replay detected: STA=00:12:17:3a:e2:c7 previous PN 000000000004 received PN 000000000004
messages.

These both seem to be completely normal in regular use, especially
'decrypt failed' whenever another wpa-using station on the same AP is
within range.

These events are still being counted in the statistics.

Signed-off-by: Jason Lunz <redacted>

---
 net/ieee80211/ieee80211_crypt_ccmp.c |   11 -----------
 1 file changed, 11 deletions(-)

Index: linux-2.6.17-rc5-git11/net/ieee80211/ieee80211_crypt_ccmp.c
===================================================================

--- linux-2.6.17-rc5-git11.orig/net/ieee80211/ieee80211_crypt_ccmp.c
+++ linux-2.6.17-rc5-git11/net/ieee80211/ieee80211_crypt_ccmp.c

@@ -326,13 +326,6 @@
 	pos += 8;
 
 	if (memcmp(pn, key->rx_pn, CCMP_PN_LEN) <= 0) {
-		if (net_ratelimit()) {
-			printk(KERN_DEBUG "CCMP: replay detected: STA=" MAC_FMT
-			       " previous PN %02x%02x%02x%02x%02x%02x "
-			       "received PN %02x%02x%02x%02x%02x%02x\n",
-			       MAC_ARG(hdr->addr2), MAC_ARG(key->rx_pn),
-			       MAC_ARG(pn));
-		}
 		key->dot11RSNAStatsCCMPReplays++;
 		return -4;
 	}

@@ -357,10 +350,6 @@
 	}
 
 	if (memcmp(mic, a, CCMP_MIC_LEN) != 0) {
-		if (net_ratelimit()) {
-			printk(KERN_DEBUG "CCMP: decrypt failed: STA="
-			       MAC_FMT "\n", MAC_ARG(hdr->addr2));
-		}
 		key->dot11RSNAStatsCCMPDecryptErrors++;
 		return -5;
 	}

On Sun, Jun 04, 2006 at 08:12:09PM -0400, Jason Lunz wrote:

Don't swamp syslog with
CCMP: decrypt failed: STA=00:12:17:3a:e2:c7
and 
CCMP: replay detected: STA=00:12:17:3a:e2:c7 previous PN 000000000004 received PN 000000000004
messages.

These both seem to be completely normal in regular use, especially
'decrypt failed' whenever another wpa-using station on the same AP is
within range.

These are not normal, i.e., they should not really show up unless
something goes wrong. In many cases, this may be caused by something
missing in local filtering (e.g., retry duplicates are not filtered out
correctly or messages to incorrect addresses are allowed through, etc.).
In other cases, it can indicate incorrect implementation of rekeying or
some other bugs in either end of the connection. Anyway, I don't have
anything against removing the messages in default kernel builds. If
there is a suitable build time debug option, that might be nicer way of
doing this, though, since these can provide valuable information when
figuring out why something does not work.

-- 
Jouni Malinen                                            PGP id EFC895FA

On Mon, Jun 05, 2006 at 06:31:48AM -0700, Jouni Malinen wrote:

These are not normal, i.e., they should not really show up unless
something goes wrong.

If these are a real problem, I'll gladly help debug it. I'm using
2.6.17-rc5's bcm43xx and the in-kernel ieee80211 softmac stack. I'm
using wpa/ccmp/aes with an openwrt AP.

In many cases, this may be caused by something missing in local
filtering (e.g., retry duplicates are not filtered out correctly or
messages to incorrect addresses are allowed through, etc.).

Is it the driver's responsibility to do this filtering, or the softmac
stack's? Can you show me a code example where this filtering is done
properly?

In other cases, it can indicate incorrect implementation of rekeying or
some other bugs in either end of the connection.

I can try different implementations of WPA in the AP if necessary. I
think openwrt has other options. My end is in-kernel ieee80211_softmac -
is there anything you'd like me to look at there?

Anyway, I don't have anything against removing the messages in default
kernel builds. If there is a suitable build time debug option, that
might be nicer way of doing this, though, since these can provide
valuable information when figuring out why something does not work.

If the messages are actually useful, and unusual, then they should
probably stay. But I get a LOT of them, and my wireless is working just
fine.

I noticed that there are counters being incremented where those printks
are. How do I see those counters from userspace?

Jason

On Mon, Jun 05, 2006 at 12:03:35PM -0400, Jason Lunz wrote:

If the messages are actually useful, and unusual, then they should
probably stay. But I get a LOT of them, and my wireless is working just
fine.

I'm dropping this patch, based on Jouni's comments.  If you want to
reformulate a patch that make this output controlled by some sort of
debug option (runtime or compile-time), then please do so and post
it for consideration.

Thanks!

John
-- 
John W. Linville
linville@tuxdriver.com

On Mon, Jun 05, 2006 at 12:03:35PM -0400, Jason Lunz wrote:

If these are a real problem, I'll gladly help debug it. I'm using
2.6.17-rc5's bcm43xx and the in-kernel ieee80211 softmac stack. I'm
using wpa/ccmp/aes with an openwrt AP.

Do you happen to have a wireless sniffer that you could use to capture
the frames? It would be interesting to see whether such a capture log
could be mapped into the dropped frames shown in the kernel debug log.

quoted

In many cases, this may be caused by something missing in local
filtering (e.g., retry duplicates are not filtered out correctly or
messages to incorrect addresses are allowed through, etc.).

Is it the driver's responsibility to do this filtering, or the softmac
stack's? Can you show me a code example where this filtering is done
properly?

This is generic functionality and something I would like to see
implemented in the 802.11 stack so that every low-level driver would not
need to do this. I don't remember what net/ieee80211 code does in this
area. Devicescape code (net/d80211 in wireless-dev.git) has duplicate
detection in ieee80211_rx_h_check().

I can try different implementations of WPA in the AP if necessary. I
think openwrt has other options. My end is in-kernel ieee80211_softmac -
is there anything you'd like me to look at there?

Would you be interested in testing this with net/d80211 code and
wireless-dev.git? It would be interesting to see whether you would get a
different result with the AP end kept in identical configuration and
just changing the client side 802.11 network stack. With net/d80211, the
CCMP replay detection printk is disabled by default (which is what
should be done with net/ieee80211 implementation, too), so that needs to
be enabled at build time. Counters are available from procfs files,
though, so number of replays can be compared.

If the messages are actually useful, and unusual, then they should
probably stay. But I get a LOT of them, and my wireless is working just
fine.

Unfortunately, they are not really unusual. They are useful--at least
for developers--so #ifdef or run-time option for enabling/disabling them
would be nice.

I noticed that there are counters being incremented where those printks
are. How do I see those counters from userspace?

These used to be visible from procfs in the original implementation in
Host AP driver. However, it looks like print_stats function is not
called at all in the version that is in net/ieee80211, so the counters
may not be exposed at the moment. They should be, though..

-- 
Jouni Malinen                                            PGP id EFC895FA

On Mon, Jun 05, 2006 at 08:41:38PM -0700, Jouni Malinen wrote:

Do you happen to have a wireless sniffer that you could use to capture
the frames? It would be interesting to see whether such a capture log
could be mapped into the dropped frames shown in the kernel debug log.

I don't know. Would booting something like knoppix on another laptop
with some flavor of Intel wireless do? The only two laptops I have
regular access to are the bcm43xx one in question and another Intel one
that ordinarily runs winxp.

Would you be interested in testing this with net/d80211 code and
wireless-dev.git?

sure, I can do that. I'm fairly clumsy with git, so it may take a while.

Jason