kernel: TKIP: replay detected:

kernel: TKIP: replay detected:

[Elimar Riesebieter]

Hi all,

I am running

zd1211rw 4-1:1.0: firmware version 4605
zd1211rw 4-1:1.0: zd1211 chip 6891:a727 v4330 high 00-14-7c RF2959_RF pa0 g---

IEEE 802.11b/g  ESSID:"BLO"  Nickname:"zd1211"
Mode:Managed  Frequency:2.462 GHz  Access Point: XX:XX:BB:LL:KK:00
Bit Rate:54 Mb/s
Link Quality=98/100  Signal level=91/100
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

in wpa/tkip mode.

My sylog is filled up with thousands of:
Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
STA=XX:XX:BB:LL:KK:00 previous TSC 00000000BLAa received TSC 00000000BLAa
Sep 21 18:18:29 aragorn kernel: printk: 62 messages suppressed.

Driver is off kernel zd1211_2006-08-19.

Linux version 2.6.18, but has also on the rc ones.

How do I get rid of the syslog messages, which are trashing my vt's
at well?

Elimar

-- 
  Planung:
  Ersatz des Zufalls durch den Irrtum.
                                -unknown-

Re: kernel: TKIP: replay detected:

[John W. Linville]

On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote:

> My sylog is filled up with thousands of:
> Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
> STA=XX:XX:BB:LL:KK:00 previous TSC 00000000BLAa received TSC 00000000BLAa
> Sep 21 18:18:29 aragorn kernel: printk: 62 messages suppressed.

Opinion seems to be running that these messages are useless and should
be removed.  Anyone disagree?

Anybody want to send a patch?

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

Re: kernel: TKIP: replay detected:

[Matthieu CASTET]

Hi,

On Mon, 25 Sep 2006 10:50:00 -0400, John W. Linville wrote:

> On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote:
> 
>> My sylog is filled up with thousands of:
>> Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
>> STA=XX:XX:BB:LL:KK:00 previous TSC 00000000BLAa received TSC 00000000BLAa
>> Sep 21 18:18:29 aragorn kernel: printk: 62 messages suppressed.
> 
> Opinion seems to be running that these messages are useless and should
> be removed.  Anyone disagree?
> 
They could be useful for debugging.

Instead of removing them, enable them when a DEBUG flags is enabled.

Matthieu

Re: kernel: TKIP: replay detected:

[Larry Finger]

Matthieu CASTET wrote:
> Hi,
> 
> On Mon, 25 Sep 2006 10:50:00 -0400, John W. Linville wrote:
> 
>> On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote:
>>
>>> My sylog is filled up with thousands of:
>>> Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
>>> STA=XX:XX:BB:LL:KK:00 previous TSC 00000000BLAa received TSC 00000000BLAa
>>> Sep 21 18:18:29 aragorn kernel: printk: 62 messages suppressed.
>> Opinion seems to be running that these messages are useless and should
>> be removed.  Anyone disagree?
>>
> They could be useful for debugging.
> 
> Instead of removing them, enable them when a DEBUG flags is enabled.

What condition do they indicate when the two are equal? As you probably saw, I sent a patch that 
disables them in that case, but still print the message when received < previous. Would that be 
acceptable?

Larry

Re: kernel: TKIP: replay detected:

[Jouni Malinen]

On Mon, Sep 25, 2006 at 10:50:00AM -0400, John W. Linville wrote:
> On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote:

> > My sylog is filled up with thousands of:
> > Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
> > STA=XX:XX:BB:LL:KK:00 previous TSC 00000000BLAa received TSC 00000000BLAa

> Opinion seems to be running that these messages are useless and should
> be removed.  Anyone disagree?

Yes, I disagree (again). In most cases, these are indication of an
implementation error. The problem here is that this issue may be at the
end of the connection. Anyway, if we are seeing large numbers of replays
detected with the same TSC/PN, I would suggest verifying that the IEEE
802.11 duplicate detection is working correctly in the driver that is
reporting these replays.

TKIP/CCMP are required to use incrementing TSC/PN for each frame. When a
directed IEEE 802.11 frame is not acknowledged, it will be retransmitted
(up to a certain limit). This retransmitted frame will use the same
TSC/PN. However, the duplicate detection routine in the receiver
(something that happens before TKIP/CCMP processing) should catch these
cases since the frames from the same source address that use the same
seq# and fragm# should be dropped at that layer.

