|Subject:||put() on hpux fails with: Connection to remote server is broken|
|Date:||Wed, 14 May 2008 14:07:51 -0600|
|To:||<bug-Net-SFTP-Foreign [...] rt.cpan.org>|
|From:||"Tom Warkentin" <Tom.Warkentin [...] intecbilling.com>|
Distribution: Net-SFTP-Foreign-1.35 Perl Version: 5.8.7 built for PA-RISC2.0-LP64 Operating System: HP-UX bmw B.11.11 U 9000/800 1121911527 unlimited-user license Local SSH Version: OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005 HP-UX Secure Shell-A.04.30.006, HP-UX Secure Shell version Remote SSH Version: OpenSSH_4.5p1+sftpfilecontrol-v1.1-hpn12v14, OpenSSL 0.9.7l 28 Sep 2006 HP-UX Secure Shell-A.04.50.003, HP-UX Secure Shell version Sending a file using the Net::SFTP::Foreign::put method consistently fails with "Connection to remote server is broken" with largish files. After further debugging, it appears that the remote server just closes the connection when largish packets of data are sent. A work around is to pass in a block_size of 483 to get rid of this error. However, this does not result in a successful transfer. After explicitly setting the block size, I got errors like "bad packet sequence, expected 11, got 12". The sequence numbers were not the same each time the error was produced. By passing in a queue_size of 1, I was able to finally get a successful "put" of a file larger than 483 bytes. The same problem occurs on a "put" transfer from an AIX machine. If you want the OS/SSH/Perl details for this as well, I can dig it up when I get some time. The only difference is that the magic number is not 483 bytes but some other slightly larger value (I haven't figured out the limit by trial and error on AIX but it is somewhere between 483 and 1000 bytes). "get" transfers do not have this problem on any OSes tested. Also, the sftp command that comes with OpenSSH works fine for sending or receiving files. This leads me to believe that there is some logic error in the put method that is causing this problem but I have not yet been able to track it down. If you need any more information or have ideas to try, let me know... Thanks, Tom This e-mail and any attachments are confidential and may also be legally privileged and/or copyright material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an intended or authorised recipient of this e-mail or have received it in error, please delete it immediately and notify the sender by e-mail. In such a case, reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Intec Telecom Systems PLC does not represent or warrant that an attachment hereto is free from computer viruses or other defects. The opinions expressed in this e-mail and any attachments may be those of the author and are not necessarily those of Intec Telecom Systems PLC.