 |
|
 |
 |
Linux"TCP: Treason uncloaked!"错误提示！ |
|
|
|
 |
|
|
| 1. Linux"TCP: Treason uncloaked!"错误提示！ |
  |
|
 |
|
HP : 88 / 884
MP : 638 / 11804
EXP : 36%
|
|
流浪的小孩
成员等级: 36
发表总数: 1916
金币总数: 95
所属组别: 核心成员
注册日期: 2003/12/12
|
RH9.0 demsg的时候有如下内容
TCP: Treason uncloaked! Peer 218.58.83.148:37600/8081 shrinks window 2068054251:2068065035. Repaired.
TCP: Treason uncloaked! Peer 218.58.83.148:37600/8081 shrinks window 2068054251:2068065035. Repaired.
TCP: Treason uncloaked! Peer 218.58.83.148:37600/8081 shrinks window 2068088267:2068092623. Repaired.
TCP: Treason uncloaked! Peer 218.58.83.148:37600/8081 shrinks window 2068088267:2068092623. Repaired.
TCP: Treason uncloaked! Peer 138.40.152.217:3395/8081 shrinks window 4051404558:4051431362. Repaired.
TCP: Treason uncloaked! Peer 138.40.152.217:3395/8081 shrinks window 4051404558:4051431362. Repaired.
TCP: Treason uncloaked! Peer 222.80.114.124:42121/8081 shrinks window 2470736240:2470750680. Repaired.
TCP: Treason uncloaked! Peer 222.80.114.124:42114/8081 shrinks window 2478060725:2478065001. Repaired.
TCP: Treason uncloaked! Peer 218.59.234.246:43242/8081 shrinks window 2090418681:2090421585. Repaired.
TCP: Treason uncloaked! Peer 218.65.113.254:38593/8081 shrinks window 828149767:828161359. Repaired.
TCP: Treason uncloaked! Peer 218.65.113.254:39301/8081 shrinks window 855657129:855670197. Repaired.
TCP: Treason uncloaked! Peer 218.65.113.254:39303/8081 shrinks window 853304179:853315771. Repaired.
TCP: Treason uncloaked! Peer 218.65.113.254:39301/8081 shrinks window 855674553:855681813. Repaired.
TCP: Treason uncloaked! Peer 218.65.113.254:39303/8081 shrinks window 853337551:853344811. Repaired.
TCP: Treason uncloaked! Peer 218.65.113.254:38593/8081 shrinks window 828856899:828864127. Repaired.
这可能是什么原因造成的哪？
为人民服务！ |
|
|
|
| 2. Re:Linux"TCP: Treason uncloaked!"错误提示！... |
|
|
 |
