Interpretation of packet capture

[AyrishGrl]

Just want to be sure I am reading this trace file correctly. I have a sequence that goes like this:

- Address A send Address B a TCP retransmission [FIN, ACK] with reference time of 40.6854 seq=0 ack=0
- Address A send Address B a TCP retransmission [FIN, ACK] with reference time of 83.8881 seq=0 ack=0
- Address B sends Address A a [RST] seq=2599 ack=1114350665

Is the reset flag for the retransmission packets? How do you match the packets and sequence of events? I'm having problems tracking down whose side the latency is on. I have little experience in reading these and am having a hard time stating one way or another. Any help will be appreciated. Thanks in advance.

 

[limester]

Hi AyrishGrl,

If you want to further gain knowledge in this area, I would recommend visiting

http://www.packet-level.com/

I am in no way affiliated with the site, but I have learned much from the site.

Cheers.

 

[PalmTest]

The way I see it, the communication went as follows:

A sends a SYN to B
B sends a SYN/ACK to A
A sends an ACK to B
A session is established between A and B.

A communicates with B, and B communicates with A.
At a certain point in time A decides to stop the session. probably because all data is transmitted and there is nothing left to transmit.

In a normal situation one sees:
A sends a FIN/ACK to B
(The FIN is the signal from A to B that A wants to (gracefuly) stop communicating. The ACK is probably from a previous packet received from B.)
B sends an ACK.
(This is the ACK from B telling A that it received the FIN.)
B sends a FIN/ACK to A.
(B is telling to A that B is stopping as well.)
A sends an ACK to B.
Both sides agreed to stop and both sides can free the resources which were used to maintain the session.

Now back to your story. You mention a retransmission of the FIN/ACK.
This means that the original FIN/ACK probably did not get through to B. Or that the ACK from B, as a response of the original FIN/ACK, did not make it to A.
After a timeout A sends another retransmission of the FIN/ACK to B.
B on the otherhand did not receive anything from A, because there are no ACK from B to A, and after the timeout of B it decides to quit the session by sending a RST to A. This RST did make it to A.

To make things a bit more sensible;
A FIN is the normal way to stop the session. One asks the other side to stop the session, the other side agrees by sending a FIN also.
A RST is an abnormal way to stop (quit) the session. One tells the other side that one has stopped with this session, and no further information is accepted for this session from the remote side, not even an ACK.

So to answer your question: No the RST has nothing to do with the retransmitted FIN packets.
B hasn't heard from A for a long time (timeout), so B assumes that A has stopped responding to this session. B tells A that B has stopped also. B is not interested if A did or did not receive the RST.

Is there a firewall between A and B?
Take a look at the IP identification at the RST coming from B. Is the IP identification 0x0000 ? Then it probably came from a firewall. Does the firewall use SynDefense?

And to make life a bit easier, I recommend you to use Packetyzer to analyze the traces you made (assuming you use Microsoft Windows).

http://www.networkchemistry.com/products/packetyzer/

Packetyzer is the Windows GUI for ethereal.
Download Packetyzer, install packetyzer, run packetyzer, load your network trace.
Select the connections tab (third from the left).
Find the A <-> B connection.
Click the [+] in front of the connection,
Click the [+] in front of TCP,
Select the first 'data stream',
RightmouseClick and select 'Analyze TCP flow',
The trace is broken down in understandable arrows.
Your host (A) is on the left, and the remote host (B) is on the right. Now you can see the complete data flow.
And to be complete, take a look at the 'Decode' tab to see what information was transmitted.

This wonderfull piece of software helped me in several cases to show the owner of the remote host (server) what was really happening at the network level (and that he has to look at hís server and not my network ).

Greetings,

A PalmTester.

 

[netwho]

Interresting: I thaught this is a Network General: Sniffer forum .....

__________________________________
DOS -> Windows -> Linux -> FreeBSD
**** The evolution of a geek ****

 

[PalmTest]

The Sniffer tool is excellent in decoding the various protocols in network traces and creating Capture Filters and Display Filters. Also the Expert functions are outstanding. Packetyzer cannot do this.
The option I have yet to discover in Sniffer is the possibility to visualize a (TCP/IP) session. Also the Decode function to see the actual transmitted data is a nice option in Packetyzer/Ethereal.
When using Sniffer to detect problems in combination with Packetyzer you can detect/trace and analyze almost everything. There will be no more secrets going around your network.