Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Illegal sftp packet len. Incompatibility with Globalscape EFT Server #5308

Closed
cyberduck opened this issue Oct 13, 2010 · 12 comments
Closed

Illegal sftp packet len. Incompatibility with Globalscape EFT Server #5308

cyberduck opened this issue Oct 13, 2010 · 12 comments
Assignees
Labels
bug sftp SFTP Protocol Implementation thirdparty Issue caused by third party

Comments

@cyberduck
Copy link
Collaborator

71bc844 created the issue

Unable to perform remote directory listing. One of our customers business partners is attempting to connect to our SFTP server (Globalscape EFT Server 6.2.18 Build 09.08.2010.3) using CyberDuck version 3.6.1 (6900). They are able to connect without any issues but they cannot complete a directory listing for a specific folder (product_images).

I can complete directory listings for this folder with other SFTP programs such as filezilla. I'm wondering if this may be a bug in cyberduck?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [5308 bbaker]:

By the way I tried enabling the full transcript from View -> Log Viewer but nothing seemed to be listed (the area was blank). Perhaps this only works for FTP not SFTP?

Duplicate for #2944.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I can replicate this issue. The underlying error is

Illegal sftp packet len: 71585

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Refer to common problems with SFTP. Let me know if there is a .bashrc file that might be cause the trouble.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Possible duplicate of #3395.

@cyberduck
Copy link
Collaborator Author

71bc844 commented

Our SFTP software is running on a windows system so no .bashrc file.

@cyberduck
Copy link
Collaborator Author

71bc844 commented

It appears if we reduce the number of files in the directory CyberDuck can complete a directory listing but as soon as we restore files the directory listing won't work any more.

The error message you included above sounds similar to a separate issue we experienced with Putty/Filezilla:

When PuTTY opens the data channel for the SFTP session, it sends SSH_MSG_CHANNEL_OPEN, and states a window size of 0x7FFFFFFF(2147483647) bytes but a maximum packet size of 0x4000 (32768). That is, the server is permitted to send almost any amount of data without requiring an SSH-level acknowledgment from PuTTY, but may not send an _individual packet_ larger than 32768 bytes.

The server is disregarding the specified maximum packet size, and is sending a packet of 65548 bytes. PuTTY treats this as a decryption failure, since the most common reason for the packet length to be out of range is because there was a disagreement in the bulk encryption between client and server, causing the packet length field to decrypt to random garbage data. In fact that isn't the cause of the problem in this case, but PuTTY unfortunately can't determine that by itself.

Our Secure FTP vendor (Globalscape) CLAIMS that this was fixed and we stopped experiencing this issue in filezilla/putty however is it possible that CyberDuck is encountering the same problem?

Thanks
Brad

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:9 bbaker]:

I suspect this bug hasn't been fixed but works due to workarounds for the particular vendor in PuTTY (and FileZilla which uses PuTTY). Refer to PuTTY now detects this particular server software and limits the window size it advertises in order to work around the problem.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please get in contact with their support and reopen this ticket if you have new findings.

@cyberduck
Copy link
Collaborator Author

71bc844 commented

I am already in contact with the server vendor (Globalscape) and they have opened a case and I've submitted debugging information. They insist that this bug was fixed - although I am skeptical that is the case.

None the less would it be possible for you to reproduce this and confirm that is indeed the problem. If so that will give me ammunition to get them to address this.

Otherwise we're both merely speculating that its a similar issue and that makes a weaker argument for getting them to address this.

Thanks
Brad

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:14 bbaker]:

I can reproduce the issue here. Possibly they have fixed the bug but have introduced a regression since.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Duplicate issue in #5396.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Added reference to this issue in the wiki documentation.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug sftp SFTP Protocol Implementation thirdparty Issue caused by third party
Projects
None yet
Development

No branches or pull requests

2 participants