PRET (PRE Transfer) command

[cyberduck]

anonymous created the issue

Some servers, for example drftpd, requires PRET support when connecting in passive mode. It's basically a command that is sent before transfers to inform the server that the client is about to do something.

More info: http://www.drftpd.org/index.php/Distributed_PASV#Solution:_PRET_.28PRE_Transfer.29_command

---

Attachments

• feat_patch (0.7 KiB)
• pret_patch (1.6 KiB)

[cyberduck]

398449a commented

I made a little patch in order to make Cyberduck compatible with PRET enabled ftps, it just send a "PRET command" command before any of the commands specified in the PRET specifications (http://drftpd.org/index.php/PRET_Specifications).
The command is sent without checking for any reply, if the server doesn't support the feature, then an error message is sent to Cyberduck and nothing happens.
Let me know if something is wrong, i'm not an experienced coder but the patch is really small.

[cyberduck]

@dkocher commented

Thanks for the patch. I have some notes on this:

• Should only be sent if the response to FEAT contains PRET.
• The client is only required to send a PRET command before PASV

[cyberduck]

398449a commented

Replying to [comment:5 dkocher]:

a) yes that's what the specs says, but I've seen some servers not spitting out the PRET inside the FEAT command, I think it's better trying to issue a PRET command anyway, in the worst case, we just get a "not implemented" error, and the connection goes on. Also I saw you have a nice "features()" function, but I didn't understand when and if it's called.

b) from the specs: "Must be sent before the PASV and ONLY the PASV command. PRET is unneccessary to be sent before any other command, although it can help enable a security feature on clients using Active transfers." so, leaving PRET enabled also for Active connections is not a bad thing. Anyway, adding a check to see if the connection is passive and, only in that case, issue the PRET command is just a matter of add some "if", so if you think it's better, I can add this check.

[cyberduck]

@dkocher commented

Thanks for comment. I have commited 9f2ecf9 which makes use of PRET if it is listed in response to FEAT. Needs testing as I don't have access to a drftpd server.

[cyberduck]

398449a commented

an error has been introduced, the server I use for test, allows the use of the FEAT command only to authenticated users:

220 DrFTPD 2.0.2 http://drftpd.org
FEAT
530 Not logged in.
220 DrFTPD 2.0.2 http://drftpd.org
FEAT
530 Not logged in.

[cyberduck]

@dkocher commented

Replying to [comment:8 neothematrix]:

> 220 DrFTPD 2.0.2 http://drftpd.org
> FEAT
> 530 Not logged in.
> 220 DrFTPD 2.0.2 http://drftpd.org
> FEAT
> 530 Not logged in.

Fixed in b5f5e4b.

[cyberduck]

398449a commented

ok, working perfectly now, just a note, now the FEAT command is sent before ANY createDataSocket, not just the first one
you didn't save the "features" variable correctly, I wrote a fix :) wow I like patching eheh
btw, do you have some additional documentation? I'd like to add support for external IP detection and the selection of a range of ports for the PORT command (in order to make PORT command works behind firewalls)

[cyberduck]

@dkocher commented

Replying to [comment:10 neothematrix]:

ok, working perfectly now, just a note, now the FEAT command is sent before ANY createDataSocket, not just the first one
you didn't save the "features" variable correctly, I wrote a fix :) wow I like patching eheh
btw, do you have some additional documentation? I'd like to add support for external IP detection and the selection of a range of ports for the PORT command (in order to make PORT command works behind firewalls)

Thanks for watching :) Fixed in 0268892. I don't have any more documentation, but you may find at [enterprisedt.net].