https://bugzilla.mindrot.org/show_bug.cgi?id=3664
Damien Miller <djm@mindrot.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |djm@mindrot.org
Resolution|--- |WORKSFORME
--- Comment #1 from Damien Miller <djm@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
Damien Miller <djm@mindrot.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |djm@mindrot.org
Resolution|--- |WORKSFORME
--- Comment #1 from Damien Miller <djm@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs