Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs
From: Jouni Malinen <hidden>
Date: 2006-09-28 16:02:45
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..
quoted hunk ↗ jump to hunk
--- 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))
quoted hunk ↗ jump to hunk
--- 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