[jcifs] Issues connecting with DFS server

[Michael B Allen]

On Tue, Oct 14, 2014 at 6:45 AM, M. D. <moder at abv.bg> wrote:
> I'm writing you in person because it is preferable that these captures won't appear in the public mailing list.

Hi M. D.,

Yes. You did the right thing. No one should ever post captures or even
logs to the mailing list. Always send them to me directly.

But now I will CC this back to the JCIFS list for posterity.

> After we analysed them we noticed something that looks suspicious to us:
>
> On node XXX.AD1.PROD/1.2.3.4:445
> errorCode=The remote system is not reachable by the transport
>
> Could you please have a look at the attached capture? Do you see anything wrong with it? We already asked our client to check the status of the DFS node running on 1.2.3.4.

Well this is not a capture. It's just a fragment of a log. To get a
capture you would have to use a program like netcap.exe or tcpdump.

But from looking at your log fragment I can see the customer's DFS is
probably slightly "broken". Specifically, JCIFS is trying to do a
Trans2FindFirst2 on the path
\XXX.AD1.PROD\SHR\some\path\that\doesnt\matter\. Meaning it's trying
to list the objects in that directory. Based on other log entries it
looks like the share SHR is actually a DFS point that maps to another
server. But it's difficult to decipher what's going on exactly because
it looks like there are multiple threads doing different things.
Ultimately the server is returning the error "The remote system is not
reachable by the transport.". Note that that error is coming from the
server. It is not coming from JCIFS. Meaning JCIFS tried to list that
directory and the server return that error.

As to what the error means, I have no idea. I have never seen that
error before. And sometimes Windows uses error codes that are not
exactly accurate. Meaning the "remote system" could mean some object
on the server was not "reachable" or something abstract like that. But
I only say that because I don't recall there being a scenario where
the server would try to contact a secondary "remote system".

A Windows client would just ignore the error and try the next host in
the DFS mapping. JCIFS doesn't do that and that's the problem. Or it
could be another bug entirely. DFS support in JCIFS is not robust when
it comes to things remotely complex or slightly "broken" scenarios
like this.

So I would just explain this to the customer and that if they really
scrutinize their DFS nodes, they might find a host in some DFS mapping
that doesn't actually have the content trying to be accessed in which
case if they fix the content or remove the host from the list, JCIFS
might start working with that path.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/