Ticket #116 (closed defect)

Opened 8 years ago

Last modified 8 years ago

ssh daemon drops connection if file size 14MB or more

Reported by: schmittty Owned by: bagder
Priority: low Milestone:
Component: SCP Version:
Keywords: Cc: schmittty, bagder, alamaison
Blocked By: Blocks:



Currently I have an issue to copy files bigger than 14MB from remote host to local host (this barrier might differ on other) if I use the libssh2 library via libssh2_scp_recv() api call. Smaller files less than 14 MB are copied without an issue from remote host to local host. Furthermore scp command from shell doesn't show any issue by copying files above 14MB size. For the test the attached source “scp.c” from the example/simple is used with small modification.

The if I look to the libssh2 debug information and tcp trace I see that the ssh daemon refuses the tcp connection by TCP RESET flag. Currently I don’t have further trace information from ssh daemon, about it this quite strange that the ssh daemon refuse the tcp connection when more bytes need to be exchanged between the peers.

I hope you can let me know root cause for the “scp - libssh2” issue.

System information:

  • Sun Solaris Sparc 64-bit
  • Openssl library is compiled with 64-bit (for sparcv9)
  • libssh2 is compiled with 64-bit (with CFLAG=m64)
  • libssh2 used Openssl library
  • Issue is observed if files are exchanged on single machine and between two Sun Solaris machines.

Please let me know if you need further information.

Thanks for your help in advance.



scp.c (5.6 KB) - added by schmittty 8 years ago.
Updated modified scp.c example (I missed a line for ip address resolution in my previous version)

Download all attachments as: .zip

Change History

comment:1 Changed 8 years ago by bagder

so does the UNMODIFIED scp.c example work?

Changed 8 years ago by schmittty

Updated modified scp.c example (I missed a line for ip address resolution in my previous version)

comment:2 Changed 8 years ago by schmittty

Yes, the original scp.c example shows the same behaviour.

Furthermore I analysed the ssh daemon debug information and saw several

"sshd[27686]: [ID 800047 auth.crit] fatal: buffer_append_space: alloc 10489856 not supported"

trace outputs before the ssh daemon (sun sshd version Sun_SSH_1.1.1) close the tcp connection (respectively in the sshd trace prints "Calling cleanup" and "channel_free").

Any idea what caused the ssh daemon to call buffer_append_space?



comment:3 Changed 8 years ago by alamaison

Which version of OpenSSH are you connecting to? It looks like you might be suffering the following Solaris OpenSSH bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1131. Apparently, it's fixed in v4.4.



comment:4 Changed 8 years ago by schmittty

In my case Sun Solaris SSH 1.1.1 is used, which might be based on OpenSSH 3.5p1 (based on information from opensolaris).

comment:5 Changed 8 years ago by bagder

I rephrased the summary.

But still, this is the server dropping a connection that otherwise works with other servers. I can't see how this isn't rather a server-side bug.

comment:6 Changed 8 years ago by schmittty

After awhile I received a positive response and temporary fix (SR# 71610828) from Sun. The fix works fine and now it is possible with the Sun ssh daemon and libssh2 to copy bigger files.

Sun plans to provide this fix (interoperability fix) within the next two weeks, in his next service release.

Problem report will be closed when the official fix from Sun is available.

comment:7 Changed 8 years ago by schmittty

Official fix, Patch 143140-02, is released on SunSolve? and ready for use. Item will be closed.

Note: See TracTickets for help on using tickets.