Today, considering it is a holiday here in the US, I figured I’d take a day off from the tutorials and ask a question of you.
All of my servers run logwatch (which will make for a great tutorial coming up soon), and I pretty regularly see something like this in the daily output:
--------------------- Kernel Begin ------------------------1 Time(s): TCP: Treason uncloaked! Peer XXX.XX.XX.XXX:XXXX/XX shrinks window 1898670412:1898670413. Repaired.
1 Time(s): TCP: Treason uncloaked! Peer XXX.XX.XX.XXX:XXXX/XX shrinks window 1911943385:1911943386. Repaired.
1 Time(s): TCP: Treason uncloaked! Peer XXX.XX.XX.XXX:XXXX/XX shrinks window 1922304386:1922304387. Repaired.
1 Time(s): TCP: Treason uncloaked! Peer XXX.XX.XX.XXX:XXXX/XX shrinks window 1922444120:1922444121. Repaired.
1 Time(s): TCP: Treason uncloaked! Peer XXX.XX.XX.XXX:XXXX/XX shrinks window 1949802160:1949802161. Repaired.———————- Kernel End ————————-
I’m not really sure what that means, but if anyone can offer me some feedback I’d appreciate it. So far I’ve seen conflicting answers from basic Googling.
I’m kind of wondering the same thing. I used to have this on my server and found very confusing and conflicting explanations of it. The only thing I know is when I stopped running Snort on the server, the messages disappeared.
It’s a little terse, and assumes you understand TCP flow control.
In TCP, each end has a “receive window”; this is a buffer for storing bytes received from the other machine. You tell the other machine how big your receive window is when the connection opens. The remote machine is not allowed to send you more bytes at a time than the spare space in your receive window.
Each time you receive a chunk of data from the remote machine, you send an acknowledgement back, and you tell it how big the remaining receive window is, and which chunks you’ve received.
If both sides are behaving properly, the remaining receive window can only shrink as a result of data sent by the remote machine. The “Treason Uncloaked” message is generated when the remote end shrinks the receive window it’s offering in an acknowledgement by *more* than the size of the chunks it’s acknowledged.
For a worked example:
We open a connection; I say I can receive 1024 bytes at a time, but not my (my initial receive window).
You send me 500 bytes; I acknowledge receiving them, and tell you I can take another 524 bytes (legal, as I’ve only reduced the window by the amount you sent).
You send me another 524 bytes; I acknowledge receiving them, and tell you that you can send another 900 bytes (legal, because I’m expanding the receive window, not reducing it).
You send me 800 bytes; I acknowledge them, and tell you that you can send another 300 bytes (again, legal – I’m decreasing the receive window by less than the amount of data I’ve acknowledged).
You then send me 150 bytes; I acknowledge them, and tell you that you can send another 100 bytes. This triggers “Treason Uncloaked!” – you sent me 150 bytes, I’d previously claimed I could accept a total of 300 bytes, and now I’m suddenly changing my mind and saying “actually, I could only accept 250 bytes – I lied when I said I could accept 300 bytes”.
How dare you attempt to intercept our communications through the neutral zone! This is Captain Lo’Tok of the Klingon Warbird Rahi. I have been monitoring your blog now for three weeks as your ship has been orbiting Planet Druidia. The Klingon Empire will not tolerate TCP or Treason of any sort!
Do not defy my request to leave orbit of Planet Druidia!
Sincerely,
Captain Lo’Tok
Klingon Warbird Rahi
I agree with Simon Farnsworth I could not have put it any better, way to go Simon. I just wanted to chime in so you have more then one with the same opinion.
Have a great 4th and a great weekend.
Scott..
Have a look at this, Christer:
http://www.informedbanking.com/acc/nxwiki/view/TCP-Treason-Uncloaked.html
Mark Preston:
your link is from 2004 based upon the 1.3.x apache kernel. don’t use.
hans
Hans:
The link has been updated recently with the following information:
I read your page first since it was #1 on Google’s search list. Then I poked around a bit farther down and discovered that there is an actual kernel bug in the TCP stack that is usually connected with this message.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2ad41065d9fe518759b695fc2640cf9c07261dd2
The bug was fixed in 2.6.14. I was testing on 2.6.10 and almost certainly exercised the bug. Maybe that was all there was to it in your situation as well. But in the meantime you sure found out lots about web server tuning!