The reason is that commands given with -e run after the connection, not before. Although set ftp:ssl-allow false is still a valid command once logged in, it's too late. If the remote FTP server advertised AUTH TLS, lftp will use it.
Why is this a problem? With certain firewalls, control traffic is snooped to determine which TCP data connections to permit, which breaks with TLS.
Another workaround is to edit one of the lftprc files, but this isn't always suitable in "stateless" production environments.
Suggest either that -e commands are executed before connection, or another option (-a ?) is provided with these semantics.
This doesn't work as expected:
but this is an effective workaround:
The reason is that commands given with
-erun after the connection, not before. Althoughset ftp:ssl-allow falseis still a valid command once logged in, it's too late. If the remote FTP server advertisedAUTH TLS, lftp will use it.Why is this a problem? With certain firewalls, control traffic is snooped to determine which TCP data connections to permit, which breaks with TLS.
Another workaround is to edit one of the lftprc files, but this isn't always suitable in "stateless" production environments.
Suggest either that
-ecommands are executed before connection, or another option (-a?) is provided with these semantics.(Tested with lftp 4.8.4 on Linux.)