Matt Smith wrote:
I was hoping someone could help do an analysis on some tcp transactions.
Maybee explain the sequence of events according the Syn's/Ack's/Psh's
and fin's (especially if there are 3 in one packet set). I have a basic
understanding of them but not enough to understand what packet is being
ack'd and such. Any help would be greatly appreciated. Also, any sites
with an advanced tutorial would be great.
Here are 2 examples, the first is the INVALID transaction and the second
is one that worked (what they all "should" look like). *.*.*.20 is the
router(to client) and *.*.*.12 is the server.
Here is a basic explaination of what should happen. The client
connects, send a message, server processes the message then sends 2
messages back to the client.
No. Time Source Destination Info
1 0.000000 *.*.*.20 *.*.*.12 3614 > 8100 [SYN] Seq=0 Ack=0
Win=65535 Len=0 MSS=1460
2 0.000038 *.*.*.12 *.*.*.20 8100 > 3614 [SYN, ACK] Seq=0
Ack=1 Win=16384 Len=0 MSS=1460
3 0.110655 *.*.*.20 *.*.*.12 3614 > 8100 [ACK] Seq=1 Ack=1
Win=65535 Len=0
4 1.113844 *.*.*.20 *.*.*.12 3614 > 8100 [PSH, ACK] Seq=1
Ack=1 Win=65535 Len=200
5 1.231208 *.*.*.12 *.*.*.20 8100 > 3614 [ACK] Seq=1
Ack=201 Win=65335 Len=0
6 4.872452 *.*.*.20 *.*.*.12 3614 > 8100 [FIN, ACK] Seq=201
Ack=1 Win=65535 Len=0
7 4.872488 *.*.*.12 *.*.*.20 8100 > 3614 [ACK] Seq=1
Ack=202 Win=65335 Len=0
8 5.741186 *.*.*.12 *.*.*.20 8100 > 3614 [PSH, ACK] Seq=1
Ack=202 Win=65335 Len=3
9 5.741844 *.*.*.12 *.*.*.20 8100 > 3614 [FIN, PSH, ACK]
Seq=4 Ack=202 Win=65335 Len=194
10 5.852781 *.*.*.20 *.*.*.12 3614 > 8100 [RST, ACK] Seq=202
Ack=4 Win=0 Len=0
11 5.862991 *.*.*.20 *.*.*.12 3614 > 8100 [RST] Seq=202
At least as I read RFC 793, it's legitimate to send data in a segment
that has FIN set; on page 26, it says
We have taken advantage of the numbering scheme to protect certain
control information as well. This is achieved by implicitly including
some control flags in the sequence space so they can be retransmitted
and acknowledged without confusion (i.e., one and only one copy of the
control will be acted upon). Control information is not physically
carried in the segment data space. Consequently, we must adopt rules
for implicitly assigning sequence numbers to control. The SYN and FIN
are the only controls requiring this protection, and these controls
are used only at connection opening and closing. For sequence number
purposes, the SYN is considered to occur before the first actual data
octet of the segment in which it occurs, while the FIN is considered
to occur after the last actual data octet in a segment in which it
occurs. The segment length (SEG.LEN) includes both data and sequence
space occupying controls. When a SYN is present then SEG.SEQ is the
sequence number of the SYN.
so such a segment means "here's the last data I'll be sending; I won't
send you any more than that (but I *am* sending you that)".
Perhaps the TCP implementation on *.*.*.20 has a bug, and can't handle
segments with data and a FIN?