Interesting Traces - Connection Reply appearent packet reversal

The following trace (figure 1) was taken using packet_monitor on a Stratus VOS V-series system. It has been extensively edited to make it fit on the page but all pertinent fields are shown. It shows an interesting reversal of packets. The first two packets show a connection request going out. Packet 1 at 7:41:50.442 is the original SYN packet and packet 2 at 7:41:53.293 is a retransmission. We know it is a retransmission because the sequence number is the same as packet 1. Packet 3 at 7:41:53.310 is an ACK for the SYN packet, followed by the SYN-ACK in packet 4 at 7:42:08.149. How can an ACK preceed the SYN-ACK?

7:41:50.442 Xmit ID 5c8a, from 172.16.1.65.62291 to 10.16.5.197.23    seq  973, ack    0, Syn      
7:41:53.293 Xmit ID 633f, from 172.16.1.65.62291 to 10.16.5.197.23    seq  973, ack    0, Syn
7:41:53.310 Rcvd ID c8d3, from 10.16.5.197.23    to 172.16.1.65.62291 seq  852, ack  974, Ack
7:42:08.149 Rcvd ID c8f4, from 10.16.5.197.23    to 172.16.1.65.62291 seq  851, ack  974, Syn Ack
7:42:08.149 Xmit ID 760c, from 172.16.1.65.62291 to 10.16.5.197.23    seq  974, ack  852, Ack

Figure 1 - trace taken on client system

My first thought was that packets 3 and 4 were reordered somewhere in the network but 15 seconds seemed like an unreasonable delay for packet 4. Also the IP ID value of packet 3 is c8d3 while packet 4's is c8f4. Since c8f4 is greater than c8d3 it would appear that packet 4 was indeed sent after packet 3.

It then occured to me to ask why there is an ACK to begin with, it is not part of the 3 way handshake.

So was there some strange glitch in the TCP stack of 10.16.5.197? Not in this case. As it turns out I have a simultaneous packet_monitor trace taken on the server, see figure 2.

7:43:00.386 Rcvd ID 5c8a, from 172.16.1.65.62291 to 10.16.5.197.23    seq  973, ack    0, Syn      
7:43:00.427 Xmit ID c8c9, from 10.16.5.197.23    to 172.16.1.65.62291 seq  851, ack  974, Syn Ack
7:43:02.600 Xmit ID c8cf, from 10.16.5.197.23    to 172.16.1.65.62291 seq  851, ack  974, Syn Ack
7:43:03.235 Rcvd ID 633f, from 172.16.1.65.62291 to 10.16.5.197.23    seq  973, ack    0, Syn
7:43:03.237 Xmit ID c8d3, from 10.16.5.197.23    to 172.16.1.65.62291 seq  852, ack  974, Ack
7:43:04.811 Xmit ID c8d7, from 10.16.5.197.23    to 172.16.1.65.62291 seq  851, ack  974, Syn Ack
7:43:09.235 Xmit ID c8e7, from 10.16.5.197.23    to 172.16.1.65.62291 seq  851, ack  974, Syn Ack
7:43:18.074 Xmit ID c8f4, from 10.16.5.197.23    to 172.16.1.65.62291 seq  851, ack  974, Syn Ack
7:43:18.093 Rcvd ID 760c, from 172.16.1.65.62291 to 10.16.5.197.23    seq  974, ack  852, Ack

Figure 2 - trace taken on server system

Unfortunately the clocks on the two systems are not in sync but you can match the packets in the client trace with the ones in the server trace by looking at the IP ID values.

As the server trace shows the server did respond to the SYN with a SYN-ACK, it did so twice. However, neither packet was received by the client. The server responded to the second SYN packet with just an ACK and that is first packet received by the client. The server then sent three more SYN-ACK packets before one was finally received by the client.

From the server side this is a perfectly normal trace showing problems communicating between server and client. From the client side the trace is just a little strange.

This page was last modified on 08-09-03

Send comments and suggestions
to ndav1@cox.net