Can anyone verify what this trace is showing? From what I can tell, packet SYN packet (186) is being rejected in packet 187 with a Reset/ACK. Then 188-190 is a normal 3-way handshake. What I don't understand is why 187 is a RESET. Is it do to the fact that the reported window size in 187 is 0? I don't even see the MSS value being returned/echoed/agreed on in 187. Normally this wouldn't' be of much concern to me as the handshake does eventually succeed, but in this case we are seeing this behavior a lot between these 2 hosts.
asked 28 Mar '14, 19:31  dsuida |
One Answer:
The reason for the first SYN being rejected is because 172.3.5.114 is not a server LISTENing port 58000 when the SYN arrives from 172.30.5.148. In the second 3-way-HS the roles have changed. 172.4.5.114 is now the client connecting to the server at 172.30.5.148:58001 . Looking at the target port numbers it seems as those incrementing ports are dynamically allocated and negotiated between the two socket applications. If this is the case it might well be a timing issue where one side is just not fast enough to have a listening socket open when the other side's SYN packet arrives. Your screenshot doesn't show any timing information. If you need further explanation could you possibly put the trace to http://cloudshark.org so we can see streams 0-5 and the timing between the packets? answered 28 Mar '14, 21:37  mrEEde |
Ah.
So the sequence of: Client > SYN Server > RESET/ACK Client > re-transmit Server > RESET/ACK ...
Indicates the server is not listening on the requested port. Tx for the info.
Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.