Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Windows server 2003.

I have the latest WireShark installed on the server and need to capture packets on the server to pinpoint a randomly happened connection reset /retransmitted issue. When the connection reset happens, it resets about 600 connections/sec, where the normal value should below 100/sec. The server is actually a virtual machine on Cisco UCS host. Does the tshark packet capture can help to find out the cause?

Another side question is since I am going to capture all traffics (not sure if it's a good idea), I also do packet slicing. My question is how many bytes should limit for each packet. Looks like the packet I captured has 54 bytes for header (seems including Frame, EthernetII, Internet Protocol, TCP part). Should I just use

tshart -q -b "filesize:20000" -b "files:5" -s 54 -w c:\outfile.pcap

so all the payload won't be saved? Please advise, thanks!

share|improve this question
up vote 3 down vote accepted

For normal ethernet, your snaplen (-s option) should be 1500 if you want the entire packet. That'll give you the entire packet, and allow full protocol decodes when loaded up into WireShark itself. Depending on what you're sniffing, you'll probably want to increase your filesize as well.

To get at least the headers of most packets, a snaplen of 200 is usually sufficient. It'll get the E_II, IP, TCP/UDP, and some of the higher level protocol headers.

There are a few types of connection resets, and each has its own meaning.

Resetting all existing connections immediately

This style of reset shows up in sniffs as a big block of RSTs being sent by the server, probably with very little traffic between the packets. This can be caused by an application above the TCP/IP stack resetting itself, which in turn tells the TCP/IP stack to kill all connection-handles associated with that module.

Resetting all existing connections when they have traffic

This shows up in the sniff with a more sneaky pattern. After a certain point, any time an existing connection receives traffic from a client station a RST packet is issued. What the client does then depends on the higher level protocol, perhaps a reconnection attempt is issued. This is usually caused by the TCP/IP stack itself silently losing connection state. As far as the stack is concerned, that packet from the client is not associated with any open connections so it just issues a RST packet and ignores it.

Resetting new connection attempts

Existing connections continue to work, but SYN packets are replied to with an RST. In normal operation this is done because there is no open port for the port listed on the SYN packet. This is typically caused by a fault in the higher level application.

As for your retransmits, those are caused by clients not receiving packets they expect to get. This can be caused by outright packet loss, or it could be that the server just isn't sending those packets at all. If your sniff on the server shows the retransmit packets, and listing the conversation shows no packets being sent by the server, it's a sign that something has gone wrong on the server itself. This can be related to faults in the higher level application, the TCP/IP stack, or the NIC driver itself. I've seen NIC driver updates fix this, but in a VM that's less likely to be the source of the problem. Mass resets like that could be caused by resource exhaustion on the part of the server.

share|improve this answer
TCP retransmits are a function of the sending host, no? The sending host doesn't recieve an ACK that it's expecting from the receiving host before the retransmit timer expires. The only thing "beyond" the sending host that I can see causing retransmits is network congestion and\or packet loss between the sending and receiving hosts. – joeqwerty Nov 30 '10 at 4:10
@joeqwerty You're right, I didn't phrase that bit terribly well. – sysadmin1138 Nov 30 '10 at 4:17
Just wanted to make sure I wasn't misunderstanding my understanding of retransmits. – joeqwerty Nov 30 '10 at 4:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.