[
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.
