[Bug 1458] New: sftping files from SSH Tectia Server 6.0.0 hangs forever

[bugzilla-daemon at bugzilla.mindrot.org]

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 at mindrot.org                                  
        ReportedBy: nix-corp at 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.