What's Mean "TCP: Treason uncloaked! Peer..shrinks window..Repaired."

最近在系统的dmesg信息中,经常看到这样的信息:

TCP: Treason uncloaked! Peer 203.168.193.2:2682/80 shrinks window 
                                     2217805154:2217892754 Repaired.
TCP: Treason uncloaked! Peer 203.168.193.2:10721/80 shrinks window ... Repaired.
TCP: Treason uncloaked! Peer 203.168.193.2:10721/80 shrinks window ... Repaired.
TCP: Treason uncloaked! Peer 203.168.193.2:44016/80 shrinks window ... Repaired.
TCP: Treason uncloaked! Peer 203.168.193.2:44016/80 shrinks window ... Repaired.
TCP: Treason uncloaked! Peer 203.168.193.2:55074/80 shrinks window ... Repaired. 

操作系统版本为Redhat Linux AD3:

[root@eygle /]# cat /etc/redhat-release 
Red Hat Enterprise Linux AS release 3 (Taroon)
[root@eygle /]# uname -a
Linux eygle 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386 GNU/Linux 

以前一直没时间关注,今天抽点时间来研究一下.

首先在网上看到这样的一段解释:

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提供解决方案.