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.