Error in sftp transfer

[James T Horn]

When trying to transfer a file from a remote system using sftp to retrieve a 6300172 byte file, I get a message:

Disconnected; protocol error (Protocol error: packet too long: 40948.).


Warning: child process (/sys$system/tcpip$ssh_ssh2) exited with code 131.


%TCPIP-E-SSH_FC_ERROR, error in ssh file transfer operation


I have tried with smaller files (214073) and it works fine.

[marsh_1]

hi,

can you post up some detail on the vms/tcpip versions and the remote system in use here.

[James T Horn]

The local information:
OpenVMS 8.3
TCPIP Version 5.6 Eco 3

Cannot get the information concerning the remote node other than "Secure FTP Server".

[Hoff]

[Reposting this message. ITRC once again failed during the submit, and the message hasn't appeared in the thread. Apologies on any duplicates.]

Here presuming you are current with current ECO kits for OpenVMS and for TCP/IP Services loaded. If you're not, go do that installation first.

Though we might be able to provide some potential workarounds, in all likelihood we can't fix this problem for you. That's only the vendor(s) involved.

Find a variant ssh and sftp for OpenVMS (specifically, an sftp client, here), and try some tests with that.

Try the same (big) transfer with a different platform; see if the problem appears to be within the client or within the server.

See if a smaller file (try just above and just below the two gibibyte and four gibibyte file sizes) and see what (if any) works with that.

Or skip a few steps here and post the problem report and the details and the sftp -v trace of the activity along to the folks at HP support or whomever is supporting your TCP/IP ssh (and sftp) tools for you. That'll probably be the most expedient approach.

(There have been a few potentially-similar reports of transfer problems and corruptions, such as http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1224623 )

[James T Horn]

Here is the "-D 3" output from the transfer.

[Hoff]

Use a Mac OS X or Linux or Unix box, or scrounge up an sftp client for Windows, and run some tests. Try testing with different file sizes around what is the most typical error case (31- or 32-bit transfer sizes) if you can, too. Also see if cranking up the -b buffer size setting helps any, though that's a complete guess.

I'm not inclined to test with the target sftp server and try to pull over the specified file from there, as I don't know who or what it is, and don't really want to end up attempting to download or downloading something I should not have around. That particular IP domain looks likely to have confidential information around, after all.

While the details are not entirely clear, this does look like either a client or server bug or an area of the existing code ripe for the implementation of an improved diagnostic message.

Allow me to rephrase my earlier reply. Gather up the details, and whatever other tests you can run. Send all of this information along in a problem report to HP. Short of some debugging suggestions and short of suggestions to swap sftp tools or (as mentioned above) guesses, we can't really help you with bugs in the HP OpenVMS ssh sftp client or with bugs or incompatibilities in the server.

[marsh_1]

hi,

to back up earlier posts, there have been similar issues that have supposedly been addressed with packet too long errors, see here with some quotes from the ietf spec :-

http://forums.globalscape.com/tm.aspx?m=15249