Rebex FTP/SSL: working with drftpd servers

0 votes
asked Apr 15 by ravedome (120 points)

I'm having trouble working with drftpd servers. I can login but when I try to get the contents of a directory I get the following error: Unable to parse server response to PASV command.

Ftp configuration:

var fp = new Ftp
    LogWriter = new ConsoleLogWriter(LogLevel.Debug),
    Passive = true,
    Settings = {UseLargeBuffers = true},
    Timeout = 30000,
    SecureTransfers = true,
fp.Settings.SslAllowedSuites = TlsCipherSuite.All;
fp.Settings.SslAllowedVersions = TlsVersion.TLS12;
fp.Connect(host, port, securityMode);
fp.Login(username, password);
var files = fp.GetList();

Its the fp.GetList() that throws the exception.

Got any working samples on how to get dir contents and transfer files using drftpd ?


Applies to: Rebex FTP/SSL

1 Answer

0 votes
answered Apr 17 by Lukas Pokorny (85,050 points)
edited May 10 by Lukas Pokorny

Update: This was caused by a bug in Rebex FTP/SSL. It has been fixed in version 2017 R3.

This error indicates that DrFTPD server is using an unusual form of PASV command reply. DrFTPD is known to require a non-standard form of establishing passive mode data connections (which involves a custom PRET command), but this should already be supported.

Could you please create a communication log showing this issue and either post it here or mail it to for analysis? That should make it possible to tell what is going on.

commented Apr 17 by ravedome (120 points)
log file has been sent to
commented Apr 20 by Lukas Pokorny (85,050 points)
We asked for additional information using e-mail on Tuesday, but received no reply so far.

The relevant reply to PASV command looked like this: "227 Entering Passive Mode (xxx)"
There are two possibilities. If this was in fact in the original log, it would explain the issue - "xxx" is definitely not an IP address, which makes this reply unparsable.
However, it seems more likely that the original log contained something else, which you replaced in order not to disclose sensitive data.
Unfortunately, doing this would have made it impossible for us to figure out what is going on.

Is this actually what the server sent? If not, would it be possible to send us a slightly more faithful representation of the original response?
commented Apr 20 by ravedome (120 points)
Yes, I replaced sensitive data such as user, password and ip with xxx
commented Apr 21 by Lukas Pokorny (85,050 points)
This turned out to be caused by a bug in Rebex FTP/SSL. Sorry for inconvenience, and thanks for bringing this to our attention. Please download the hotfix and give it a try:
commented Apr 27 by ravedome (120 points)
The fix works
commented May 10 by Lukas Pokorny (85,050 points)
We just published version 2017 R3 that incorporates this fix: Thanks for bringing this issue to our attention.