I have come accross an FTP server which lftp (an Unix command-line
client) handles well but ftplib doesn't. Both ftplib and lftp are
configured to use passive mode (this server apparently doesn't handle
non-passive), but the address sent in response by the server is a
private IP. Here is a wireshark transcript of the FTP conversation done
by lftp:

220 172.29.AAA.BBB FTP server ready

FEAT

211-Features:
 LANG en
 MDTM
 UTF8
 AUTH TLS
 PBSZ
 PROT
 REST STREAM
 SIZE

211 End

LANG

200 Using default language en

OPTS UTF8 ON

200 UTF8 set to on

USER XXXX
331 Password required for ftth_rdvph

PASS XXXX
230 Connexion reussie pour ftth_rdvph

PWD

257 "/" is the current directory

PASV

227 Entering Passive Mode (172,29,AAA,BBB,195,84).

LIST

150 Opening ASCII mode data connection for file list

226 Transfer complete



As you see, lftp had no problem opening a data connection. It probably
notices that the address advertised in response to PASV doesn't respond
(after e.g. a 2s. timeout), and falls back on the host's known address
instead. In contrast, ftplib simply sits while the connection is
attempted and bails out at the end with a connection error.

At least we could add an optional argument to set_pasv() so as to ignore
the host provided by the server. Here is a patch proposal.

If the server is behind a NAT it should be up to the administrator to
properly configure it so that the internal address gets replaced in
PASV/EPSV replies.
Any FTP server provides this possibility.
IMHO, this is not in the realm of problems which should be dealt by
ftplib. It's just server's fault.

> If the server is behind a NAT it should be up to the administrator to
> properly configure it so that the internal address gets replaced in
> PASV/EPSV replies.
> Any FTP server provides this possibility.
> IMHO, this is not in the realm of problems which should be dealt by
> ftplib. It's just server's fault.

Yes, probably. The point was only that lftp seemed to be able to handle
it, so I thought that maybe ftplib could be enhanced to match that.

Closing following Giampaolo's suggestion.

I understand the standpoint that the server is configured incorrectly, and I see why this might not be the best solution to the problem. 

But not everyone owns the ftp server they're connecting to. And the `EPSV` command often doesn't include the ipaddress, so many ftp clients are now using `EPSV` to circumvent the problem of the ip address and the dns address not matching up.

Would it not be sensible to give users the option to use just `EPSV` so people can connect to incorrectly configured ftp servers. Although this can't be a massive issue for people, because I'd expect this bug to be a bit more active. 

Curl for example defaults to EPSV and then falls back to PASV when it's not supported by the server. The ftp client in macos also defaults to EPSV. I'm not sugesting we do that, but it would be nice if we could tell the ftplib to use EPSV without it being a ipv6 address. 

In our specific situation, we have an ftp server that has a public and a private endpoint on different ip addresses, and the ftp server is configured to use the public ip address, but if we want to access in internally we need to use the internal host and ip address. This causes `ftplib` not to work, because the ips don't line up. 

We currently monkey patch ftplib to use `EPSV`, but it does state that you need to use EPSV when you connect with ipv6 it doesn't say you can't use it when you use ipv4.