https://bugzilla.mindrot.org/show_bug.cgi?id=3664 Bug ID: 3664 Summary: sftp Product: Portable OpenSSH Version: 9.4p1 Hardware: amd64 OS: Mac OS X Status: NEW Severity: minor Priority: P5 Component: scp Assignee: unassigned-bugs at mindrot.org Reporter: rossmck at mac.com Created attachment 3787 --> https://bugzilla.mindrot.org/attachment.cgi?id=3787&action=edit debug3 log I will preface this by saying it *may* be an issue on the server, but the vendor is adamant it is the client implementation, citing FileZilla and WinSCP having no problems with the same operation. However, I believe OpenSSH will have a more compliant implementation of the protocol. The sftp client app is hanging when copying a file from a server which supports a maximum packet of 32768. Attached is a (slightly anonymised) debug log of such a session. I amn't familiar enough with OpenSSH but from the below; scp: debug3: Request range 0 -> 32767 (0/1) channel 0: rcvd big packet 32781, maxpack 32768 This looks like we asked for the range 0-32767 but received a length of 32781 in response? Is there some additional overhead here and, if the limit on length - imposed by the remote side - of a packet is 32768 should sftp have requested a shorter range? Or is the remote implementation broken? -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3664 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |djm at mindrot.org Resolution|--- |WORKSFORME --- Comment #1 from Damien Miller <djm at mindrot.org> --- This is a bug in the remote implementation. OpenSSH does use a maximum channel packet size of 32KB however this limit is not relevant to applications that use ssh as a transport, such as sftp. The interface that the channels protocol presents to application is an ordered stream, and applications (like sftp) don't see or need to care about the packet size at all. In fact, SFTP implements its own framing because it runs over a stream interface rather than a packetised interface. I think what is happening here is that the remote implementation has confused these two concepts and mixed channel framing with SFTP framing, and this has caused it to violate the maximum packet size when replying to a SFTP request. If you want to yell at your vendor, these are the relevant section of the RFC that specify the use of the maximum packet size: https://datatracker.ietf.org/doc/html/rfc4254#section-5.1 https://datatracker.ietf.org/doc/html/rfc4254#section-5.2 -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3664 --- Comment #2 from rsmck <rossmck at mac.com> --- Many thanks, that's sort of what I expected but thanks for the clear explanation - the channel vs sftp framing makes perfect sense. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.