FTP - Problems sind update to Alexandria

[chkaufmann 17]

I use the Indy FTP client in my application. Since the update of the compiler to Alexandria 11, Update 1, one of my client gets the following error when the Put() command is called:

 

Opening BINARY mode data connection.

 

I have no idea, how I can fix that because I cannot reproduce it on FTP servers I work with.

 

The strange thing is, it worked fine as long as I compiled my application with Delphi Seattle.

 

Any hints?

 

Christian

[Fr0sT.Brutal 897]

Enable the most detailed logs as possible.

Is the error constant or random? Is TLS involded?

[chkaufmann 17]

20 minutes ago, Fr0sT.Brutal said:

Enable the most detailed logs as possible.

Is the error constant or random? Is TLS involded?

They use plain FTP.

 

And about logging, maybe a stupid question: Do I have to build this on my own? I can find the TIdLogBase / TIdLogFile classes, but I don't find examples where I can activate logging for FTP.

 

Christian

[Fr0sT.Brutal 897]

Have you looked for log usage in Indy docs? Usually such client classes have some logger property; however I've no idea with Indy.

Do Indy versions in working and failing app versions differ?

Anyway logging should decrease the guess area as now it's too broad. Maybe Indy in D11 asks for active data connection by default which is blocked by firewall.

[chkaufmann 17]

I recompiled the application with Sydney and now I get the same error with the customers server. Here is the full log:

Stat Connected.
Recv 21.11.2022 20:49:55: 220 Microsoft FTP Service<EOL>
Sent 21.11.2022 20:49:55: HOST 1.1.1.1<EOL>
Recv 21.11.2022 20:49:55: 504 Server cannot accept argument.<EOL>
Sent 21.11.2022 20:49:55: USER testftp<EOL>
Recv 21.11.2022 20:49:56: 331 Password required<EOL>
Sent 21.11.2022 20:49:56: PASS ********<EOL>
Recv 21.11.2022 20:49:56: 230 User logged in.<EOL>
Sent 21.11.2022 20:49:56: FEAT<EOL>
Recv 21.11.2022 20:49:56: 211-Extended features supported:<EOL> LANG EN*<EOL> UTF8<EOL> AUTH TLS;TLS-C;SSL;TLS-P;<EOL> PBSZ<EOL> PROT C;P;<EOL> CCC<EOL> HOST<EOL> SIZE<EOL> MDTM<EOL> REST STREAM<EOL>211 END<EOL>
Sent 21.11.2022 20:49:56: OPTS UTF8 ON<EOL>
Recv 21.11.2022 20:49:56: 200 OPTS UTF8 command successful - UTF8 encoding now ON.<EOL>
Sent 21.11.2022 20:49:56: TYPE I<EOL>
Recv 21.11.2022 20:49:56: 200 Type set to I.<EOL>
Sent 21.11.2022 20:49:56: SYST<EOL>
Recv 21.11.2022 20:49:56: 215 Windows_NT<EOL>
Sent 21.11.2022 20:49:56: TYPE I<EOL>
Recv 21.11.2022 20:49:56: 200 Type set to I.<EOL>
Sent 21.11.2022 20:49:56: CWD /testsplash<EOL>
Recv 21.11.2022 20:49:56: 250 CWD command successful.<EOL>
Sent 21.11.2022 20:49:56: PASV<EOL>
Recv 21.11.2022 20:49:56: 227 Entering Passive Mode (10,0,19,1,240,228).<EOL>
Sent 21.11.2022 20:49:56: STOR MM_LiveResultFtpTest.txt<EOL>
Recv 21.11.2022 20:50:17: 150 Opening BINARY mode data connection.<EOL>
Stat Disconnected.

In InternalPut it runs fine until the call LPasvCl.Connect; Then there is a timeout and the upload fails. When I use Filezilla I get the same message, but for some reason the upload works in a second try:

