6

On one linux server (Gentoo hardened), we are experiencing bursts of the following messages in dmesg from time to time:

TCP: Treason uncloaked! Peer xx.xx.xxx.xxx:65039/80 shrinks window 4094157295:4094160199. Repaired.

Is there anything we should take care of or is this normal?

Update: Maybe related, we are using net.ipv4.tcp_congestion_control = cubic. Kernel version is 2.6.28 with Gentoo hardening patches.

Update: This could probably really be related to hardware/driver issues, as we are seeing a "hickup" on the switches sometimes: The port goes down and comes up again. Only lately we discovered the following dmesg output related to these port hickups:

[5781269.910133] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[5781269.910136]   Tx Queue             <0>
[5781269.910137]   TDH                  <e0>
[5781269.910139]   TDT                  <76>
[5781269.910140]   next_to_use          <76>
[5781269.910141]   next_to_clean        <da>
[5781269.910143] buffer_info[next_to_clean]
[5781269.910144]   time_stamp           <22750e54>
[5781269.910146]   next_to_watch        <e2>
[5781269.910147]   jiffies              <22750f5f>
[5781269.910148]   next_to_watch.status <0>

Usually after these logged lines there also follow some "Treason uncloaked" lines (but not vice versa, means these are not always logged before "Treason uncloaked").

hurikhan77
  • 477
  • 3
  • 9
  • 23

3 Answers3

4

The reson may be any of the following:

  1. Bad tcpstack parameters
  2. Remote attack
  3. Bugs in the kernel or network adapter driver ( I had these in the past with Intel EtherExpress PRO/100 and eepro100 driver )
  4. Faulty network adapter
  5. Damaged or bad cables
moo
  • 311
  • 1
  • 8
  • How to debug if the network adapter driver is the culprit? We are using the gigabit adapter by Intel (e1000). – hurikhan77 Mar 23 '10 at 15:24
  • you can try to find alternative driver for that adapter or just install another adapter, connect everything to it and see what happens – moo Mar 24 '10 at 12:55
1

You can get this message when people decide to "optimize" TCP parmameters on remote systems, but it could be a syn flood attack as well.

There were a few known Kernel bugs that caused this message to be appear in error. I believe they were fixed in the 2.6.26 kernel.

duffbeer703
  • 20,797
  • 4
  • 31
  • 39
  • May it be related to using the cubic congestion control algorithm? May the error be yielded less/more when using other congestion controls? – hurikhan77 Mar 16 '10 at 16:01
  • This exact log message has been removed from the kernel a long time ago, it should no longer occur. I believe your answer is the correct one. – hurikhan77 Aug 21 '19 at 13:36
0

What version of Linux are you using? It could be a bug in your kernel.

Gerald Combs
  • 6,441
  • 25
  • 35