[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues
[
https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887253#action_12887253
]
Sebb commented on NET-313:
--
I suspect that the reversion to using PASV for IPv4 was to maintain backwards
compatibility.
Would it work for you to make it an option to try EPSV on IPV4?
That could easily be added when the patch is applied.
The other parts of the patch look good.
FTP: EPRT fails + EPRT/EPSV issues
--
Key: NET-313
URL: https://issues.apache.org/jira/browse/NET-313
Project: Commons Net
Issue Type: Bug
Components: FTP
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.
[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues
[
https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885632#action_12885632
]
Don Goertzen commented on NET-313:
--
Encountered issue with EPRT incorrectly sending port as 0 instead of the
actual port that the ServerSocket is listening on. This is always going to
fail, and normally would fall back to the PORT command. However, in my case the
FTP server (FileZilla) is terminating the connection when it encounters the
invalid EPRT command rather than returning an error response, so the PORT
command never even gets a chance to run. As mentioned in the description,
server.getLocalPort() should be used here, rather than getActivePort().
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.
[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues
[
https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873680#action_12873680
]
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: 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.
