"Object reference" null exception in GetListing after building data stream fails (EPSV not supported)

[tiberius-cocarlea-nshift]

"Object reference not set to an instance of an object" is raised when connecting with passive auto mode and trying to get the file list.

Code raising exception: [FtpClient] ftpClient.GetListing(sRemoteDirectory)

Attached is the verbose log.

ftp_verbose_20260526_140927.log

[FanDjango]

[Info] Command: EPSV
[Verbose] Status: Waiting for response to: EPSV
[Verbose] Status: Disposing(sync) FtpClient.FtpSocketStream(control)

EPSV command seems to be blocked or not available.
Try using PASV instead of AutoPassive mode.

[tiberius-cocarlea-nshift]

Hi, found last year it's working with standard mode, but auto it's default when choosing passive mode. I don't want to upgrade to a version that is throwing null object exceptions.

[robinrodricks]

It could be the security changes. Can u update to the latest version and see if any exceptions are thrown?
Also I'm not seeing any null exception in the log. Where is it??

[Verbose] >         OpenDataStream("LIST /Test/Out", 0)
[Verbose] >         OpenPassiveDataStream(AutoPassive, "LIST /Test/Out", 0)
[Info] Command:  EPSV
[Verbose] Status:   Waiting for response to: EPSV
[Verbose] Status:   Disposing(sync) FtpClient.FtpSocketStream(control)
[Verbose] Status:   GetReply(...) failure: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond..

[FanDjango]

From the log, I can see:
The response to the FEAT command shows that EPSV is not among the supported options of this server.
Thus it seems that this server responds to the FEAT command by terminating the control connection - a very nice server, phooey.
Therefore, to transfer files successfully you need to make FluentFTP not try the EPSV command before finally resorting to PASV. You need to tell it to not AutoPassive, but instead to PASV.

Looking at the code (ours), I can see:
We do not check the FEAT response as to whether EPSV is at all supported, which is a piece of smartness that AutoPassive does not possess. And handling such a brutal response to a tentative try to determine if EPSV is supported by simply entering the command is, as can be seen, too primitive. (One would need to reconnect etc. etc.) It probably was coded at a time when the respective RFCs for the FEAT command were still generally unknown.

Todo item would be to have AutoPassive also check the FEAT response before blithely trying EPSV, and this goes for all other FEAT responded commands also. For this see: https://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml. The necessary code change is rather trivial.

EDIT Check for EPSV supported: DONE

[FanDjango]

Concerning the "Object reference" null exception:
Our GetListing API call code does not react/catch the suddenly closed connection correctly and trys to access a result of its GetReply call, the returned object is null.

Todo item would be to improve this. (N.b. it can be easily simulated/reproduced).

[FanDjango]

Hi, found last year it's working with standard mode, but auto it's default when choosing passive mode. I don't want to upgrade to a version that is throwing null object exceptions.

Concerning these two statements
I have some dissent whith this. You seem to have a penchant for wanting the defaults of parameters to support or be tailored to your specific use case. The defaults are there for the majority of users and not for you, in this case.

If you don't want to set PASV mode because AutoPassive is the default, then currently you will get a null object exception. We are not going to change the default for you. That's how it is. Then don't upgrade. It's your choice.

Changing the thrown exception (from null object referenced) to some other more beautiful exception won't change the current situation.

Facit, Tiberius: Opening a passive datastream should not try to use EPSV if this is not listed in the FEAT response. This will be fixed, it's on the Todo List now, but it is a devastatingly low priority, since there is a workaround (by using PASV instead of AutoConnect.

EDIT Check for EPSV supported: DONE because it was so easy.

[tiberius-cocarlea-nshift]

Hi,

I understand this is special case (maybe badly configured server???). Thank you for explaining the issue, much appreciated.
Since list files doesn't work on 52.x version too, only the behavior is different, i'll look into changing the code to either inform the user to re-configure or, automatically reconnect, using PASV mode.

[robinrodricks]

Yes since its just a matter of changing the config, I don't see any real issue here. The dev can easily make a change in the config.