|
|
comp.protocols.tcp-ip
Discussion complète de l'article :
Somthing wrong with the RST-ACK? Server/Client broken?
|
Article :
30119
Date :
02-04-2008
From :
Markus Rehbach
Sujet :
Somthing wrong with the RST-ACK? Server/Client broken?
Hi all,
in the follwing trace we see a quite pathological TCP session.
What's broken? RST-ACK in packet 8 malformed? Telnet host defect? Client, too?
1 0.000000 10.1.14.2 -> 10.2.33.2 TCP 62 1201 > 23 [SYN] Seq=1181960481 Win=64512 Len=0 MSS=1260
2 0.000828 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
3 2.919766 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
4 2.920221 10.1.14.2 -> 10.2.33.2 TCP 62 1201 > 23 [SYN] Seq=1181960481 Win=64512 Len=0 MSS=1260
5 8.825826 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
6 20.645954 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
7 44.304512 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
8 44.305136 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604382 Win=65535 Len=0
9 44.305455 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604382 Ack=1181960482 Win=65535 Len=0 MSS=1452
10 44.305773 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604383 Win=65535 Len=0
11 44.306152 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604383 Ack=1181960482 Win=65535 Len=0 MSS=1452
12 44.306573 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604384 Win=65535 Len=0
13 44.306794 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604384 Ack=1181960482 Win=65535 Len=0 MSS=1452
14 44.307531 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604385 Win=65535 Len=0
15 44.307834 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604385 Ack=1181960482 Win=65535 Len=0 MSS=1452
16 44.308265 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604386 Win=65535 Len=0
17 44.308546 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604386 Ack=1181960482 Win=65535 Len=0 MSS=1452
18 44.308911 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604387 Win=65535 Len=0
19 44.309190 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604387 Ack=1181960482 Win=65535 Len=0 MSS=1452
20 44.310401 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604388 Win=65535 Len=0
following an endless SYN-ACK RST-ACK pingpong......
Thank you
Markus
P.S.: Sorry for the length of the trace lines.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
30120
Date :
03-04-2008
From :
Barry Margolin
Sujet :
Re: Somthing wrong with the RST-ACK? Server/Client broken?
In article ,
Markus Rehbach wrote:
> Hi all,
>
> in the follwing trace we see a quite pathological TCP session.
>
> What's broken? RST-ACK in packet 8 malformed? Telnet host defect? Client,
> too?
Where did you make this trace, on the client or the server? I assume
it's the server. Basically, it looks like the SYN-ACKs aren't getting
to the client for some reason. That's why the client resent the SYN in
packet 4. The server keeps resending the SYN-ACKs, doubling the
retransmit time each time.
After about 30 seconds, the client has given up and closed the
connection. When the server retransmits the SYN-ACK after that, it gets
a RST because the connection no longer exists.
What I don't understand is why the server is repeating its SYN-ACKs
after receiving the RST. This seems like a bug in the server's TCP
stack.
>
> 1 0.000000 10.1.14.2 -> 10.2.33.2 TCP 62 1201 > 23 [SYN] Seq=1181960481
> Win=64512 Len=0 MSS=1260
> 2 0.000828 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 3 2.919766 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 4 2.920221 10.1.14.2 -> 10.2.33.2 TCP 62 1201 > 23 [SYN] Seq=1181960481
> Win=64512 Len=0 MSS=1260
> 5 8.825826 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 6 20.645954 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 7 44.304512 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 8 44.305136 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604382 Win=65535 Len=0
> 9 44.305455 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604382 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 10 44.305773 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604383 Win=65535 Len=0
> 11 44.306152 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604383 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 12 44.306573 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604384 Win=65535 Len=0
> 13 44.306794 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604384 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 14 44.307531 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604385 Win=65535 Len=0
> 15 44.307834 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604385 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 16 44.308265 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604386 Win=65535 Len=0
> 17 44.308546 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604386 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 18 44.308911 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604387 Win=65535 Len=0
> 19 44.309190 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK]
> Seq=1999604387 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 20 44.310401 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK]
> Seq=1181960483 Ack=1999604388 Win=65535 Len=0
> following an endless SYN-ACK RST-ACK pingpong......
>
> Thank you
>
> Markus
>
> P.S.: Sorry for the length of the trace lines.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
30121
Date :
03-04-2008
From :
News Reader
Sujet :
Re: Somthing wrong with the RST-ACK? Server/Client broken?
Markus Rehbach wrote:
> Hi all,
>
> in the follwing trace we see a quite pathological TCP session.
>
> What's broken? RST-ACK in packet 8 malformed? Telnet host defect? Client, too?
>
Presumably, you are sniffing at the Telnet server's end of the connection.
> 1 0.000000 10.1.14.2 -> 10.2.33.2 TCP 62 1201 > 23 [SYN] Seq=1181960481 Win=64512 Len=0 MSS=1260
You see the inbound SYN from the client.
> 2 0.000828 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
You see the SYN/ACK response from the Telnet server.
> 3 2.919766 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
Three seconds later, the server sends another SYN/ACK because it did not
receive an ACK from the client. Either the client did not receive the
SYN/ACK sent by the server, and therefore did not respond with an ACK,
or the server is not receiving an ACK sent by the client.
If you can, it would be good to sniff the client side of the connection
and determine whether the SYN/ACK arrived at the client, and whether an
ACK is sent by the client.
> 4 2.920221 10.1.14.2 -> 10.2.33.2 TCP 62 1201 > 23 [SYN] Seq=1181960481 Win=64512 Len=0 MSS=1260
Host is initiating a new connection attempt (same sequence number).
> 5 8.825826 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 6 20.645954 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 7 44.304512 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604381 Ack=1181960482 Win=65535 Len=0 MSS=1452
Multiple SYN/ACKs from the server (several seconds apart).
Server still isn't getting the ACK it expects.
We are expecting the client's ACK to have Seq 1181960482.
> 8 44.305136 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604382 Win=65535 Len=0
Client sends RST.
Packet 7's Ack was 1181960482 (next expected Seq), but the Seq of packet
8 is 1181960483. Perhaps an ACK was sent from the client with Seq
1181960482, and it's not making it onto the segment your sniffer is
attached to.
> 9 44.305455 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604382 Ack=1181960482 Win=65535 Len=0 MSS=1452
Server is expecting an ACK with Seq of 1181960482 but not getting it.
> 10 44.305773 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604383 Win=65535 Len=0
Client's Ack has been incremented. It received something from the server
(SYN/ACK perhaps).
> 11 44.306152 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604383 Ack=1181960482 Win=65535 Len=0 MSS=1452
Server is still expecting an ACK with Seq of 1181960482 but still not
getting it.
> 12 44.306573 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604384 Win=65535 Len=0
Client's Ack has been incremented. It received something from the server
(SYN/ACK perhaps).
> 13 44.306794 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604384 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 14 44.307531 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604385 Win=65535 Len=0
Client's Ack has been incremented. It received something from the server
(SYN/ACK perhaps).
> 15 44.307834 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604385 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 16 44.308265 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604386 Win=65535 Len=0
> 17 44.308546 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604386 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 18 44.308911 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604387 Win=65535 Len=0
> 19 44.309190 10.2.33.2 -> 10.1.14.2 TCP 60 23 > 1201 [SYN, ACK] Seq=1999604387 Ack=1181960482 Win=65535 Len=0 MSS=1452
> 20 44.310401 10.1.14.2 -> 10.2.33.2 TCP 60 1201 > 23 [RST, ACK] Seq=1181960483 Ack=1999604388 Win=65535 Len=0
> following an endless SYN-ACK RST-ACK pingpong......
>
> Thank you
>
> Markus
>
> P.S.: Sorry for the length of the trace lines.
>
>
Best Regards,
News Reader
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
30122
Date :
03-04-2008
From :
Markus Rehbach
Sujet :
Re: Somthing wrong with the RST-ACK? Server/Client broken?
News Reader wrote:
> Presumably, you are sniffing at the Telnet server's end of the connection.
Its on a mirror port in the middle, but the more critical network
components are on the path to the client (Firewall, IPS IPsec Tunnel).
> Client sends RST.
> Packet 7's Ack was 1181960482 (next expected Seq), but the Seq of packet
> 8 is 1181960483. Perhaps an ACK was sent from the client with Seq
> 1181960482, and it's not making it onto the segment your sniffer is
> attached to.
Is the RST invalid? At first I saw 'reset processing' on Page 36 of the
RFC739. The telnet server is in SYN-RECEIVED state, the SeqNr of the client
is in the window and therefore the RST is valid, or? And what's with the
description of Page 35? Does it matter in that case?
Page 35 of RFC739:
There are three groups of states:
....
2. If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
Page 36 of RFC739:
Reset Processing
In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window. In the SYN-SENT state (a RST received in response
to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
30123
Date :
03-04-2008
From :
Markus Rehbach
Sujet :
Re: Somthing wrong with the RST-ACK? Server/Client broken?
Barry Margolin wrote:
> What I don't understand is why the server is repeating its SYN-ACKs
> after receiving the RST. This seems like a bug in the server's TCP
> stack.
Yes, it is my interpretation, too. IMHO the server should ignore the
packet because the RST is invalid or honour the RST and go back in
LISTEN state.
But the SEQnr of the RST is not matching the SEQnr I expected
(see answer of 'news reader') and I wonder whether the RST is
valid.
Life is hard...;-)
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
|