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").

  • Don't you think that title is a bit over the top? Perhaps you should look up the definition of treason. Mar 17 '10 at 3:00
  • @John That's just copy and pasted from the kernel log message... So is the log message over the top?
    – hurikhan77
    Mar 17 '10 at 3:45
  • 1
    Yes. (stupid 15 character minimum) Mar 17 '10 at 4:06
  • @John Better now?
    – hurikhan77
    Mar 17 '10 at 6:53
  • Yep :) (still 15 character limit) Mar 17 '10 at 7:02

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.

  • 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

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
  • 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

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

  • It's kernel 2.6.28... I've updated the question to reflect this.
    – hurikhan77
    Mar 17 '10 at 2:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.