Ethereal-users: Re: [Ethereal-users] Help Analysing Transaction

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jack Jackson <jack@xxxxxxxxxxxxxxx>
Date: Mon, 24 Oct 2005 17:09:32 -0700
At 02:55 PM 10/24/2005, 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.

PSH is of no interest in looking at sequences of events. It is a flag to the receiver to indicate that data is high priority. The receiver is free to ignore it.

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

A SYN is an implicit byte of data. Packet 2 ACKs packet 1's sequence of 0 with its ACK of 1.

3 0.110655 *.*.*.20 *.*.*.12 3614 > 8100 [ACK] Seq=1 Ack=1 Win=65535 Len=0

*.20 ACKs the SYN from *.12

4 1.113844 *.*.*.20 *.*.*.12 3614 > 8100 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=200

*.20 sends 200 bytes of data

5 1.231208 *.*.*.12 *.*.*.20 8100 > 3614 [ACK] Seq=1 Ack=201 Win=65335 Len=0

*.12 ACKs everything through the 200 bytes just sent

6 4.872452 *.*.*.20 *.*.*.12 3614 > 8100 [FIN, ACK] Seq=201 Ack=1 Win=65535 Len=0

*.20 sends FIN to say that it has no more data to send. The data flows in the two directions are independent of each other. *.12 can still send data to *.20.

7 4.872488 *.*.*.12 *.*.*.20 8100 > 3614 [ACK] Seq=1 Ack=202 Win=65335 Len=0

The FIN is an implicit byte of data at the end of the packet, just like SYN is an implicit byte at the front. *.12 ACKS the FIN.

8 5.741186 *.*.*.12 *.*.*.20 8100 > 3614 [PSH, ACK] Seq=1 Ack=202 Win=65335 Len=3

*.12 sends more data

9 5.741844 *.*.*.12 *.*.*.20 8100 > 3614 [FIN, PSH, ACK] Seq=4 Ack=202 Win=65335 Len=194

*.12 sends 194 bytes of data plus a FIN.

10 5.852781 *.*.*.20 *.*.*.12 3614 > 8100 [RST, ACK] Seq=202 Ack=4 Win=0 Len=0

*.20 is unhappy, for no reason that I can see, unless it is because data was sent with the FIN. That is perfectly legal, but I don't think I have ever seen an actual example before. Likewise I have never seen data sent with SYN, which is also legal.

What should happen here is that *.20 should send an ACK of (4+194+1) to ACK the 194 bytes of data and the FIN, and then *.12 should send one more ACK to indicate it received the ACK from *.20 and the connection is closed.