[jcifs] Re: SMB URL
Christopher R. Hertel
crh at ubiqx.mn.org
Thu Sep 13 20:25:07 GMT 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 samba-technical
mailing list