We are experiencing difficulty with a Windows Server 2003 that is connected to our network via a VPN.

Everything seems to work fine with this server except file share downloads to local machines.

The local machines are running Windows XP. Remote Desktop connections to the same server work great. Uploads to file shares also work acceptibly. (This is surprising because the network between us is actually rated higher for download than upload.)

When dragging and dropping files to the local system, there is a delay > 10 seconds before any progress bar activity. Download of files via the command prompt has the same characteristics. Delay is incurred for each file to be transferred, not once for the entire connection. I have tried ping address -f -l 1472 to verify that this is not a "black hole router" problem http://support.microsoft.com/kb/314825. Same delay regardless of whether a mapped drive or a UNC path is used or whether the connection is made by specifying the IP address instead of the host name. Disabling "NetBIOS over TCP/IP" also did not help. The registry does not have any advanced TCP/IP settings (such as MTU) altered from their defaults. I tried reducing MTU in the registry and that didn't help either.

Any ideas? Also, workarounds that involve adjusting the local XP machine configuration instead of the LAN/WAN or server configuration would be greatly appreciated, if possible.

  • This may be because for the direction you are trying to transfer files upload and download become swapped seen from the external side of your router. This is normal for VPN and assymetric connection types. – hurikhan77 Sep 16 '09 at 22:59
  • <This may be because for the direction you are trying to transfer files> Thanks but I don't think that gets me closer to a solution. Keep in mind the RDP works absolutely great, no detectable latency. – Jason Kresowaty Sep 16 '09 at 23:06
  • Have you tried doing transfers both directions with something like ftp or http? They are both better suited for slow links. – Zoredache Sep 17 '09 at 0:00
  • <Have you tried doing transfers both directions with something like ftp or http> I'd really prefer to get the file sharing working, because I have scripts to transfer files and these aren't built to work with FTP or something else. – Jason Kresowaty Sep 17 '09 at 0:05
  • 1
    It is a "known problem". SMB sucks like a Hoover over latent links. – Evan Anderson Sep 17 '09 at 4:50

Sniff the traffic between the client and the server and see what's happening. There's no better way to get to the bottom of a protocol problem than to see what the computers are saying to each other.

The SMB protocol is a total dog when running over a latent network. I also suspect that you're seeing "progress bar" activity sooner on uploads because of implementation artifacts of the Windows shell, not because data is actually being transferred sooner. My guess is that the same kind of things are happening on every file transfer. A per-file latency lends some creedence to such a conclusion.

  • No, it really is much faster. The latency simply does not occur for the uploads. And if latency was a problem, I would think RDP would be terribly affected. In any case, your troubleshooting is more invasive than I would like to try. So I'm hoping someone can say that they have seen this exact problem and tell me how they solved it. – Jason Kresowaty Sep 16 '09 at 23:18
  • 1
    Phh... sniff the traffic. It'll take a second to load Wireshark on a PC and give it a go. Come on, community-- back me up here. RDP is a lot better w/ latency than SMB, because RDP doesn't have the nasty round-trip dependencies in it that SMB does (basically another ACK layer on top of TCP). – Evan Anderson Sep 16 '09 at 23:49
  • @binarycoder, RDP really doesn't use the network as much or the same was as SMB. Either way the quickest way to find the problem is going to be by starting up a sniffer like Evan suggested. – Zoredache Sep 16 '09 at 23:58
  • @Zoredache: I've never understood reluctance to use a sniffer. Not using a sniffer on a network protocol issue would be like a surgeon not using a scalpel. Any ideas from you experience why people are so reluctant? Years ago, before open source sniffers were common, there was a stigma that sniffers were expensive and complex beasts. Today, I'd think, that stigma has worn off. – Evan Anderson Sep 17 '09 at 0:29
  • <Any ideas from you experience why people are so reluctant> Umm... because I'm not the network admin :) But I am free to change the registry on the local XP box. – Jason Kresowaty Sep 17 '09 at 0:42

In a past life, we fixed file-transfer issues (specifically over VPN) by reducing the MTU. Ping tests using packet sizes around the MTU thresholds were not useful; it's true that you rule out black-holes, but if you had a black-hole you probably wouldn't be able to do anything useful through the VPN.

Our problems were specifically with SMB file transfers, I believe due to packet fragmentation. Reducing the MTU to the 1400-1420 range helped significantly. Remember, VPN encapsulation adds more headers to each packet (it's been a while so I forget the specifics and I'm too lazy to google it tonight), but 1472 + ESP+AH + Ethernet is far more than 1500 (assuming you're using IPSec/ESP+AH). From my experience, excessive fragmentation is not a black or white problem; just because certain tests pass at certain times doesn't mean you can rule it out later.

Since the server is sending the data in this case, you might see if you can set the MTU on the server. It's also the common point that all SMB client connect to, so changing the MTU once there might eliminate the need to set MTU on all the clients (as Path MTU is negotiated between end points).

Also, to those telling him to run wireshark -- what specifically would you tell him to look for? I'm not sure that this is a 'protocol error' -- SMB is probably resetting its connection because of the underlying latency and/or packet drops, so technically SMB is doing its job (it's just a fragile protocol) -- and I'm not sure that tcpdump/sniffer/wireshark is going to point them to a solution. I love tracing network network conversations as much as the next CCNP, but in the wrong hands a scalpel is useless/dangerous. He already said he's not a network admin...

  • 1
    I remember something else: it wasn't just file transfers, we also had problems with Outlook/Exchange. As this FAQ advises, very low MTU's (1100 bytes) might be helpful: cs.cmu.edu/~help/networking/vpn/vpn_faqs.html – Anonymous Sep 17 '09 at 3:46
  • 1
    There's nothing dangerous about running a sniffer. At worst, you waste your own time. I'd be looking for ugly things like TCP retransmits, first. Then I'd be looking at the periods when the client appears to be "doing nothing" to see if data is actually moving (or if stupid things like name resolution requests are being broadcast, SYNs to IPs assigned to secondary NICs, etc). If data is moving, I'd measure the throughput to see if we are incurring delay because of the excessive round-trippiness of the protocol. None of that is seems particularly difficult to me. – Evan Anderson Sep 17 '09 at 4:49
  • agreed that there is nothing really "dangerous" about running a sniffer; except that sometimes a little information can be dangerous (especially without the proper context). none of it seems difficult to you because you're comfortable with it, but you have to admit there is a pretty steep learning curve. the other problem is that sniffers can't see into ESP packets; so all they're going to see is encrypted packets and not the SMB packets contained inside (assuming their VPN is client-based and not router-to-router). they didn't say anything about the VPN connection dropping... – Anonymous Sep 17 '09 at 20:27
  • sorry to be piling on comments down here -- I don't have the points to comment anywhere else... binarycoder -- can you provide more details about the VPN? you only barely mentioned that a VPN is being used, but where? between remote desktops and a central VPN concentrator/router? what vendor? what VPN client? what versions? – Anonymous Sep 17 '09 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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