CIFS archives -- September 2001, week 2 (#14)

Christopher R. Hertel crh at
Fri Sep 14 13:44:04 GMT 2001

Paul, you said:

> Why is it necessary to take this approach?  It would be overly
> restrictive on implementers, and requires the spec to detail exactly how
> name resolution and directory service must be provided. 

The specification will not dictate how service name resolution should be
done, but it should provide an example of how such resolution *might* be

It *must* dictate which outcome will result from which strings in which
situations.  There cannot be any ambiguity there.  The meaning of the URL
string is inherent in the definition of the URL scheme, not in (possibly
differing) implementations. 

That's why I need your input.  If you implement the URL string one way and
we wind up specifying it another way then the URL strings become useless 
because they don't mean the same thing from system to system.

In an updated draft, what we are trying to achieve is this:

CIFS: == SMB:  - the two URL prefixes mean the same thing.

cifs://        - gives the list of local workgroups, the root of the 
                 local W2K Domain service hierarchy.  [No one has yet 
                 shown me how to do this.]

cifs://name/   - gives the following:
                 + If name is a NetBIOS workgroup name, the list of servers
                   in the workgroup.  [I know how to find this out.]
                 + If name is a NetBIOS server name, the list of shares 
                   offered by the server.  [I also know how to discover 
                 + If name is a DNS name or IP address, then:
                   = If the remote node is offering SMB services on port
                     139, then the list of shares.  [We can simply try to 
                     connect to the port.]
                   = If the remote node is offering CIFS services on port
                     445, then the list of shares.  [Again, simply try to
                   = If the remote node is a W2K Domain Controller, then
                     a list of servers in the W2K Domain (browse list).
                     [I don't know how this is done but I assume, once
                     again, that we would just try to connect.]

                 Worst case that's three NetBIOS queries (with possible
                 repetitions), one DNS lookup, and three TCP connection
                 attempts before we even know what service we're talking

               - Under the assumption that browse services are not 
                 redirected to alternate ports we can reduce the above 
                 problem to one of simply figuring out which semantics 
                 are used on the port.  I think this can easily be done
                 by sending an NBT Session Setup request and ignoring
                 the reply if its an error.

                 On the other hand, what if someone does redirect service 
                 listings (the browse list) to another port.  Sigh.  That 
                 puts us back to the previous case (cifs://name/).

               - Workgroups do not offer shares, as far as I know, so 
                 this would only be a file service connection.  If we 
                 know that 'name' is an NBT name then we might try port 
                 139 first.  Otherwise, use Luke's suggestion and try 139 
                 first if "smb" is the prefix, else try 445 first.

The problem with the above--and the one I am trying to solve--is that I 
need to know that the 'cifs://name/' format can be made to work without 
causing long delays and annoying the user.

My original suggestion was to separate old SMB and new CIFS semantics 
using two different URL schemes.  My thought was that by splitting the 
two environments we could reduce the problems to managable ones.  I am 
not against creating a "unified" scheme.  I just need to know that it 
*can* be done in a reasonable way.

Most of all, I need to fill in the above outline with explanations of what
*might* happen on the wire to figure out which kind of service is

Chris -)-----

More information about the samba-technical mailing list