[jira] Created: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
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 [~[hidden email]] removed it from the supplied patch in NET-288 (see 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Bolte updated NET-313:
----------------------------

    Attachment: ftp_nat.patch

see ticket description

> 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 [~[hidden email]] removed it from the supplied patch in NET-288 (see 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Bolte updated NET-313:
----------------------------

    Comment: was deleted

(was: see ticket description)

> 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 [~[hidden email]] removed it from the supplied patch in NET-288 (see 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Bolte updated NET-313:
----------------------------

    Description:
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 [~[hidden email]] 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

  was:
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 [~[hidden email]] removed it from the supplied patch in NET-288 (see 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


> 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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ 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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-313:
---------------------

    Component/s: FTP

> 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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887357#action_12887357 ]

Felix Bolte commented on NET-313:
---------------------------------

hi sebb,

you are right, as EPRT could have disadvantages on IPv4,
EPSV could have them too ... default to PASV is ok

please go ahead ... an option to enable EPSV as default sounds fine to me

> 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 [~[hidden email]] 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.

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (NET-313) FTP: EPRT fails + EPRT/EPSV issues

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb resolved NET-313.
----------------------

    Fix Version/s: 2.1
       Resolution: Fixed

Thanks for the patch and info.

Applied to SVN in two different commits (see SVN history).
Added method to enable EPSV over IPv4 as discussed.

> 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
>             Fix For: 2.1
>
>         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 [~[hidden email]] 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.