Hoping to get some assistance with an rsync (or possibly ssh) problem. Unfortunately no-one on the rsync mailing list has felt able to assist.

I'm trying to send files from my local server running Ubuntu Dapper to my Linode server (also Ubuntu Dapper) using rsync over ssh. The local server sits behind my router and is accessible from my PC as 192.168.1.2. I can establish ssh links to my Linode OK.

Issuing an rsync command from the local server initiates a response on the destination as I can see the new directories being created to mirror the local setup, but no files ever get transferred and the process eventually times out. I have collected the error messages, and also set up a debug process as described in the rsync debugging FAQ, but it's meaningless to me. I won't post it here as it's a 15kB output.

I have access to 4 different servers (all Ubuntu Dapper), and have established the following:

2 remote servers can each rsync files between themselves. Both remote servers can push files to my local server. My local server can push files to a VM server on the same network. The VM cannot transfer files to the Linode or other remote server. My PC can transfer files to my Linode using sFTP. rdiff-backup behaves essentially the same - the process is initiated on the destination, but no files get transferred.

It would seem the problem arises only when trying to move files from within my local network to the outside world. There is nothing obvious on the local server IP tables (incoming ssh allowed, default outgoing is to accept, and the VM doesn't have an active firewall). My router port-forwards ssh requests to the local server, but I can't see anything blocking outgoing packets (mail gets out OK).

Sorry this is a bit long, but I'm totally stumped and can't use my Linode for one of its intended purposes (as a backup for my local file-server) unless and until I can resolve this.

My initial guess will be a local MTU issue on your home network. How are you connecting to the internet? DSL using PPPoE? If so, and if your router is being too agressive at blocking ICMP packets, then it's possible that it's not getting the right resize requests and oversized packets are being dropped.

(This is mostly a WIndows problem; I've never seen a linux machine with this issue, but your description is very symptomatic). Try setting a smaller MTU (1492 is common) on the ethernet connection using ifconfig and see if that solves the problem.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

The local server is connected to the router by ethernet. The router connects to an ADSL modem using PPPoA, which just basically acts in pass-through mode for the router to handle. Modem MTU is set to 1500 (default), and I adjusted the local server like so:

sudo /sbin/ifconfig eth0 mtu 1492. Astonishingly, I've just successfully transferred my first file to the remote!! And confirmed it with some more, so it looks like it's fixed. Many many thanks.

It's the "PPP" part that killed you; that adds 8 bytes of packet overhead, so when your PC was sending out 1500 bytes, the PPP would add it's 8 bytes of overhead, resulting in 1508 bytes to be sent over the PPPoA connection and that was too big.

The router should have fragmented the packet or sent a "too big" response back to the server, but... *shrug* By setting your local MTU to 1492 then you'll never send a too big a packet. All machines on your local network should be configured this way if they're going to send to the internet.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Interesting that the Windows programs transfer data OK, but the Linux ones don't (or didn't). Anyway thanks, I won't change any more settings as it's all working OK now, but will remeber the MTU settings if anything like it happens again in future.