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-b...@mindrot.org Reporter: ross...@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. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs