Well, for anyone who ever runs into this or similar issues again, I figured out what the problem was: my friend's Linksys router. It seems to be puking while processing TCP streams and it simply stops passing the packets along. I set up an OpenVPN tunnel with my friend (runs over UDP) and it's been running great! Kind of crappy that I have to hack it like this, but we're going to talk to Linksys and see if we can get it fixed. Derek Derek Chen-Becker wrote: > Thanks everyone for the replies. Here are some more details and answers > to some of the questions people have responded with > > 1. It's hanging on the same file every time, but it will transfer a bit > more each time if I let the rsync timeout and then start it over (I'm > using rsync's partial file support). The strange thing is that the > "delta" of data is different each time; that is, it's not like it hangs > after sending 2MB each time. Sometimes it send 8MB before hanging, > sometimes it hangs after 1MB. The really strange thing is that if I > compare the file size the rsync reports sending vs what the file system > on the remote side reports they don't match up. Some of that may be > unflushed buffers... > > 2. There are other files that are the same size or slightly larger that > transfer fine > > 3. I've tested the integrity of the file. These are Dar (backup utility) > archives and when I run the archive integrity check this file is passing. > > 4. The remote side has large file support enabled. In any case, the > transfer starts hanging around the 200MB mark > > One of the interesting things to me is that I see the same behavior when > I use SCP and rsync; as far as I can gather, the only thing these two > have in common is that they use an SSH channel for data transfer. Mark's > comment about an older version of OpenSSL and OpenSSH is interesting. If > I have time I'll try to build older versions to see if that makes it > work. Is there any way to get SSH to log packets or do some other low > level debug logging? > > Thanks, > > Derek > >
