?: 'rsync' hang with 'sshd2' (F-Secure), Digital Unix (OSF1) and HP/UX 11

[Harala, Sauli]

Hi, 

I have managed to test this same transfer reliably with the 
Linux boxes and open-ssh,  but I am in trouble with the 
OSF1 4.0 (Digital Unix)  being the server sending files from a single 
directory  to the HP/UX 11 - being the client 

The 'sshd2' (and ssh2) in both ends is installed as root (and starts 
probably from 'rc')

The 'rsync' (2.4.6)  in both end is just installed as a single  binary
in the  stadard user local directory - no '--daemon' mode has been tested
yet.

The 'OSF/1 server side already has the
http://www.clari.net/~wayne/rsync-nohang.patch
included - the client side is still missing it 
Tthe patch included in the OSF side 
did not have any affect on the trouble.

The terminal 'ssh' connection between the machines
works OK. The 'scp' works also (though a bit slowly ...)

I have tried many combinations of swithces, but e.g.the normal single 
directory sync:
./rsync -e /usr/local/bin/ssh --rsync-path=/usr/users/rem_usr/bin/rsync
rem_usr at rem_host:/usr/users/rem_usr/cpy_src/ ./cpy_target/
executed on HP/UX 11 side seems to be hanging.

It  seems that the 'rsync' transfer will start but it may hang
without any proper error messages on the client side.

It may e.g. transfer 0 to 80 of several ~4MB 
files - (most often count is 0) 
- and when it hangs it looks like the forked 
'sshd' daemon (owned by root) on the OSF/1 server 
side would stop processing after short boost 
- though it remains alive as well the 
'rsync' daemon running (well... sleeping) 
under standard end-user ID.

When the '--verbose' is used on the client side,
the result tells that it is receiving the 
directory list, and it lists
the files it has transferred (most often none 
appears)

A partially transferred file may remain in the
receiving directory with the temporary name.

The client running on HP/UX 11  does 
not receive any error information - 
so it will hang waiting for ever 
(I have not tested the --timeout yet)

Only way to restart is to
close the client side with '^C' and restart.

Reading the mail archive, it seems 
that the 'ssh' transport has caused much trouble 
with some other 'rsync' users.

I can configure & establish a verbose 
version of sshd2 proccess at the OSF1/side
with a private port(=1888) and standard user ID - and 
I am capable to connect through it with the normal 'ssh'
client from the HP/UX side - but I have not
yet been able to configure the remotely starting 'rsync' to use this 
'private running' sshd daemon - How this would be possible ?

Quite a long story, but if you know some suggestions, 
please let me know. (I am not experience 
debugging neither the 'ssh' nor 'rsync' traffic.)

I have not used any special options to compile the 'rsync' - the
'off-the-net'
source package was compiling fine with OSF/1 after configure - the
HP/UX version produced some more trouble when compiled with aCC...

I have also tried to read the mailing-list archives, 
but so far none of the hints found have hit the point.

Regards,
sh
----
Sauli Harala
EDS Finland Oy