rsync 2.5.6 timeout bug

[jw schultz]

On Sat, Aug 02, 2003 at 01:00:47AM +0100, Alan Burlison wrote:
> 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 

The stuff from stat(2).  No checksums yet unless you specified -c.

> 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. 

4 bytes NULL to terminate the gid list.  4 bytes status.
Everything normal so far.

> 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.

What should have been sent next (aside from ACK) should have
been a 4 byte integer of a fairly low value followed by some
binary data representing the checksums or 12 bytes of NULL
for a new file.

> Is there any documentation on the rsync protocol?

I don't think so.  Only the code.  If i recall the comments
of someone else correctly pysync is wire-compatible with
rsync and might be easier to grasp.

> 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.

Is there any chance there is a firewall enforcing a timeout;
possibly a "personal" firewall on the client machine?  If it
were the client code timing out i think there would be an
error message.  What you describe looks like the connection
is being closed from the client end, not a timeout in the
client code.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt