I am seeing this behavior on our network, i.e., the syn+ack packets being retransmitted even though an ack packet was received. Initially, I thought the ack packet was being lost but capturing on the server showed that the ack packet was received. Digging deeper I noticed that a web browser (172.16.49.134) would open 6 simultaneous connections to the web server (172.16.1.39) and while one connection would receive data the other 5 would sit idle and exhibit the same behaviour as in the attached packet capture and eventually get closed. https://www.cloudshark.org/captures/36ce590618f0 The server is running RedHat Linux: [[email protected] tmp]# uname -a Linux hostname 2.6.18-371.11.1.el5 #1 SMP Mon Jun 30 04:53:12 EDT 2014 i686 i686 i386 GNU/Linux netstat -i doesn't show errors or dropped packets. Is this normal? asked 27 Jul '15, 08:21  naskop |
One Answer:
Everything has gone normal. But then the Client does not send application Data and for that kind of reason the server sends the syn,ack again, because he hadn´t anything more (Paket 4). And the client acknowledge this again(Paket 5). Afterthat the client closes the session with a normal session close (FIN), perhaps he really has nothng to send. A similar question could be found here: https://ask.wireshark.org/questions/43648/spurious-retransmission-and-dup-ack answered 27 Jul '15, 15:13  Christian_R |
Thanks for the input Christian. I also found this link which explains the behavior: https://ask.wireshark.org/questions/33690/tcp-handshake-question Any suggestions why the client would pause that long before making the GET request? I am seeing this also on sessions that do have actual data transferred.
First of allI think the link you posted in your comment describes another problem. Then I can see that the server sends the answer to a different mac address ( it is different from the source mac of the syn request) Could you provide a trace with a request inside?
I have sanitized the original capture and it also changed the devices MAC addresses. The server sends the frame to the gateway's vrrp virtual mac address
Ok. No then I just have the idea, that it could be application related. But as I told a trace with a request inside would be helpful.