commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mirko Nasato (JIRA)" <>
Subject [jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues
Date Mon, 31 May 2010 14:44:38 GMT


Mirko Nasato commented on NET-313:

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:
>             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|])
> what my patch does:
>  * (re)enable EPSV command on IPv4 too (i dont know why [] 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 "",
"EPRT |1||0|"
> Tue Mar 23 17:17:20 2010 [pid 10581] [ftpuser] FTP response: Client "",
"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.

View raw message