Opened on Oct 12, 2010 at 10:52:40 PM
Closed on Oct 14, 2010 at 2:41:30 PM
Last modified on Dec 11, 2010 at 4:51:50 PM
#5308 closed defect (thirdparty)
Illegal sftp packet len. Incompatibility with Globalscape EFT Server
Reported by: | bbaker | Owned by: | dkocher |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | sftp | Version: | 3.6.1 |
Severity: | normal | Keywords: | |
Cc: | Architecture: | ||
Platform: |
Description (last modified by dkocher)
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?
Change History (18)
comment:1 Changed on Oct 13, 2010 at 7:26:54 AM by dkocher
- Description modified (diff)
comment:2 in reply to: ↑ description Changed on Oct 13, 2010 at 7:27:40 AM by dkocher
comment:3 Changed on Oct 13, 2010 at 7:28:03 AM by dkocher
- Component changed from core to sftp
- Owner set to dkocher
- Summary changed from Cyberduck unable to perform remote directory listing to Unable to perform remote directory listing
comment:4 Changed on Oct 13, 2010 at 7:29:01 AM by dkocher
- Description modified (diff)
comment:5 Changed on Oct 13, 2010 at 7:30:19 AM by dkocher
I can replicate this issue. The underlying error is
Illegal sftp packet len: 71585
comment:6 Changed on Oct 13, 2010 at 8:36:54 AM by dkocher
Refer to common problems with SFTP. Let me know if there is a .bashrc file that might be cause the trouble.
comment:7 Changed on Oct 13, 2010 at 8:37:06 AM by dkocher
Possible duplicate of #3395.
comment:8 Changed on Oct 13, 2010 at 1:19:14 PM by bbaker
Our SFTP software is running on a windows system so no .bashrc file.
comment:9 follow-up: ↓ 11 Changed on Oct 13, 2010 at 10:17:26 PM by 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
comment:10 Changed on Oct 14, 2010 at 7:27:53 AM by dkocher
- Description modified (diff)
- Summary changed from Unable to perform remote directory listing to Incompatibility with Globalscape EFT Server
comment:11 in reply to: ↑ 9 Changed on Oct 14, 2010 at 7:35:26 AM by 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.
comment:12 Changed on Oct 14, 2010 at 7:38:09 AM by dkocher
- Resolution set to thirdparty
- Status changed from new to closed
Please get in contact with their support and reopen this ticket if you have new findings.
comment:13 Changed on Oct 14, 2010 at 1:20:19 PM by 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
comment:14 follow-up: ↓ 15 Changed on Oct 14, 2010 at 1:22:15 PM by bbaker
- Resolution thirdparty deleted
- Status changed from closed to reopened
comment:15 in reply to: ↑ 14 Changed on Oct 14, 2010 at 2:41:30 PM by dkocher
- Resolution set to thirdparty
- Status changed from reopened to closed
Replying to bbaker:
I can reproduce the issue here. Possibly they have fixed the bug but have introduced a regression since.
comment:16 Changed on Nov 4, 2010 at 1:33:21 PM by dkocher
- Summary changed from Incompatibility with Globalscape EFT Server to Illegal sftp packet len. Incompatibility with Globalscape EFT Server
comment:17 Changed on Nov 4, 2010 at 2:52:11 PM by dkocher
Duplicate issue in #5396.
comment:18 Changed on Dec 11, 2010 at 4:51:50 PM by dkocher
Added reference to this issue in the wiki documentation.
Replying to bbaker:
Duplicate for #2944.