Command:    STOR meet_live_ftp_Fail_Sydney.log
Response:    150 Opening BINARY mode data connection.
Error:    Connection timed out after 20 seconds of inactivity
Error:    File transfer failed
Status:    Connecting to 91.217.122.30:21...
Status:    Connection established, waiting for welcome message...
Status:    Plain FTP is insecure. Please switch to FTP over TLS.
Status:    Logged in
Status:    Retrieving directory listing of "/testsplash"...
Status:    Directory listing of "/testsplash" successful

Now it's always difficult to explain to a customer, that this is a server side problem. So I would like to have a solution, that could handle this kind of problems like Filezilla. 

 

Regards
Christian

[Fr0sT.Brutal 897]

Typical issue

Quote

Recv 21.11.2022 20:49:56: 227 Entering Passive Mode (10,0,19,1,240,228).<EOL>

Server is incorrectly configured reporting its internal IP to external client.

If touching the server is not an option at all, look for client option to ignore that IP in PASV and always use main server address for connection. You may also change the command to EPSV which is more modern kind of making data connection that doesn't require server IP at all.

Edited November 22, 2022 by Fr0sT.Brutal

[Remy Lebeau 1260]

15 hours ago, Fr0sT.Brutal said:

If touching the server is not an option at all, look for client option to ignore that IP in PASV and always use main server address for connection.

TIdFTP has a PassiveUseControlHost property for that exact purpose.  It is False by default.

15 hours ago, Fr0sT.Brutal said:

You may also change the command to EPSV which is more modern kind of making data connection that doesn't require server IP at all.

TIdFTP has a UseExtensionDataPort property to enable use of EPSV if the server supports it.  This is also False by default.

[Dan1979 0]

On 11/23/2022 at 1:56 AM, Remy Lebeau said:

TIdFTP has a PassiveUseControlHost property for that exact purpose.  It is False by default.

TIdFTP has a UseExtensionDataPort property to enable use of EPSV if the server supports it.  This is also False by default.

Sorry to interfere but since you mentioned both options here I jump to ask you quick. If needed I will make a new thread.

No matter what I do after I connect to a VSFTPD server be it on Docker or on an Ubuntu Linux Machine, LIST command timeouts if I don't use either PassiveUseControlHost or UseExtensionDataPort set to True.

I can connect from other clients like Filezilla or Total Commander, but I cannot get Directory Listing unless I use one of the two above options.

According to my logic, regardless if vsftpd has a pasv_address set to my external ip, the ftp client receives a (0,0,0,0,val1,val2) on PASV command in filezilla and my delphi code won't be able to solve this situation unless I use one of the two above options.

Also, I set 

listen_ipv6=NO
listen=YES

in vsftpd.conf but that doesn't seem to help the issue being solved.

In my opinion I should set something either in vsftpd.conf or in delphi so that the IdFTP can properly connect using passive mode.

Please help with this issue.

[Dan1979 0]

I can't believe that I wasted 2 days trying to change Delphi/Docker/Linux VSFTPD options to find out that the pasv_address was the IP from home instead of the one from Work where I have the Linux machine installed...

Sorry for wasting your time, hopefully others will not do the same as me.. 😞

Edited June 21, 2023 by Dan1979

[Fr0sT.Brutal 897]

Well, you always can look at what server sends. FTP is really easy for humans. This way you'd spot the issue in a moment

[Dan1979 0]

23 hours ago, Fr0sT.Brutal said:

Well, you always can look at what server sends. FTP is really easy for humans. This way you'd spot the issue in a moment

For me was a bit of an unfortunate situation:

Filezilla and Total Commander was working correctly because they were both not using pasv_address ip specified by the server when connecting, and in my mind I was sure that if they connect then the pasv_address is correct, This was cause I didn't know that both clients don't use that pasv_address probably after checking their validity and failing at it. Since both clients worked correctly there was no log error to check for.

On the other hand, I probably should have checked the logs made by idFTP but I only caught exceptions and checked their error message instead. Probably here I was wrong to not check logs.

Long story short now it makes sense that from Delphi the it only worked if I forcefully fallen back to the host ip. 

I apologize if you wasted any time checking my issue... Cheers