dmesg時發現

TCP: Treason uncloaked! Peer 218.75.242.247:1993/80 shrinks window 4036344937:4036346397. Repaired.

找了一些相關訊息

Quote: http://www.eygle.com/archives/2006/01/whats_mean_tcp_treason_uncloaked.html

首先在網上看到這樣的一段解釋:

The remote host decided to shrink the TCP window size without negotiating such with your Linux box. The message is of the informational level, meaning Linux doesn’t like what it is seeing but will cope with it and carry on.

大致意思是說:這是一段一般性提示信息,說明遠程主机在未經Linux主机”同意”就收縮了TCP window size,雖然Linux主机不喜歡這類舉動,但是仍將繼續處理這類請求.

這是一種解釋,也就是這類信息可能並非危險.

另外一段解釋來自Debian郵件列表,首先回復者引用了一段源代碼說明錯誤的來源:

>>From /usr/src/linux/net/ipv4/tcp_timer.c:

        if (tp->snd_wnd == 0 && !sk->dead &&
!((1<<sk->state)&(TCPF_SYN_SENT|TCPF_SYN_RECV))) {
/* Receiver dastardly shrinks window. Our retransmits
* become zero probes, but we should not timeout this
* connection. If the socket is an orphan, time it out,
* we cannot allow such beasts to hang infinitely.
*/
#ifdef TCP_DEBUG
if (net_ratelimit())
printk(KERN_DEBUG “TCP: Treason uncloaked! Peer
%u.%u.%u.%u:%u/%u shrinks window %u:%u. Repaired. “,
NIPQUAD(sk->daddr), htons(sk->dport), sk->num,
tp->snd_una, tp->snd_nxt);
#endif

具體的解釋是:

So it appears that someone is running some sort of “tar-pit” system that is
designed to keep sockets in a bad state and run you out of kernel memory.

I suspect that this ties in with the spam blocking things we recently
discussed.  Maybe you should tell your ISP that they are to blame for such
actions being done to you and that they should “give you face” (I think that
was the term you used) by closing their open relays.

作者認為這可能和tar-pit攻擊相關.並且建議聯系ISP提供解決方案.

還有如下的解釋:

The reason Linux is printing such messages is because your client guy is shrinking the TCP Window to 0, and the server has something to retransmit. There is something seriously wrong with your client’s stack. Which Stack/OS are you using on he client side, and which browser?

That could explain your browser showing some html tags as the server fails to send the whole page across and based on what browser you are using it is failing to parse it out.

意思是,這類錯誤也可能是客戶端Stack錯誤引起的.

另一段同樣引用了源代碼的解釋似乎直指了問題的本質:

> Treason uncloaked! Peer [IP address]:515/1022 shrinks window
> 3957222360:3957222379.  Repaired.

> Our researches so far indicate the problem may be a buggy TCP stack
> in the client, that is in the DP301P+. But we still do not know
> exactly what caused the problem, nor how to prevent it happening
> again.

That comes from the kernel tcp code below.  Looks like the DLink has
returned information yielding a transmit window smaller than it
previously did; specifically it returned a window of zero plus an ack
of up to byte 3957222360, thus indicating that it can accept nothing
after that byte.  Previously it had sent some ack+wnd values
indicating that it would accept up to byte 3957222379.

The Linux side is now supposed to send a packet every now and then
forever until the returned window is nonzero.  It does.

However, the dlink is apparently not responding in a timely manner.
Any response would either open the window or update the rcv timestamp
such that the thing will retransmit forever.  It may be responding
very slowly, or just not responding at all.

The kernel prints the message after it expected but did not see a
response to the probe packet it sent to check for a nonzero window.
The kernel implements exponential backoff retransmissions until it
hasn’t seen any response in 2m, then it will bail and close the
connection.  This is reasonable.  It’s unclear from your report if the
connections are failing outright or just sometimes having to
retransmit a probe against a peer that shrank the window.

這段解釋极為詳盡.就此作結.

http://magazine.redhat.com/2007/01/29/why-do-i-get-tcp-treason-uncloaked-messages-in-my-system-logs/

Reason:
This is just an informative message. It is not a problem with the system. The message is informing the system administrator that a remote system is not able to communicate correctly with the system in question. It is a problem on the remote system. It indicates that the system in question has received packets with incorrect TCP information. It is caused by a remote host, or intermediate firewall/NAT getting TCP behavior incorrectly. In the usual cases, the only likely impact is a little performance drop on the connection.

contributed by David Robinson

http://www.diybl.com/course/6_system/linux/Linuxjs/20090307/159016.html

后來通過監控圖像發現開始流量是正常的,突然在某個時刻流量一下降低了很多,后來的几個小時也是一樣,流量圖很平,這讓我想起了是不是由于交換机流量限制的原因,后來和机房交涉,並將截圖發給他們看看,果然是他們對單机流量做了限制引起的。

結果:
讓机房把單机流量限制放開,一切正常!

http://pank.org/blog/2006/08/linux-tcp-treason-uncloaked.html

這個訊息是 client 在建立連線後, 沒有和 server 作 negotiate 就嘗試 resize TCP window size,
很可能是 DoS 攻擊.
ref.
DOS attack?? [Archive] – ServerBeach Forums
What’s Mean “TCP: Treason uncloaked! Peer..shrinks window..Repaired.”
Treason uncloaked
http://www.eygle.com/archives/2006/01/whats_mean_tcp_treason_uncloaked.html
Related posts 相關文章
nc 指令檢查 UDP port 是否活著
More...
Named Data Networking (NDN) 用來取代 TCP/IP,但誰知道何時普及呢?
More...

作者

留言

撰寫回覆或留言

發佈留言必須填寫的電子郵件地址不會公開。