If it can be shown, that these errors are indeed caused by a broken
transmitter (and that transmitter is not a Linux device for which we
control the driver code ;-), I would be much more willing to accept
patches that silence these messages (as long as the replay statistics
are easily available in other ways) by default, but I would still not
remove them completely.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: kernel: TKIP: replay detected:

[Larry Finger]

Jouni Malinen wrote:
> 
> TKIP/CCMP are required to use incrementing TSC/PN for each frame. When a
> directed IEEE 802.11 frame is not acknowledged, it will be retransmitted
> (up to a certain limit). This retransmitted frame will use the same
> TSC/PN. However, the duplicate detection routine in the receiver
> (something that happens before TKIP/CCMP processing) should catch these
> cases since the frames from the same source address that use the same
> seq# and fragm# should be dropped at that layer.
> 
> If it can be shown, that these errors are indeed caused by a broken
> transmitter (and that transmitter is not a Linux device for which we
> control the driver code ;-), I would be much more willing to accept
> patches that silence these messages (as long as the replay statistics
> are easily available in other ways) by default, but I would still not
> remove them completely.
> 

I added the following patch to bcm43xx:

Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -460,6 +460,9 @@ static s8 bcm43xx_rssinoise_postprocess(
  }
  #endif

+static u16 prev_frame = 0;
+static u16 prev_seq = 0;
+
  int bcm43xx_rx(struct bcm43xx_private *bcm,
  	       struct sk_buff *skb,
  	       struct bcm43xx_rxhdr *rxhdr)
@@ -470,6 +473,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
  	struct ieee80211_rx_stats stats;
  	struct ieee80211_hdr_4addr *wlhdr;
  	u16 frame_ctl;
+	u16 seq_ctl;
  	int is_packet_for_us = 0;
  	int err = -EINVAL;
  	const u16 rxflags1 = le16_to_cpu(rxhdr->flags1);
@@ -544,6 +548,14 @@ int bcm43xx_rx(struct bcm43xx_private *b
  	}

  	frame_ctl = le16_to_cpu(wlhdr->frame_ctl);
+	seq_ctl = le16_to_cpu(wlhdr->seq_ctl);
+
+	if ((frame_ctl == prev_frame) && (seq_ctl == prev_seq))
+		return -EINVAL;
+
+	prev_frame = frame_ctl;
+	prev_seq = seq_ctl;
+
  	if ((frame_ctl & IEEE80211_FCTL_PROTECTED) && !bcm->ieee->host_decrypt) {
  		frame_ctl &= ~IEEE80211_FCTL_PROTECTED;
  		wlhdr->frame_ctl = cpu_to_le16(frame_ctl);		



By dropping those packets with frame_ctl and seq_ctl the same as the values in the previous packet, 
I was able to cut the number of TKIP replay messages, but some still come through. Is this what you 
had in mind, or is there somewhere else that I should be looking?

Larry

Re: kernel: TKIP: replay detected:

[Jouni Malinen]

On Thu, Sep 28, 2006 at 04:42:10PM -0500, Larry Finger wrote:

> @@ -544,6 +548,14 @@ int bcm43xx_rx(struct bcm43xx_private *b
>  	}
> 
>  	frame_ctl = le16_to_cpu(wlhdr->frame_ctl);
> +	seq_ctl = le16_to_cpu(wlhdr->seq_ctl);
> +
> +	if ((frame_ctl == prev_frame) && (seq_ctl == prev_seq))
> +		return -EINVAL;
> +
> +	prev_frame = frame_ctl;
> +	prev_seq = seq_ctl;

> By dropping those packets with frame_ctl and seq_ctl the same as the values 
> in the previous packet, I was able to cut the number of TKIP replay 
> messages, but some still come through. Is this what you had in mind, or is 
> there somewhere else that I should be looking?

This is quite close to what I had in mind and is likely okay for
testing, but would not be generic enough to be something I would like to
see in the main kernel tree. See IEEE 802.11 clause 9.2.9 for the
details of what the receiver needs to do (mainly, the validation of
addr2 and per STA prev_seq is needed for AP and IBSS modes). In
addition, this should really be in the generic IEEE 802.11 code and
there are couple of optimizations which can be used when combining this
with defragmentation (see, e.g., net/d80211/ieee80211.c
ieee80211_rx_h_check).

Did the replay messages still show the same TSC/PN or did you get rid of
all messages that had the same number repeated?

-- 
Jouni Malinen                                            PGP id EFC895FA