https://bugzilla.mindrot.org/show_bug.cgi?id=1458
Summary: sftping files from SSH Tectia Server 6.0.0 hangs
forever
Classification: Unclassified
Product: Portable OpenSSH
Version: 3.9p1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: sftp
AssignedTo: bitbucket@mindrot.org
ReportedBy: nix-corp@esperi.org.uk
Created an attachment (id=1482)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1482)
Trace of sftp hanging
(Note that despite the ancient version attached to this log, from code
inspection I am reasonably certain that the 'bug', if such it may be
called applies to 5.0p1 as well.)
On March 7th SSH Communications Security, Inc released SSH Tectia
Server 6.0.0. sftping files from this system fails with the trace
attached (with private info such as pathnames and filenames replaced
with [...]).
The file in question here is 8764 bytes long, but once the server's
sent that, requests for more data do not lead to it sending us an
SSH2_FX_EOF status packet, but rather a packet of length *zero*. This
doesn't let us make any forward progress, so we keep requesting more
data forever. From the user's POV, sftp freezes solid with a saturated
network.
I suspect that the problem is that this server hasn't been tested
against sftp clients supporting protocol 3, and it's violating the
protocol spec by ignoring both the negotiated protocol version *and*
the fact that (due to the protocol version) it hasn't been able to
engage in 'supported2' negotiation, and is assuming that the
'max-read-size' extension is available. Under that extension, it *has*
signalled EOF. Unfortunately protocol 3 doesn't support that extension,
so we never realise this. (I suspect that SSH Communications Security
knows about this and that the 'Known Issue' regarding failed transfers
of files >4Kb using Net::SFTP relates to this bug. However, it's a damn
unclear way to put it.)
I suspect the only workaround is a new compat quirk which causes
sftp-client.c to treat short reads as equivalent to SSH2_FX_EOF
packets; this will of course render us unable to detect *real* short
reads from affected servers, since we can't tell if the server has
chosen to enable the max-read-size extension or not :/ one way a hang,
the other way possible file truncation: choose your poison.
I'll whip up a patch that does that in the next day or so.
--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
Summary: sftping files from SSH Tectia Server 6.0.0 hangs
forever
Classification: Unclassified
Product: Portable OpenSSH
Version: 3.9p1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: sftp
AssignedTo: bitbucket@mindrot.org
ReportedBy: nix-corp@esperi.org.uk
Created an attachment (id=1482)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1482)
Trace of sftp hanging
(Note that despite the ancient version attached to this log, from code
inspection I am reasonably certain that the 'bug', if such it may be
called applies to 5.0p1 as well.)
On March 7th SSH Communications Security, Inc released SSH Tectia
Server 6.0.0. sftping files from this system fails with the trace
attached (with private info such as pathnames and filenames replaced
with [...]).
The file in question here is 8764 bytes long, but once the server's
sent that, requests for more data do not lead to it sending us an
SSH2_FX_EOF status packet, but rather a packet of length *zero*. This
doesn't let us make any forward progress, so we keep requesting more
data forever. From the user's POV, sftp freezes solid with a saturated
network.
I suspect that the problem is that this server hasn't been tested
against sftp clients supporting protocol 3, and it's violating the
protocol spec by ignoring both the negotiated protocol version *and*
the fact that (due to the protocol version) it hasn't been able to
engage in 'supported2' negotiation, and is assuming that the
'max-read-size' extension is available. Under that extension, it *has*
signalled EOF. Unfortunately protocol 3 doesn't support that extension,
so we never realise this. (I suspect that SSH Communications Security
knows about this and that the 'Known Issue' regarding failed transfers
of files >4Kb using Net::SFTP relates to this bug. However, it's a damn
unclear way to put it.)
I suspect the only workaround is a new compat quirk which causes
sftp-client.c to treat short reads as equivalent to SSH2_FX_EOF
packets; this will of course render us unable to detect *real* short
reads from affected servers, since we can't tell if the server has
chosen to enable the max-read-size extension or not :/ one way a hang,
the other way possible file truncation: choose your poison.
I'll whip up a patch that does that in the next day or so.
--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs