Cyberduck Mountain Duck CLI

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#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 8 years ago by dkocher

  • Description modified (diff)

comment:2 in reply to: ↑ description Changed 8 years ago by 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.

comment:3 Changed 8 years ago 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 8 years ago by dkocher

  • Description modified (diff)

comment:5 Changed 8 years ago by dkocher

I can replicate this issue. The underlying error is

Illegal sftp packet len: 71585

comment:6 Changed 8 years ago 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 8 years ago by dkocher

Possible duplicate of #3395.

comment:8 Changed 8 years ago by bbaker

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

comment:9 follow-up: Changed 8 years ago 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 8 years ago 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 8 years ago by dkocher

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

Last edited 8 years ago by dkocher (previous) (diff)

comment:12 Changed 8 years ago 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 8 years ago 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: Changed 8 years ago by bbaker

  • Resolution thirdparty deleted
  • Status changed from closed to reopened

comment:15 in reply to: ↑ 14 Changed 8 years ago 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 8 years ago by dkocher

  • Summary changed from Incompatibility with Globalscape EFT Server to Illegal sftp packet len. Incompatibility with Globalscape EFT Server

comment:17 Changed 8 years ago by dkocher

Duplicate issue in #5396.

comment:18 Changed 8 years ago by dkocher

Added reference to this issue in the wiki documentation.

Note: See TracTickets for help on using tickets.
swiss made software