[PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

[PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

[Larry Finger]

When using TKIP and CCMP for wireless encryption with ieee80211, the logs get filled with useless
replay messages where the previous and received TSC are identical. This change deletes
the log message for this case, but still prints the message when there are major differences
in the TSC's.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

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
@@ -394,7 +394,7 @@ static inline int tkip_replay_check(u32 
 				    u32 iv32_o, u16 iv16_o)
 {
 	if ((s32)iv32_n - (s32)iv32_o < 0 ||
-	    (iv32_n == iv32_o && iv16_n <= iv16_o))
+	    (iv32_n == iv32_o && iv16_n < iv16_o))
 		return 1;
 	return 0;
 }
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
@@ -287,7 +287,7 @@ static inline int ccmp_replay_check(u8 *
 	iv16_o = (pn_o[4] << 8) | pn_o[5];
 
 	if ((s32)iv32_n - (s32)iv32_o < 0 ||
-	    (iv32_n == iv32_o && iv16_n <= iv16_o))
+	    (iv32_n == iv32_o && iv16_n < iv16_o))
 		return 1;
 	return 0;
 }

Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

[Johannes Berg]

On Mon, 2006-09-25 at 10:49 -0500, Larry Finger wrote:
> When using TKIP and CCMP for wireless encryption with ieee80211, the logs get filled with useless
> replay messages where the previous and received TSC are identical. This change deletes
> the log message for this case, but still prints the message when there are major differences
> in the TSC's.

Hey, that seems like a good idea to get rid of the messages no one wants
to see (in the retransmit case) but still warn if someone is really
messing with it.

Acked-by: Johannes Berg <johannes@sipsolutions.net>

johannes

Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

[Jouni Malinen]

On Mon, Sep 25, 2006 at 10:49:12AM -0500, Larry Finger wrote:

> When using TKIP and CCMP for wireless encryption with ieee80211, the logs get filled with useless
> replay messages where the previous and received TSC are identical. This change deletes
> the log message for this case, but still prints the message when there are major differences
> in the TSC's.

NAK.

These are not useless messages; they are more or less always indication
of a broken implementation. I have nothing against hiding the messages
by default, but there should be an easy mechanism for noticing that this
is the reason for connection not working..

> --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_tkip.c
> @@ -394,7 +394,7 @@ static inline int tkip_replay_check(u32 
> -	    (iv32_n == iv32_o && iv16_n <= iv16_o))
> +	    (iv32_n == iv32_o && iv16_n < iv16_o))

> --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_ccmp.c
> @@ -287,7 +287,7 @@ static inline int ccmp_replay_check(u8 *
> -	    (iv32_n == iv32_o && iv16_n <= iv16_o))
> +	    (iv32_n == iv32_o && iv16_n < iv16_o))

These changes would break replay protection and must not be applied.
This is opening a security problem, not just limiting when something is
being printed out.

I would be more open to adding this extra condition for just the printk,
i.e., changing net_ratelimit() to net_ratelimit() && (iv32 and iv16 are
same). Even this is a case that should not really happen unless
something is broken since IEEE 802.11 duplicate detection should have
filtered the frames before (and it should be fixed if it did not do its
job correctly).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

[Johannes Berg]

On Thu, 2006-09-28 at 09:02 -0700, Jouni Malinen wrote:
> (and it should be fixed if it did not do its
> job correctly). 

Yup, that's actually the correct fix for this problem. ieee80211 doesn't
do any such thing afaict, probably because Intel's hardware does it
directly or something.

johannes