Bug 9407 - rsync transfers cause zero window packets
rsync transfers cause zero window packets
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
x64 Linux
: P5 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2012-11-17 01:24 UTC by Emmett Culley
Modified: 2012-11-17 14:03 UTC (History)
0 users

See Also:

Wireshark packet stream capture (binary tcpdump) (41 bytes, text/plain)
2012-11-17 14:03 UTC, Emmett Culley
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emmett Culley 2012-11-17 01:24:36 UTC
I am using BackupPC with rsync daemons running on the target machines.  Some targets are virtual and some are on their own hardware.

A couple of months ago I noticed that one of the VM targets always failed to get a backup, and upon investigation I found that the packet stream contained lots of zero window and keep alive packets.

The failure turned out to be caused by a wrong VM network driver on that particular VM and after resolving that all backups completed.  However that caused me to look into it further when I discovered that fixing the driver did not stop the zero window packets from happening and upon further investigation I discovered that ALL backup sessions are seeing lots of zero window packets, then further investigation shows that backups are taking way too long; as long as ten hours for a 35GB backup.

I've googled for zero window errors with rsync and nothing I've found points to anything that could resolve my issue.  But how can that be?  Am I the only one seeing this issue?  Or is it that no one is looking?

I am running CentOS 6 and Fedora 17, all of which have rsync 3.0.9-1, except one, which has 3.0.6-9.  I have a Gigibit LAN and iperf shows that there is a solid 900+Mbs throughput in both directions to/from all target machines and the backup server.
Comment 1 Emmett Culley 2012-11-17 14:03:34 UTC
Created attachment 8212 [details]
Wireshark packet stream capture (binary tcpdump)

Please use tcp.port==873 as a filter to see an example of results of this bug.