Home Forums .NET libraries Xceed SFTP/FTP for .NET FTP for .NET: Cannot open data connection

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #20777 |

    We are evaluating Xceed FTP for .NET in order to enable our software to download files from a secure FTP site, however our code fails to obtain a directory listing or to download files encountering the error “Cannot open data connection. (reply code 425)”. I do not believe our code is at fault because the Xceed sample “Client Ftp” program encounters the exact same error when using the same settings. I do not believe this is a firewall issue because I can successfully obtain directory listings and download files from the same secure FTP site using the “Core FTP” FTP client on the same machine using equivalent settings.

    The output from the Xceed Client Ftp program is as follows:
    < 220 Gene6 FTP Server v3.7.0 (Build 24) ready…
    > AUTH TLS
    < 234 AUTH command ok; starting SSL connection.
    > PBSZ 0
    < 200 PBSZ=0
    > PROT P
    < 200 PROT command successful.
    > USER xxxxxxxxxxxxxx
    < 331 Password required for xxxxxxxxxxxxxx.
    > PASS xxxxxxxxxxx
    < 230 User xxxxxxxxxxxxxx logged in.
    > PWD
    < 257 “/” is current directory.
    > TYPE A
    < 200 Type set to A.
    > PASV
    < 227 Entering Passive Mode (xxx,xxx,x,xx,xxx,126)
    > LIST
    < 425 Cannot open data connection.
    (selected Passive Transfer, Representation Type: Binary, Secure Connection: Explicit TLS Authentication)

    The successful output from the Core FTP client is as follows:
    Welcome to Core FTP, release ver 1.3c, build 1447.4 (U) — © 2003-2006
    WinSock 2.0
    Mem — 1,047,556 KB, Virt — 2,097,024 KB
    Started on Wednesday June 14, 2006 at 12:43:PM
    Resolving http://ftp.stortextfm.com&#8230;
    Connect socket #468 to xxx.xxx.xx.xxx, port 2125…
    220 Gene6 FTP Server v3.7.0 (Build 24) ready…
    AUTH SSL
    234 AUTH command ok; starting SSL connection.
    TLSv1, cipher TLSv1/SSLv3 (AES256-SHA) – 256 bit
    USER xxxxxxxxxxxxxx
    331 Password required for xxxxxxxxxxxxxx.
    PASS **********
    230 User xxxxxxxxxxxxxx logged in.
    SYST
    215 UNIX Type: L8
    Keep alive off…
    PWD
    257 “/” is current directory.
    PBSZ 0
    200 PBSZ=0
    PROT P
    200 PROT command successful.
    PASV
    227 Entering Passive Mode (xxx,xxx,x,xx,xxx,87)
    xxx.xxx.x.xx -> xxx.xxx.xx.xxx
    LIST
    Connect socket #748 to xxx.xxx.xx.xxx, port 50007…
    TLSv1, cipher TLSv1/SSLv3 (AES256-SHA) – 256 bit
    150 Data connection accepted from xx.xxx.xxx.xxx:1273; transfer starting.
    226 Transfer ok.
    Transferred 321 bytes in 0.015 seconds
    (selected Auth SSL, SSL Listings, SSL Transfers, PASV)

    Any ideas?
    Thanks,
    Rob Armitage

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Robert (had 5910 views)

    User (Old forums)
    Member
    Post count: 23064

    Turns out the problem was the remote FTP server was incorrectly returning its INternal IP address in response to the PASV command. The CoreFTP client handled this by ignoring the incorrect address and using the original address in its place.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Robert (had 338 views)

    User (Old forums)
    Member
    Post count: 23064

    Is there a way to force the FTP client to use the public IP address for passive transfers? I have a customer with an FTP server that incorrectly returns its private IP address. With another FTP component, I was able to set a property that forced it to use the public IP address for all commands.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by ChristianASPNET (had 411 views)

    User (Old forums)
    Member
    Post count: 23064

    The only workaround to this problem is to connect in port mode, that is, not passive. However, if the client is behind a firewall, it might not work properly.

    For the passive mode, if the communication is not encrypted (not a secure connection) it might work. The reason for this is that the firewall sniffs the FTP commands passing through, and modifies them as required so the right IP address is used. When using a secure connection, the commands are encrypted, thus the firewall cannot sniff the commands and make the appropriate changes.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 279 views)

    User (Old forums)
    Member
    Post count: 23064

    Yes, this is a secure FTP over SSL connection, and port mode will not work.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by ChristianASPNET (had 5706 views)

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.