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

I have a problem with RDC slowing to a crawl or disconnecting entirely. Client is XP SP3 w/ RDC 6, server is Win 2k8 R2. Both have been scanned thoroughly and found to be virus free.

I downloaded and installed Wireshark on the client computer and ran a packet capture during an RDC session. The log showed at least 10-20 retransmit / dup ack /segment losses per minute during normal usage. Then, when I had a disconnect, it shot up to dozens of these per second.

FYI, I know very little about the Wireshark tool or how to do a full analysis of this problem.

** EDIT **

A little about my network architecture:

Client -

  • 12 Mb down, 1Mb up
  • 1 laptop directly connected to the modem -or- (I've tried it this way with no change) plugged in through a Linksys DSL phone box
  • Located in Israel. Telecom services are split into infrastructure and ISP there, infrastructure is provided by HOT, ISP is provided by Netvision.

Server -

  • 5 Mb down, 5 Mb up
  • Medium web/data/app hosting network, routed with Allied Telesyn AR410
  • Located in CA (US). ISP is Call America.

Other remote clients have no issues connecting to the servers (either speed or disconnects). Several other laptops have been used at the client location to verify it is not a hardware issue. The cable modem has also been replaced.

share|improve this question
This is usually due to some idiotic firewall administrator blocking all ICMP because he vaguely remembers hearing somewhere that ICMP is a security risk. – David Schwartz Sep 26 '12 at 19:30
up vote 4 down vote accepted

Probably not enough information, but here is some general guidance:

If other remote clients are ok and do not experience the symptom, the problem probably is not with the server. It may be the connection for that client.

A retransmit typically means that a packet was not acknowledged, so there usually will not be actual "errors" in a packet capture. It means that one end was sending the packets, and the other was not acknowledged. You may want to perform the capture from both ends, to determine if the retransmit is one-way only, or both ways.

If you ping your host from the client, what is the response time? If it is over 150 ms, you may have a suboptimal connection.

The server network adapter setting for Large Send Offload should be disabled. Windows should be smart enough to know it cannot send large packets to machines on different subnets, but sadly this is not always the case. If your server is a hyper-v guest, this is almost certainly the problem.

MTU. Generally speaking, accessing a server remotely when you are not on the same subnet, the MTU should always be whatever the smallest MTU is between the two endpoints. And that usually means the client. For remote clients that connect over VPN, it is not uncommon to have an MTU of 1400 or even lower. It can be beneficial to set the server MTU to match what the lowest MTU would be, to avoid issues where MTU cannot be discovered properly (sometimes referred to as black hole routers). To find the MTU for your connection you can enter the following command from your client:

ping -f -l xxxx <server ip>

Where xxxx is the MTU size. Start with 1400. If it works, increase it until it displays the message "Packet needs to be fragmented but DF set". If 1400 does not work, decrease it until it does. The highest number that works is your payload size. Add 28 to the payload size and that is your MTU.

You can set the server MTU at the following registry location:

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}  

FYI - RDP packets are always sent with the "Do Not Fragment" bit set.

share|improve this answer
Good answer but I completely disagree with disabling large send offload, it it will do negotiation and determine proper size. – Jim B Dec 14 '11 at 2:36
Run at command line: netsh interface ipv4 show subinterfaces. This show MTU per interface – lsalamon Feb 5 at 17:21

Be aware that Network Monitor will often errorneously flag packets as 'Segment Lost' at the beginning of a capture for any TCP conversation the had started prior to the capture.

That is because Netmanager will see Acknowledgements (Sequence Numbers) for packets that occurred prior to the start of capture. Since it sees the ACK without seeing the corresponding packet, it assumes the packet is lost and flags it with 'Segment Lost'. Be careful not to confuse this start of capture lost segment with actual lost seqments. If you sort a conversation by individual IP flow these should sort to the top.

Alternatively you can save the capture to a file and then reload it back into Netmanager. I noticed it will not longer flag the start of capture acknowledgements as 'Segment Lost' after reload.

share|improve this answer

You are receiving the following packages:

  1. TCP Retransmits
  2. Duplicate ACK
  3. Segment lost

If you receive a TCP retransmit, this is because the ACK you have sent was not received by the server. The server was not aware the TCP packet was received, thinks it was lost underway and will send it again.

The duplicate ACK is typically received at the Sender in the following scenario:

  • Receiver receives packet 1
  • Receiver sends ACK for packet 1
  • Receiver receives packet 3
  • Receiver sends ACK for packet 1 (maximum packet sequence number received). This is a Duplicate ACK for the Sender.
  • Receiver receives packet 4
  • Receiver sends ACK for packet 1 (maximum packet sequence number received). This is a Duplicate ACK for the Sender.

The third error (Segment Lost) is exactly this scenario, but at the Receiver side. It indicates packet 3 was received before packet 2.

All these errors indicate congestion: somewhere along the way packets are dropped. This can have a lot of causes, so we really need a good indication of your network architecture to be able to tell you what the cause is.

Normally, congestion is not a bad thing. TCP is made to automatically adjust to this scenario, increasing transfer rate until packet drops / slowdown starts to occur. The fact that congestion poses problems here can have a number of different causes:

  1. Your network is so congested it cannot handle the minimum required transfer rate for RDP. This would be the case for a 2G cell phone connection.
  2. The algorithms in server or client are badly configured. Some ADSL "optimizer" programs can cause this, messing with the parameters of the Vegas TCP algorithm in Windows.
  3. There is some other error (very high load on server or client, bad firmware/driver for network card, ...)
share|improve this answer

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.