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

["Matt Smith" <gramps_dogg@xxxxxxxxxxx>]

Thank you everyone for your help.  Heres a little more info.

The client (*.20) is telling us that at the application level, he is getting a timeout, never recieving the data.  We don't have control over the client application, but the server application we do (*.12).  We are trying to determine where the problem resides. If the clients is infact recieving the data, and maybee a problem at the application level. Out of 10,000 transactions a day, only about 5 have this problem.  This is a problem because the server thinks the transaction was sucessful, but the client didn't hear a response so resends the transaction after about 30 seconds.  We are getting duplicates for this reason.

Thanks again everyone, your help is greatly appreciated.

---

From:  Jack Jackson <jack@xxxxxxxxxxxxxxx>
Reply-To:  Ethereal user support <ethereal-users@xxxxxxxxxxxx>
To:  Ethereal user support <ethereal-users@xxxxxxxxxxxx>
Subject:  Re: [Ethereal-users] Help Analysing Transaction
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.

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users