rsync 2.5.6 timeout bug

[Alan Burlison]

Alan Burlison wrote:

>> That is what really happens.  The client specified timeout
>> is passed over the wire for use by the server but if the
>> server has a value specified in rsyncd.conf that value will
>> override the client.
> 
> OK, right - thanks for the clarification.  Still leaves me with the 
> puzzle of why my rsyncs are timing out though...  More investigation is 
> obviously needed.

I've been watching the traffic between the client & server with ethereal, 
and I notice that a lot of the rsync packets are tagged as [short frame], 
although they do have a data payload consisting of a list of filenames 
interspersed with binary data (lengths/checksums I guess).  The penultimate 
pachet sent by the server has a [short frame] tag, and the last packet sent 
by the server looks like it contains the names of a couple of files from the 
top-level directory I am syncing, followed by my string user & group ids, 
followed by 8 nulls.  The next packet back from the client is a ACK, 
followed by FIN, ACK - so it looks like the client is barfing on this last 
packet, as it prints the "error in rsync protocol stream" message.

A few questions:

Does anyone know what the [short frame] indicator means in ethereal - is it 
a glitch in their rsync packet decoder?  If it was a real problem I'd expect 
rsync to fail far sooner that it actually does.

Is there any documentation on the rsync protocol?

Anyone have any clues as to why this failure might be happening, or how I 
might narrow it down?  I was wondering if the packets were being fragmented 
between the client/server, and if that could be causing problems.

I'm going to look through the client end of the rsync code over the weekend, 
but any tips or shortcuts would be gratefully received!

-- 
Alan Burlison
--