|
HP : 1026 / 1710
MP : 4105 / 27553
EXP : 43%
|
|
rotartsinimdA
成员等级: 69
发表总数: 12315
金币总数: 406
所属组别: 管理员
注册日期: 2003/01/1
|
http://www.experts-exchange.com/Security/L...Q_20788430.html
http://www.linuxprinting.org/pipermail/gen...3q2/003945.html
http://www.google.com/search?sourceid=mozc...eason+uncloaked
xxbin@netbuddy.org |
|
|
|
| 3. RE: Linux"TCP: Treason uncloaked!"错误提示！... |
|
|
|
|
|
HP : 88 / 884
MP : 638 / 11804
EXP : 36%
|
|
流浪的小孩
成员等级: 36
发表总数: 1916
金币总数: 95
所属组别: 核心成员
注册日期: 2003/12/12
|
FT!
我查过了，但没有找到答案。
而experts-exchange的注册是要收费的。
为人民服务！ |
|
|
|
| 4. Re:Linux"TCP: Treason uncloaked!"错误提示！... |
|
|
|
|
|
HP : 1026 / 1710
MP : 4105 / 27553
EXP : 43%
|
|
rotartsinimdA
成员等级: 69
发表总数: 12315
金币总数: 406
所属组别: 管理员
注册日期: 2003/01/1
|
from experts-exchange
Comment from jlevie
Date: 11/05/2003 05:10AM PST
Comment
I'd say there's two different issues here and they probably aren't related. The TCP errors would tend to point to a problem with the ssh client/system you are using. If I understand your problem with the web site it sounds like some of the data that you expect to be rendered by a browser is showing up as the raw HTML code. That would point to a problem with the HTML pages themselves, or if they are being generated by a scripting language (PHP, Perl, etc) with the code that generates the page.
Comment from linuxsub
Date: 11/05/2003 02:43PM PST
Comment
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.
Comment from mbarbos
Date: 11/06/2003 01:55AM PST
Comment
As my predecessors have said, the error means a broken stack on the client side. Or maybe an (pretty silly) attack.
Or a new firewall policy from your ISP or a broken device along the way (although I think this is quite unlikely).
Anyway:
1. do you find any other errors linked to the TCP/IP stack ? Something about wrong checksums ?
2. Are you using any mobile devices ? Some of those seem to have funny ideas about TCP/IP.
3. Do you recognize the IP (202.162.56.156) ?
Comment from pjedmond
Date: 12/13/2003 03:44AM PST
Comment
The IP 202.162.56.156 does not appear to be a valid registered IP to anyone, and it is not an 'internal network ip' as far as I'm aware, therefore, I'd treat this particular incident suspiciously.
Unfortunately, I can't reproduce this error, even with a RedHat 7.2 Server available to me.
I suspect that this message was as a result of an attempted attack on your sshd. As a result of the number of packets being sent, you attempts to access anything else were messes with, and unable to complete. Therefore I recommend:
a. Check whether you have sshd running. If you don't need it, then get rid of it.
b. If you do need sshd, then check version number (rpm -q sshd), and go here:
http://www.openssh.com/security.html
Check whether your sshd needs to be updated, and update as required.
HTH:)
Comment from pjedmond
Date: 12/13/2003 03:50AM PST
Comment
Of course if you are not using sshd - just bloke port 22 with your firwall:)
Comment from ahoffmann
Date: 12/14/2003 01:22AM PST
Comment
> .. then check version number (rpm -q sshd),
please don't rely on rpm (or packages anyhow) but use
sshd -V
to get the real version.
Think secure, not guessing ;-)
Accepted Answer from savash
Date: 02/26/2004 12:58AM PST
Grade: B
Accepted Answer
The client is "shrinking the TCP Window to 0" and it cause the problem. So, what to do to prevent this issue ?
Administrative Comment from jlevie
Date: 02/26/2004 07:44AM PST
Administrative Comment
savash,
If you are seeing an answer to a similar problem you should open your own question.
Comment from ahoffmann
Date: 06/07/2004 01:32PM PDT
Comment
logudotcom, could you please explain your grading
Comment from mgbyrne2004
Date: 07/07/2004 06:36PM PDT
Comment
*** advertising removed by Netminder, Site Admin ***
Comment from buckaro0
Date: 10/06/2004 04:19PM PDT
Comment
Just to comment on pjedmond's remark that you should treat this suspiciously... I'm not so sure.
-- the original IP address 202.162.56.156 is a _valid_ IP address, with a registered operator in India.
so it's not as suspicious as a packet coming from an unallocated source.
inetnum: 202.162.48.0 - 202.162.63.255
netname: SPACENET
descr: HCL Comnet, Internmet Service Provider on VSATs, India
xxbin@netbuddy.org |
|
|
|
| 5. 这个也许讲的有道理。 |
|
|
|
|
|
HP : 88 / 884
MP : 638 / 11804
EXP : 36%
|
|
流浪的小孩
成员等级: 36
发表总数: 1916
金币总数: 95
所属组别: 核心成员
注册日期: 2003/12/12
|
> 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.
RFC793 describes the correct behaviors here:
The mechanisms provided allow a TCP to advertise a large window and
to subsequently advertise a much smaller window without having
accepted that much data. This, so called "shrinking the window," is
strongly discouraged. The robustness principle dictates that TCPs
will not shrink the window themselves, but will be prepared for such
behavior on the part of other TCPs.
The sending TCP must be prepared to accept from the user and send at
least one octet of new data even if the send window is zero. The
sending TCP must regularly retransmit to the receiving TCP even when
the window is zero. Two minutes is recommended for the
retransmission interval when the window is zero. This
retransmission is essential to guarantee that when either TCP has a
zero window the re-opening of the window will be reliably reported
to the other.
When the receiving TCP has a zero window and a segment arrives it
must still send an acknowledgment showing its next expected sequence
number and current window (zero).
The requirement in last paragraph is apparently not met by the dlink.
Possibly the issue is that Linux is sending not the "usual" 1-byte
zero-window probe, but instead may be sending a 19-byte packet that it
just happened to have at the head of the queue. This is entirely
legal (the spec says "send _at least_ one octet"), but is different
than the behavior of most stacks - Linux included - for a normal
zero-window situation, so perhaps the dlink doesn't deal with it.
I would capture the tcp traffic with tcpdump to determine for sure
what is going on. That done it should be possible to fix it.
You might attempt to work around this by replacing the TCP_RTO_MAX
probe cap in the kernel code with a much larger number than the
recommended value (try 10 minutes: 10*60*HZ). This will cause
flow-controlled connections to seemingly dead peers to retransmit for
a longer time at a 2m interval; if the dlink is still alive but just
temporarily nonresponsive, then maybe things will continue when it
starts speaking to the network again.
Less ugly would be to arrange for Linux to send 1-byte probes for this
case, if in fact it is not doing so.
Mind you, 2 minutes is a pretty long time for a flow control
condition, even for a printer. I would check for congestion-causing
configuration elements in your setup. Are there many TCP clients of
this printer server at once? Are there broadcast storms on the
network? Do people print jobs that pause the printer forever until a
button gets pushed on the printer panel?
为人民服务！ |
|
|
|
| 0 名会员正在浏览该主题 (0 名游客 和 0 名隐身会员) |
| 0 名会员: |
|
|
