[jcifs] RE: FW: Connecting to DFS Roots

[Daniel Palmer]

Yep, I started with the Technical info on DFS from there - but I then
went looking for more on the workings of MUP - as those docos say MUP is
the part which determines if the UNC path is to be handled by DFS or by
the Windows Networking component.  What the MUP info I found said that
to determine if it's a DFS share, you ask for a DFS referral.  I've just
been testing here.  Using dfsutil I did a /PurgeMupCache /PktFlush and
/SpcFlush (not sure which of these are relevant) - then captured
connections to several network shares which were *not* DFS roots.   In
all cases the after connecting to IPC$ windows does a GET_DFS_REFERRAL
which returns STATUS_NO_SUCH_DEVICE and then proceeds on it's merry way
doing a usual tree connect.

So to answer your question 1: how does explorer know to ask for a DFS
referral - it just tries it first.  I'm sure this would be a fairly
simple thing to implement in JCIFS - but I haven't looked through the
code far enough to see if there is any DFS referral cache.  It's kind of
over-kill to do a get dfs referral for *every* connection - so it would
be good to cache the result and only check the first time that base
share is encounted.  I'm guessing this is prob a 2.x job :)

Dan

> -----Original Message-----
> From: Michael B Allen [mailto:mba2000 at ioplex.com] 
> Sent: Thursday, 31 March 2005 12:34 PM
> To: Daniel Palmer
> Cc: jcifs at samba.org
> Subject: RE: FW: Connecting to DFS Roots
> 
> 
> Daniel Palmer said:
> > Just been doing some reading to help with my own understanding.
> >
> > OK - windows has a UNC path.  First thing it does with it 
> is pass it 
> > to MUP.  What I found interesting is the first thing MUP 
> does with the 
> > path (at least according to 
> > http://www.zacker.com/articles/mup/mup.html) is to check if 
> it is a DFS share.  It doesn't even try to connect to the
> > server / share using the Windows Networking redirector.    
> I just found
> > it interesting that DFS is the first port of call - and it 
> seems that 
> > jCIFS does the opposite (try connecting as a normal server.  If no 
> > good try DFS).
> >
> > I could be way off base here - I've only been playing 
> packet sniffer 
> > for about a day ;)
> 
> At some point the client must discover that a path is "in 
> dfs". Once it does it gets a "referral" and puts the path and 
> the referral path into a map. From that point on, whenever 
> the client tries to access a path it first checks the map. 
> JCIFS and I'm sure all other DFS capable clients behave the same way.
> 
> I don't think the documentation you founds is what your 
> looking for. I think Microsofts website is a better bet:
> 
http://www.microsoft.com/WindowsServer2003/technologies/fileandprint/fil
e/dfs/default.mspx

Your captures did not show the discovery process. But I noticed some IPs
have changed. In one capture the ip for trinity.local and shadrach are
the same. I think the paths you're interested in are in a DFS cluster.
It is not a vanilla DFS redirect. There is more going on.

Unfortunately, whatever the case is I cannot fix it. The 1.x branch is
locked down. There has to be a pretty serious bug (security flaw) for me
to do a release at this point and I consider this problem to be a
feature enhancement.

I would very much like to hear about what you find. There's always 2.0.
If you're good with Java you could probably make it work without too
much trouble provided you can answer those 3 questions I posed.

Mike