On Mon, May 17, 2010 at 3:18 PM, Jon Schewe <jpschewe at mtu.net> wrote: > I'm trying to capture some large files from my house (on Comcast) to a > server out of state (not on Comcast). I'm copying the files using ssh > and a non-standard port.Things are fine for files of a couple megabytes, > but files over say 10 megabytes stall out part way through. One night I > got 50MB uploaded all night! So today I started up tcpdump on both ends > and captured the traffic. I noticed an interesting thing in wireshark > when the connection stalled out. I got a "TCP Previous segment lost" > message on the server side and then started getting "TCP Dup ACK" on > both ends. The server has a SonicWall firewall in front of it and is > virtualized with vmware. My house is using dd-wrt on a Linksys router as > my connection. Is this Comcast doing it's filtering for our protection > or is this just something misbehaving on either firewall? Could very well be the Sonicwall. I had to administer one of these trash heaps before, the default timeout for stateful connections is set to something useless. I worked around it by creating an outbound rule for all TCP traffic with a timeout of 120 minutes instead of the default (10?). There's also a setting (sorry, don't remember where) that adjusts the global TCP settings, and they're WRONG, horribly wrong by default. If I can find my Sonicwall documentation that I wrote, I'll post what the exact TCP settings are and where to find them. Your SSH session issue sounds identical to what I saw when I was trying to set up my first Sonicwall 3060 Pro. Brian