> 21 aug 2014 kl. 08:47 skrev Brian Trammell <[email protected]>: > > Now the problem would remain -- how, in an interfaceless environment, can the > tcpinc machinery tell passive from active FTP in advance? One possible > approach here would be to detect a failed active FTP transaction, then rely > on the application to try again and remember to disable itself for the second > attempt (kind of like Valery's option 4, but with fallback). > > Of course this leads to the type of implementation complexity I was hoping to > avoid through deprecation. I still think any pressure we can exert to speed > active-mode FTP's retirement is effort better spent than effort building > fiddly bits into tcpinc (Valery's option 6) for this corner case.
This have been an issue for a implementors of RFC 2228 (FTP Security Extensions) and RFC 4217 (Securing FTP with TLS) so nothing really new under the sun here for ftp implementors, active mode have always been an issue with firewall and nats. The implementations I’ve touched have had fallback code to the other mode in case of failure, usually trying PASV first. Love _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
