tcp retransmission

@suarez, please take a while to find out how this site works.

• if you set up your e-mail address, you'll get notifications on any answers or comments relevant to your questions, including those which are not immediately visible when you open the question in the web browser because they are too deep in the chain.

• if you look at your previous question, there are two threads of comments, and as the last but one comment to the Question, which is only accessible if you press the "show 2 more comments" button, there is my (second) explanation why the server node A ignores the SYN packet for a while, before finally responding it.

For your convenience, I copy-paste the explanation here (i.e. for the 3rd time in total ;-) :

I can see in the capture at Node A that in the previous TCP session using the same socket pair like the one affected with retransmissions, the client (or the NAT device) sends FIN first, which causes the server side to go into TIME_WAIT state after closing the session, which usually lasts for two minutes. The last ACK packet of the "previous" TCP session, in frame 23, comes at 11:16:28.368, so the server ignores any packets from the same source socket to the same destination socket until 11:18:28.36 because it treats them as wandering packets belonging to that last session. This is the case for all the SYN packets from frame 24 (the initial SYN packet) through frame 27 (which has come at 11:18.22.287), and the server has only "taken seriously" the retransmission of the SYN which has come at 11:18:46.266 (frame 28).

There is also a suggestion of further steps to take.

Thanks for your help Sindy..Appreciate it. The NAT device is cisco router, i believe it only forward the traffic...so the port from source and destination should be from same transaction.. Could we compare using IP identification ? Why client server send from same source continously ? Any setting at client side to resolve this issue ?

I don't understand what you wanted to say by

so the port from source and destination should be from same transaction.

Packets of protocols which use the idea of ports (UDP, TCP...) are sent from a specific port at sender side to a specific port at destination side.

A NAT device translating the sender's address keeps the destination address unchanged, but it may have its reasons to change not only the sender's IP address but also the port. So if a client X sends a request packet from port x to server Y port y, then after passing through the NAT, the packet has the same payload but the source address is changed to Z (the IP address of the server-facing interface of the NAT device) and the source port is changed to z. The z may be the same like the x but it may also differ from it. Without exact knowledge of the algorithm the NAT device is using, you cannot take any of these two possibilities for granted.

The response of the server is a packet with Y:y as source and Z:z as destination. The NAT device looks up in its tables that such packet should be delivered to X:x, so it changes the destination address and port accordingly, keeps the sender address unchanged (Y:y) and sends the modified packet to the original client.

...to be continued

The NAT device is cisco router, i believe it only forward the traffic...

Your captures filtered by the same pair of ports show that the client receives the (SYN,ACK) response to its SYN before the server has sent the (SYN,ACK). This means one of two things:

• either the two TCP session initial handshakes are not linked to each other, i.e. the Cisco does not keep the source port of the client's request unchanged,

• or the Cisco does not merely forward the traffic because in such case, it would not be possible for it to send the (SYN,ACK) packet to the client before receiving it from the server.

Could we compare using IP identification?

I don't think we could rely on it: imagine that there are several clients at the private side of the NAT box, and two of them would send a TCP packet with the same IP ID value through the NAT box to the same server, which is an unlikely but realistic case. The NAT changes the source IP of both these packets to its own one, so we would have two different packets with the same source IPs and destination IPs and protocol. RFC6864 mandates that such packets must not share a common IP ID value for obvious reasons. TCP ports do not play a role here as the requirements on IP ID uniqueness only care about IP addresses, not about any higher layer protocols' information fields.

So to answer the question whether the two tcp sessions between the client and the NAT and between the NAT and the server belong to each other or not, take the "Client Hello" packets of both, and compare the contents of the protocol fields which should be unique for independent sessions (ssl.handshake.random for SSL3 or TLSv1.2 Client Hello, ssl.handshake.challenge for SSL2 Client Hello, I don't have a TLSv1 capture handy so you have to find out yourself). If these values differ, the Client Hello packets belong to different sessions, if they match (bit by bit, it is not enough that they are just similar!), then the packet captured at the server is a NATed copy of the one captured at the client.

Before removing this doubt it makes no sense to proceed.