Hello Rick,

client: Windows 11, VFP 9.0 legacy code (character mode)

server: new AWS Lightsail (one public IP, one private IP), Windows 2019, ftp server under IIS: 127.x.x.x (private IP) no host name

wwclient: V 7.27

code:

    o=Create("wwftp")  

    m1ftphost = '52.x.x.x'   && public IP
    m1ftppass = 'xxxxxxx'
    m1ftpuser = 'xxxxx' 
    o.nftpport = 2121
    o.nftpbinary=0    && 0 - ascii, 1 - binary
    o.lpassiveftp = .t.
    mfrom = 'wwsets.dbf'
    mto = 'wwsets.dbf'
    mreturn = o.ftpsendfile("&m1ftphost","&mfrom","&mto","&m1ftpuser","&m1ftppass")

mreturn = 12003

o.cerrormsg = 227 Entering Passive Mode (172,26,0,207,42,182)

o.ftpsendfileex(..) produced the same error.

In other testings with the same setup, I was able to connect (passive mode too) and create a new directory off the ftp root with no problem; but the o.aFTPDir(..) command will return 0 entries of a known folder with files.

However the same file upload works under Filezilla with no problem.

Help appreciated,

Steve Yu, long time developer in Houston

If you're using the IIS server I think you don't want to use passive mode. If you get that error that seems to suggest the server doesn't support passive mode.

+++ Rick ---

Same error if I set passive mode to .f. in VFP

Filezella will also fail in active mode and throw error 501

501 Server cannot accept argument. Error: Failed to retrieve directory listing

correction: VFP will throw 501, same as FileZilla if passive mode is off.

Don't know other than I know passive mode works because i've been using it for years with various upload routines. Make sure that Anti-Virus and Firewall are not interfering - AV especially can potentially block connections from 'unknown' non-white listed applications. Also make sure you are referencing the path correctly. Use a root relative path ("/somepath") rather than a relative path to ensure that you're not sitting in some unexpected auto-set folder on the server when connecting.

That said, in v8.0 Web Connection switched to a more modern FTP client (.NET based) mainly in order to support the ftps:// protocol, but also to work around some of the awkwardness of the Windows built-in WinInet protocols which have been on deprecation support for close to 10 years now.

Maybe give the sharewere version of v8 a try and see if that works better (using wwFtpClient)

+++ Rick ---

Thank you, Rick.

Will try the new version and see.

Great utility and life saver to enable legacy VFP to integrate with modern systems.

Regards,

Steve Yu

Just want to let you know we figured out the problem. We did not fill in the public IP (the host IP of the wwftp process) in FTP Firewall Support of the ftp site under IIS. That was all there is needed to get rid of the 12003 error.

It's always the firewall or Anti-Virus 😢