I'm trying to figure out a problem where I'm getting multiple socket exceptions on client machines on the network. Clients always connect to the server, send some data and the server always sends some data back to every client. I've run a prolonged capture and I'm seeing that when the problem occurs, the server seems to be sending the data back to the client, but almost immediately after that the server sends an RST+ACK packet, as shown below:
A more detailed log is available under http://winger.pl/userfiles/err.txt .
Does anyone have any suggestions of to what might be causing the [RST, ACK] packets to be sent? The clients seem to be getting the RST/ACK (causing them to throw a socket exception) but I'm not sure they are getting the data. There are no firewalls or routers between the host and the client, any kind of firewall/AV software has been disabled on the system running the host application. Also, the same host application is being used on numerous other locations and I havent' seen this problem anywhere else.
Kind Regards, Winger
asked 05 Aug '11, 10:44
TCP RST packets should not be seen normally, one exception is when a Microsoft client closes an SSL session, then you might see "normal" TCP RST packets.
The fact that your first show frame (#57081) has "[TCP Port numbers reused]" in the info column means that Wireshark has seen another TCP session with the same IP-addresses and port numbers before. I think you need to focus on that. Filter on the port numbers and check how long these two (different) TCP sessions were apart, and then check whether the TIME_WAIT timer on 10.41.1.100 might be longer than that.
If so, you need to look into the amount of sessions that you need to process and tune the port range that can be used and the TCP timers accordingly (or even start using multiple IP addresses for making these connections).
It's also a good idea to compare all bad sessions with the good sessions. What do they have in common?
answered 07 Aug '11, 07:10
It is not uncommon for servers to terminate TCP connections by sending a RST, simply because it is faster than FIN/ACK/FIN/ACK, and there is no TIME_WAIT status afterwards. So far I interpret your trace like this:
So, keep in mind that a reset (RST) packet unfortunately doesn't mean anything went wrong. It could be a "normal" connection termination. This kind of termination is often used by Microsoft products like Internet Explorer, Outlook, Exchange Server etc.
answered 05 Aug '11, 17:40