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

Filipe Bojikian Rissi commented on NET-649:
-------------------------------------------

I do not know how to make this error happen as it happens only on a private FTP 
server, in passive mode it should return a valid IP to make the route, but 
terona "0,0,0,0" then launches ConectionException, but that is because of the 
wrong IP, and I saw that File Zila happens the same thing, and in the log it 
informs that as the server returned an invalid IP used the IP of the server 
used in the connection.

So as I needed this fix I made a fork and implemented it just as File Zila 
reported in the log.


{code:java}
java.net.ConnectException: Connection refused (Connection refused)

at java.net.PlainSocketImpl.socketConnect (Native Method)
at java.net.AbstractPlainSocketImpl.doConnect (AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress 
(AbstractPlainSocketImpl.java:204)
at java.net.AbstractPlainSocketImpl.connect (AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect (SocksSocketImpl.java:392)
at java.net.Socket.connect (Socket.java:589)
at org.apache.commons.net.ftp.FTPClient._openDataConnection_ 
(FTPClient.java:920)
at org.apache.commons.net.ftp.FTPClient._storeFileStream (FTPClient.java:714)
at org.apache.commons.net.ftp.FTPClient .__ storeFileStream (FTPClient.java:701)
at org.apache.commons.net.ftp.FTPClient.storeFileStream (FTPClient.java:2064)
at br.com.finchsolucoes.dicasmei.application.impl.FileManagerServiceFTP.save 
(FileManagerServiceFTP.java:75)
at 
br.com.finchsolucoes.dicasmei.application.impl.FileManagerServiceFTPTest.save 
(FileManagerServiceFTPTest.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.junit.runners.model.FrameworkMethod $ 1.runReflectiveCall 
(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run 
(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively 
(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate 
(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf (ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild 
(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild 
(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner $ 3.run (ParentRunner.java:290)
at org.junit.runners.ParentRunner $ 1.schedule (ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren (ParentRunner.java:288)
at org.junit.runners.ParentRunner.access $ 000 (ParentRunner.java:58)
at org.junit.runners.ParentRunner $ 2.evaluate (ParentRunner.java:268)
at org.junit.runners.ParentRunner.run (ParentRunner.java:363)
at org.junit.runner.JUnitCore.run (JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs 
(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner $ 
Repeater.startRunnerWithArgs (IdeaTestRunner.java:47)
at ()
at com.intellij.rt.execution.junit.JUnitStarter.main (JUnitStarter.java:70)
{code}

https://github.com/apache/commons-net/pull/28

> 227 Entering Passive Mode
> -------------------------
>
>                 Key: NET-649
>                 URL: https://issues.apache.org/jira/browse/NET-649
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.6
>         Environment: Fedora, Java 8
>            Reporter: Filipe Bojikian Rissi
>             Fix For: 3.7
>
>
> In a situation where I passed, the FTP server is restoring 227 Entering 
> Passive Mode (0,0,0,0,156,126), so it was obvious to me that the problem is 
> on the server side and not on the API, but using the File Zila client and 
> analyze the log precebi that the same problem was also happening, so he 
> changed the route to use the IP of the server that returned this information 
> and thus manages to make the route correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to