| msg94226 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2009-10-18 21:22 |
| 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. |
|
|
| msg94227 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-10-18 21:52 |
| 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. |
|
|
| msg94231 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2009-10-19 08:49 |
| 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. |
|
|
| msg94232 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-10-19 11:30 |
| > 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. |
|
|
| msg119679 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2010-10-27 07:29 |
| Closing following Giampaolo's suggestion. |
|
|
| msg303820 - (view) |
Author: Albert-Jan Nijburg (Albert-Jan Nijburg) * |
Date: 2017-10-06 13:53 |
| 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. |
|
|