I have been investigating a "slow" application complaint. When the issue happens I've been told it affects everyone. I did a Wireshark capture on the server and one client. On the server, I saw the [SYN],[SYN, ACK] but no [ACK] when the problem started. I went back to a capture on the client and saw the [SYN], [SYN, ACK] and no [ACK] sent. Normally, I would think that this is a problem with the client NIC or drivers. But, multiple clients are experiencing problems. I thought it might be a bad checksum on the [SYN, ACK] but Wireshark says that the checksum is good. Any ideas? asked 14 Sep '13, 10:05  bbulen |
2 Answers:
There is nothing I can detect in the capture files that might explain the behavior. I conclude: This must be related to the client, which could be:
Regards answered 14 Sep '13, 15:16  Kurt Knochner ♦ Thank you for reviewing it. After I posted the question, I thought I should confirm that the other clients are experiencing the same issue to confirm that there aren't multiple problems. (14 Sep '13, 16:33) bbulen Thank you for reviewing the captures. It turns out that there were two different problems. The NIC of the client I looked at was bad. And, the antivirus software on the server was misbehaving causing the widespread complaints. (17 Sep '13, 12:28) bbulen |
Well, if it is the same server suddenly having problems with multiple (=all?) clients not ack-ing its syn-ack packets it should be 'something' in those 2/3 of the handshake packets. Can you post them in www.cloudshark.org for us to have a look? Some possibilities: - invalid ack number - invalid options Server traceThe server is receiving 3 syn request simultaneously from the (winXP?) client on the same LAN, only the first one making it into an established state with subsequent TLS handshake. The other 2 are entering retransmission from the server side only. Client traceThe client trace only shows one tcp session that does not get an ack from the client. There is nothing wrong with the server's syn_ack. The fact that it is seen in the client's capture excludes a network/NIC issue. So, the question is: Did the Win TCP stack see the syn-ack? I believe it did, but for some reason discarded it, because we would have seen the client retransmitting its own syn packets otherwise. As we don't see any retransmissions by the client, the TCP stack of the must no longer be interested in setting up those sessions. When you issue a netstat at the client, do you see any longer lasting syn_sent connections? There have been some discussions with winXp and half-open limits, not sure if they would apply here. answered 14 Sep '13, 12:45  mrEEde2 edited 15 Sep '13, 03:21 |
I uploaded two captures. One from the server and one from the client. Unfortunately, they weren't captured at the same time. The server capture shows one successfully connection to the client right before two failed connections.
https://www.cloudshark.org/captures/89061479e926
https://www.cloudshark.org/captures/a3ad9d20cae7