[ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873680#action_12873680 ]
Mirko Nasato edited comment on NET-313 at 5/31/10 10:45 AM: ------------------------------------------------------------ Just stumbled into an issue with v2.1 and nf_conntrack_ftp on Linux where the connection times out and iptables logs something like May 31 14:16:38 foo kernel: [35656.336325] conntrack_ftp: partial EPRT 987422914+27 I guess this may confirm your EPRT "could even have disadvantages" prediction. Using commons-net v2.0 everything works fine. (I also wonder why there are v2.1 jars in the Maven central repository if v2.1 hasn't been officially released yet, but that's a different story.) was (Author: mnasato): Just stumbled into an issue with v2.1 and nf_conntrack_ftp on Linux where the connection times out and iptables logs something like May 31 14:16:38 foo kernel: [35656.336325] conntrack_ftp: partial EPRT 987422914+27 I guess this may confirm your IPv6 "could even have disadvantages" prediction. Using commons-net v2.0 everything works fine. (I also wonder why there are v2.1 jars in the Maven central repository if v2.1 hasn't been officially released yet, but that's a different story.) > FTP: EPRT fails + EPRT/EPSV issues > ---------------------------------- > > Key: NET-313 > URL: https://issues.apache.org/jira/browse/NET-313 > Project: Commons Net > Issue Type: Bug > Affects Versions: 2.1 > Environment: FTP server = vsftpd/Centos 5.4 > FTPClient = commons-net (FTPClient) ;) > Network = IPv4 > Reporter: Felix Bolte > Attachments: ftp_nat.patch > > > as implemented in NET-288, the client can work now via IPv6 ... EPSV is not > only useful on IPv6 but also when NAT is enabled (see [RFC > 2428|http://tools.ietf.org/html/rfc2428]) > what my patch does: > * (re)enable EPSV command on IPv4 too (i dont know why > [~rwins...@eircom.net] removed it from the supplied patch in NET-288), also > see my comments in patch > * sending EPRT only if we are over IPv6, cause there is no advantage over > PORT on IPv4, it could even have disadvantages (see comments in patch) > * EPRT was sending the result of getActivePort() to the server, but when > there was no activePortRange set, it did send 0 as default which leads to an > error on server site: > {quote} > Tue Mar 23 17:17:20 2010 [pid 10581] [ftpuser] FTP command: Client > "192.168.11.130", "EPRT |1|192.168.11.130|0|" > Tue Mar 23 17:17:20 2010 [pid 10581] [ftpuser] FTP response: Client > "192.168.11.130", "500 Illegal EPRT command." > {quote} > * and even calling getActivePort() has no sense here, cause that port is > used to be random, but we should send same port where the ServerSocket is > listening on -> server.getLocalPort() > * getActivePort() checks if __activeMaxPort > __activeMinPort, but when i > want to set a range of only one single port (min==max) it would return 0 ... > now it will check if equal and return __activeMaxPort -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.