Bugs item #3076430, was opened at 2010-09-27 09:48
Message generated for change (Comment added) made by oernii
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3076430&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SCP/SFTP
Group: bad behaviour
>Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Ernest Beinrohr (oernii)
Assigned to: Daniel Stenberg (bagder)
Summary: SFTP resume with 4GB file does not work

Initial Comment:
I was trying to resume a file, part of which was downloaded with scp. The file is ~3.5GB large (3579444861) and the small part is
176521216 bytes. However, curl refuses to resume the file with the message:

curl: (36) Offset (176521216) was beyond file size (-715522435)

command line:
/usr/src/curl-7.21.1/src/curl -v sftp://user@server/backup/file.tar.bz2 -C - -o file.tar.bz2

curl version:
curl 7.21.1 (x86_64-unknown-linux-gnu) libcurl/7.21.1 OpenSSL/1.0.0a zlib/1.2.3 libidn/1.18 libssh2/1.2.5
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: IDN Largefile NTLM SSL libz

PS: ever worse, if I leave out the '-C -' part, curl crashes :(

----------------------------------------------------------------------

>Comment By: Ernest Beinrohr (oernii)
Date: 2010-10-15 12:14

Message:
I've just build curl 7.21.1 with libssh2 1.2.7 (64bit,static) and still see
some problems related with the file size. No error this time, but a
segfault. With the 'right' size, the transfer works ok. When I apply the
patch, I get an error:

/usr/src/curl-7.21.1/src/curl --verbose -v
sftp://root@server/dir/file.iso -o file.iso -v
* About to connect() to server port 22 (#0)
* Trying 193.200.9.2... % Total % Received % Xferd Average Speed
Time Time Time Current
                                 Dload Upload Total Spent Left
Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
  0connected
* Connected to server (1.2.3.4) port 22 (#0)
* Failed to read known hosts from /home/oernii/.ssh/known_hosts
* SSH host check: 0, key: AAAAB...w==
* SSH authentication methods available:
publickey,password,keyboard-interactive
* Using ssh public key file /home/oernii/.ssh/...
* Using ssh private key file /home/oernii/.ssh/..
* Initialized SSH public key authentication
* Authentication complete
* Bad file size (-964165632)
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
  0* Connection #0 to host server left intact

curl: (36) Bad file size (-964165632)
* Closing connection #0

PS:
curl 7.21.1 (x86_64-unknown-linux-gnu) libcurl/7.21.1 OpenSSL/1.0.0a
zlib/1.2.3 libidn/1.18 libssh2/1.2.7
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
Features: IDN Largefile NTLM SSL libz

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-10-10 22:45

Message:
Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state
of this issue to pending and it will automatically get closed later on
unless we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-10-05 20:39

Message:
Ernest, can you please verify that you see this problem with libssh2 1.2.7
as well?

If you do, I think we should switch over to continue the bug tracking in
the libssh2 project as this looks like a libssh2 problem more than anything
else to me. If you get the problem with 1.2.7 it'd be great if you could
build one of the sftp examples in the libssh2 project to see if that shows
the problem.

I've still not been able to repeat this.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-30 21:02

Message:
Oh, and I use libssh2 1.2.7 and 1.2.8-dev in my tests.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-30 21:01

Message:
I've tried with 2.9G and 4.2G file sizes using my OpenSSH_5.5p1 on Debian
but they both work just fine off my ext3 file system on a 2.6.32 kernel.

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-30 06:08

Message:
I have yesterday checked, the issue is with multiple sshd server 4 and 5.
Before I was just trying another filesize, so I hit just the one which
worked. I guess that you can try it yourself with 3, 5 and 7 GB file and
see for yourself.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-29 14:28

Message:
I just check the SFTP internet draft. The reported file size is supposed to
be an _unsigned_ 64 bit value so it really cannot ever be negative
protocol-wise.

I get the feeling the size is somehow being treated as a signed 32bit and
it is being sign-extended when converted to 64bit and thus still kept
negative. But I can't understand why it only happens on some servers and
not on others.

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 13:48

Message:
No, the size is reported good obviously, because if its larger that 4GB the
transfer with curl is OK and even the reported size is OK. Its only when
the size is < 2^32 (and probably larger that 2^31). The problem is only
with files from 2GB to 4GB. I just tested a 7GB file and it does not work
also. 8GB goes again. Seems like some math problem.

case 1:
* Initialized SSH public key authentication
* Authentication complete
{ [data not shown]
  0 4177M 0 17.0M 0 0 2770k 0 0:25:43 0:00:06 0:25:37
2945k^C

case 2:
* Initialized SSH public key authentication
* Authentication complete
  0 5320M 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
  0{ [data not shown]
  1 5320M 1 65.2M 0 0 10.6M 0 0:08:20 0:00:06 0:08:14
11.0M^C

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-29 13:23

Message:
Aha, so maybe we can just treat the final size as "unknown" if we get a
negative size then, as clearly the exact size reported in the stat call
doesn't matter for the actual transfer and clearly your server sends the
full file even if it reports a bad size for it.

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 11:37

Message:
Commandline sftp and scp can transfer all those files. Also, I was able to
replicate the issue on mandrakes 'OpenSSH_5.5p1, OpenSSL 1.0.0a 1 Jun
2010'

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 11:28

Message:
Funny, I accidentally created a file BIGGER than 2^32 (4502294711 bytes)
and curl works!!! If I reduce the filesize to 3579444861 bytest it wont
work. This was not on thel but centos 5.5. But sshd is builded from the
same source.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-29 11:02

Message:
I would suspect that since this server doesn't like this big files, even if
 we'd come up with a work-around that would allow the transfer to pass this
point in the code and the transfer would start, it would probably still get
problems when trying to read pieces of the file that are beyond the first
2GB.

I don't see any easy work-around here.

Can openssh's sftp tool copy that file from that server?

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 09:49

Message:
the patch works, it hits
curl: (36) Bad file size (-715522435)

PS: 2^32 - 715522435 = 3579444861 , so yes it hits, but the with
roll-overs you never know, it could be 2x 2^32-715522435 :(

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-29 09:38

Message:
So the patch's condition triggers?

We need to first know exactly what happens before we can consider
work-arounds. If the patch triggers it means the server is broken. If the
server is broken, we need to decide if we can figure out a decent way to
work around this flaw.

Your problematic case might be due to the server not supporting large
files properly, and I'm not at all certain that we can work around that
flaw in the client side.

Can you derive that negative file size somehow from the original actual
size? Is it -(4GB-file size) ?

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 08:19

Message:
Well, I was hoping for a work-around :(

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-28 22:13

Message:
I just attached 'sftp-avoid-negative-file-size.patch' to this bug report.
It is an attempt to detect a negative file size at once and then bail out.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-28 06:55

Message:
Right, to me this looks like a bad server-end that responds with a weird
file size on the SFTP stat request. I'll soon provide you with a test patch
to allow us to see this in detail.

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-28 06:50

Message:
my ssh: OpenSSH_5.5p1, OpenSSL 1.0.0a 1 Jun 2010
remote server: RHEL 5.5: OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul
2008

PS: against another ssh 5.5 it works

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-27 16:36

Message:
Do you know what server software and version is running in the other end?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3076430&group_id=976
Received on 2010-10-15