Created attachment 1482 [details]
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.