[
https://issues.apache.org/jira/browse/NET-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-588.
----------------------
Resolution: Fixed
Fix Version/s: 3.6
Thanks for the report and the PR.
Applied:
URL: http://svn.apache.org/viewvc?rev=1782074&view=rev
Log:
NET-588 FTPClient.setPassiveNatWorkaround assumes host is outside site local
range
Modified:
commons/proper/net/trunk/src/changes/changes.xml
commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClient.java
commons/proper/net/trunk/src/test/java/org/apache/commons/net/ftp/FTPClientTest.java
> FTPClient.setPassiveNatWorkaround assumes host is outside site local range
> --------------------------------------------------------------------------
>
> Key: NET-588
> URL: https://issues.apache.org/jira/browse/NET-588
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.1, 3.3, 3.4
> Reporter: Dave Nice
> Fix For: 3.6
>
>
> We have a NAT firewall between two "site local" 10.x networks. The effect is
> that the FTP library tries to make data connections to the wrong host because
> the passive NAT workaround doesn't operate if the FTP connection is made to a
> "site local" private address and the host returned in the PASV reply is also
> "site local".
> I see that Damon Dan references pretty much the exact issue within bug
> NET-363 when the workaround was originally introduced.
> Users with "site local" networks would be quite at liberty to subnet within
> the network, I guess, to suit their administrative needs, so this seems like
> a valid issue.
> Options I can see:
> 1) Include a way of forcing the workaround in place
> 2) Remove the selectivity around rewriting the host only if the PASV reply is
> "site local" and original host isn't... Issue here is around a server that
> has multiple endpoints for data connections?
> 3) Allow the user to specify their own data host via API
> 4) Check for whether the PASV reply address is in a different subnet to the
> original host we connected to and apply the workaround if so
> I haven't yet identified a workaround within the current code!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
