早上发现系统中有很多这样的警报信息:
TCP: Treason uncloaked! Peer 202.99.23.243:25/41675 shrinks window 685192561:685194009. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
TCP: Treason uncloaked! Peer 202.99.23.243:25/41513 shrinks window 3033292794:3033295690. Repaired.
在 eygle@ITPUB 的 网站上找到详细的解释, 贴过来:
> 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.
原文:
--------------------next---------------------
阅读(731) | 评论(0) | 转发(0) |
