[jcifs] Re: SMB URL

Christopher R. Hertel crh at ubiqx.mn.org
Fri Sep 14 13:28:27 EST 2001


On Thu, Sep 13, 2001 at 04:42:05PM -0700, Conrad Minshall wrote:
:
> So if there were any systems already doing this then you'd know it is
> possible and you'd capture packets to see the details.

Well, yes and no.  I think it's all possible.  My biggest concern is that
full support of both browsing and filesharing over both NBT and non-NBT
transports using one unified URL scheme is going to take forever.

Consider:  cifs://name/  (equivalent to smb://name/)

To figure out what this means we need to do this:

  Send a NetBIOS query for name<1D> and for name<20> unless 'name' is
  longer than 15 characters and does not contain dots.

    If there are no dots in the first 16 characters then it cannot be a
    NetBIOS name.  Assume DNS...

    If it contains dots then it could be NetBIOS name with scope.  For
    example, if it's "neko.cat.org" (which is only 12 characters) then we
    need to try:  neko<1D>.cat.org, neko<20>.cat.org, neko.cat<1D>.org,
    neko.cat<20>.org, neko.cat.org<1D>, and neko.cat.org<20>.  Ouch.
    ...and yes, there are versions of Windows that allow such names, ugly
    as they are.  The order I gave is also the obvious order in which to
    try the combinations as NetBIOS names with dots are uncommon.

    Oh, and there are both broadcast and NBNS (WINS) queries to be
    considered.

    The name could be a DNS name or even an IP address.  IP addresses will
    also have dots (and be made up of numbers and dots only), while
    partially-qualified DNS names may or may not have dots.  The DNS name
    does not need to match the NetBIOS name, BTW.  

    If 'name' is not a NetBIOS name then we will assume that it is either
    a DNS name or an IP address.  We send an NBT Node Status Request to
    see if we get a list of NetBIOS names back in a response.  Then we
    need to look through the list to see if there is a <1D> name or a <20>
    name (unique names only).  If we get a response, then we can assume
    NBT semantics.

    Subtotal:  If the name is a NetBIOS name (we got a response to an NBT
               name query) or if it is *not* a NetBIOS name but we
               received a reply to the Node Status Query, then we can
               assume NBT semantics.

               - If we have a <1D> name then we look for a browse list.
               - If we have a <20> name then we look for a share list.

  ...but if we have no proof that we are talking NBT, then what?

  First, we know we don't have a NetBIOS name.  That's some help.  
  Further, it is fair to assume that the remote node is not using NBT.
  (This is not absolutely true.  Someone could, for example, run Samba's
  smbd without running nmbd which would result in *no* responses to
  queries even though SMB over NBT services are running.  Some firewalls
  could cause the same problem.)

  Note, by the way, that the decision to use port 139 or port 445 is made
  based on whether or not we detect NBT.  Now that I think of it, there is
  no reason to try both ports *if* we go to the trouble of discovering
  NBT by sending queries.

  Okay, so we have the IP address of a remote node that we assume is not
  running NBT transport.  It *could* be a W2K Domain Controller, so
  we'll try to ask it for a browse list.  (Luke touched on how this is
  done--LDAP queries, RPCs, etc.)  The node could be a W2K server
  offering services on port 445, so we can try connecting to that too.

  ...what happens if we get *both*?  Do we return the browse list or the
  share list?  Fortunately, we have guidance from the NBT case.  In a
  misconfigured or otherwise annoying NBT network the preferred behavior
  is to return both, though an application may optionally choose to
  return only the share list.

The issue here is that all of the above takes time.  Possibly lots of
time.  I don't know how much time and I don't know how much in different
situations (such as Luke's 56Kbaud modem).

Oh, and after all that, we still haven't talked about things like
authentication (Kerberos under W2K) and other differences in the
supporting protocol suites.

> Then what you are
> concerned about is that it might be possible with seperate smb/cifs prefix
> semantics but impossible with them unified?  Help me see how that can be...

Not exactly.  I am trying to explain the problem so that it can be solved.  
If it can be solved in a reliable and non-user-impacting (read: reasonably
fast) way then I have no argument.

In fact, the reason I am pushing this is so that we can *prove* to
ourselves that it either can or cannot be done in a practical way.

> can't any wire traffic possible under the non-synonomous URL definition be
> attempted, with success, given synonomous URL prefixes?  My apologies if
> I'm missing something obvious - I'm still quite new to these protocols.

See above.  I am really asking the same question except that I am adding
two things to your question:  "Can it be done quickly enough that it does
not impact the user?"  and  "Can it be done reliably enough that it does
not impact the user?"

I don't know about "something obvious", but the way I think of this is
along the lines of

  "If I can get to the food co-op and back in under 20 minutes and I can
  get to the farmer's market and back in under 20 minutes, then can I
  visit both in under 20 minutes?"

If they were next to each other, yes I could.  They happen to be in
opposite directions so no, I can't.

Likewise with the unified URL.  As described above, I think it can be
done.  The question is, can it be done quickly and reliably enough that it
makes sense?

With two separate, non-overlapping URL forms we have workable solutions.
They're still ugly (see the appendices of the current draft), but we know
it can be done in a reasonable timeframe.  Combining the URL forms into
one looks do-able, but the problem is multiplied.

Keep talking folks.  This is a pain but I think we'll be glad when we get
through it.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org




More information about the jcifs mailing list