This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP client stops acknowledging messages

0

Hi,

In our setup we have a TCP server that continuously sends data (@35 Mbyte/sec) to a single TCP client and, after running for more than 24hours continuously, the client side stops acknowledging the messages with as a result that the server side retransmitting the data over and over again. We caught this issue using wireshark running on another Dell Server with a fast raid controller for storage. Any ideas on why the client side stops sending ACKs?

A couple of keywords on our setup: . Server side: a FPGA . Client side: Dell Server (windows server 2012) with a Intel 4P I350-t network adapter . TCP client using overlapped IO

Kind regard, Peter

asked 05 Sep '15, 10:31

peter73's gravatar image

peter73
6112
accept rate: 0%

Could you provide us a capture file somewhere publicly accessible, like http://www.cloudshark.org, dropbox or somwhere else, and post a link to the capture file.

(06 Sep '15, 12:12) Christian_R

I've placed an export of the capture in my dropbox, https://dl.dropboxusercontent.com/u/29942579/Retransmit_Export_2015_09_07.pcapng

Many thanks for your support, Peter

(07 Sep '15, 01:37) peter73

2 Answers:

0

I would say it is due to the client losing the ARP entry for the server.
Adding a static ARP might circumvent this problem ...

arp /s 192.168.4.1 00-50-c2-43-63-1d 00-AA-00-4F-2A-9C

NB: You are receiving multicast packets for the ip.dst == 192.168.9.255 which is far away from your interface's IP address 192.168.4.100 so maybe this is a misconfiguration issue and is contributing to this problem...

Regards Matthias

answered 07 Sep '15, 04:00

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

Thank you for your reply. What can be the reason for the client to loose the ARP entry? is there a log that shows this was the case? I'll will check the multicast from 192.168.9.255, no idea at the moment where this is coming from.

Regards, Peter

(07 Sep '15, 04:50) peter73

The multicast is coming one of the other interface of the the machine doing the wireshark capture, no problem there because this is not used operationally.

(07 Sep '15, 08:38) peter73

0

Till packet 9 server is sending data to client on mac a0:36:9f:2b:f2:f4 and it received ack also but from packet 12 server is sending data to same client(same session) on mac a0:36:9f:2b:f2:84 and may be a different client system where that session doesnt exist,so no ack sent by this client.

answered 07 Sep '15, 10:32

kishan%20pandey's gravatar image

kishan pandey
221282936
accept rate: 28%

Holy smokes! I totally missed that. Thank you very much for pointing this out!

(07 Sep '15, 13:07) peter73