<div dir="ltr">Thank you very much Mike! Its a firewall issue.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 6:42 PM, Michael B Allen <span dir="ltr"><<a href="mailto:ioplex@gmail.com" target="_blank">ioplex@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 7, 2015 at 11:12 AM, Dev <<a href="mailto:vendeve@gmail.com">vendeve@gmail.com</a>> wrote:<br>
> Michael B Allen <ioplex <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
>> Hi Stefan,<br>
>><br>
>> I believe the "connection in error" condition will only occur if you<br>
>> try to reuse the same transport after it just choked. Then, just in<br>
>> case the server suddenly becomes alive at some point, it resets the<br>
>> connection state. Thats why you then go back to "connect timed out". I<br>
>> never really liked that behavior because it seems clumsey to ping-pong<br>
>> between two different errors. But it's not obvious to me that anything<br>
>> is logically wrong with this behavior. Think about it. If you try to<br>
>> connect to a server and it chokes, why mindlessly try to connect to<br>
>> the same server again? You should have some logic in your code that<br>
>> catches the exception and just removes all targets on that server from<br>
>> the list for the current scan.<br>
>><br>
>> So I would say that with some adjustment to your code as described<br>
>> above and combined with using responseTimeout > connTimeout, that<br>
>> should give you correct results.<br>
>><br>
>> If you're still not getting the desired result, please explain what<br>
>> you think the correct results should be.<br>
>><br>
>> Mike<br>
>><br>
><br>
><br>
><br>
> Hi Michael,<br>
><br>
> I am getting the below exception when I try to use JCIFS-1.3.17.jar.<br>
>  Please let me know what is the<br>
> resolution.<br>
<br>
Hi Dev,<br>
<br>
Easy. Fix the network / other end to accept the connection.<br>
<br>
> Also can you let me know what are the ports that<br>
>  JCIFS uses to connect to the destination<br>
> server? Is it something if we try to open the ports from source<br>
>  to destination would help?<br>
<br>
Like a firewall problem? Certainly.<br>
<br>
JCIFS uses TCP port 445 [1].<br>
<br>
Mike<br>
<br>
[1] Techincally JCIFS actually fails over to port 139 if 445 is not<br>
available. But I don't know of any servers that only listen on 139.<br>
Maybe some really old version of Samba. So port 139 can / should just<br>
be ignored because if 445 doesn't work, 139 won't either.<br>
<br>
--<br>
Michael B Allen<br>
Java Active Directory Integration<br>
<a href="http://www.ioplex.com/" target="_blank">http://www.ioplex.com/</a><br>
<br>
> osgi.wiring.package=*) -> [0]<br>
> jcifs.smb.SmbException: Failed to connect: 0.0.0.0(00)/<a href="http://10.12.212.41" target="_blank">10.12.212.41</a><br>
> jcifs.util.transport.TransportException: Connection timeout<br>
>         at jcifs.util.transport.Transport.connect(Transport.java:174)<br>
>         at jcifs.smb.SmbTransport.connect(SmbTransport.java:307)<br>
>         at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)<br>
>         at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)<br>
>         at jcifs.smb.SmbFile.connect(SmbFile.java:954)<br>
>         at jcifs.smb.SmbFile.connect0(SmbFile.java:880)<br>
>         at jcifs.smb.SmbFile.open0(SmbFile.java:972)<br>
>         at jcifs.smb.SmbFile.open(SmbFile.java:1006)<br>
>         at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:73)<br>
>         at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:65)<br>
>         at<br>
</blockquote></div><br></div>