Illegal sftp packet len. Incompatibility with Globalscape EFT Server

[bbaker]

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?

[dkocher]

Replying to 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.

[dkocher]

I can replicate this issue. The underlying error is

Illegal sftp packet len: 71585

[dkocher]

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

[dkocher]

Possible duplicate of #3395.

[bbaker]

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

[bbaker]

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

[dkocher]

Replying to bbaker:

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

[dkocher]

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

[bbaker]

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

[dkocher]

Replying to bbaker:

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

[dkocher]

Duplicate issue in #5396.

[dkocher]

Added reference to this issue in the ​wiki documentation.