[jcifs] Re: SMB URL

[Christopher R. Hertel]

On Wed, Sep 12, 2001 at 10:54:46PM +0200, Luke Kenneth Casson Leighton wrote:
:
> > My original thought was
> > to use smb:// for SMB over NBT and cifs:// for SMB over native TCP.  
> 
> that is very sensible.

That's what I thought...

> > I was, er, convinced that one URL form could handle both.
>  
> no it can't.  was the following issue raised:
> 
> at some point, netbios is going to be deprecated
> [maybe 15 more years?]
> 
> at that point, port 139 is going to be unused.

Your argument is understood.  As you pointed out, SMB/NBT semantics allow
for redirection of a service request to another port.  This can be done in
an RFC1001/1002 compliant way or, as has been pointed out to me, via port
redirection (eg. using ssh).  Note that you could redirect to port 445.

Also, as far as I know there is nothing to stop someone from running
cifs/tcp filesharing on some port other than port 445--say, er, 139.  I
don't know if W2K or WXP provide ways to make that happen, but again one
could redirect at a firewall, for example.

That said, the port number is not sufficient in any case--even today--to
distinguish between semantics.

> at _that_ point, or possibly even earlier, ms
> may decide to 'do away' with the NetBIOS session
> request, and simply skip straight to what is
> now the exclusive domain of port 445, which
> i will refer to as cifs/tcp.  [and will also
> refer to what is now the exclusive (except
> for port redirection requests) domain of
> port 139 as smb/nbt.]

I consider that point to be here and now.  The solution, which is as
kludgy and as ugly as most solutions in the CIFS world, is to try the
NetBIOS session request and, basically, ignore the result.  Note that
Samba (and, probably, TNG) doesn't care if it gets a NetBIOS session
request or not.  Therefore, these servers support both smb/nbt and
cifs/tcp semantics--from the server side--out of the box.

> at that point, it will become necessary to
> distinguish between cifs/tcp and smb/nbt -
> _on the same port number_, for legacy
> reasons.

Yes.  As stated, I think we are already at that point.

Note that complete implementation of the the SMB URL format--as currently
specified--already requires a good deal of semantic twiddling.  For
example, consider what must be done to figure out what

  smb://name.this.that/

means.

- It could be a NetBIOS name.  It is only 14 characters long so it could
  mean that the scope is "", or the scope is "that", or the scope is
  ".this.that".  Which is it?  We don't know, as the only dot-related
  restrictions are applied at the application layer, not at the lower
  layers.  Sigh.

  + If it's a NetBIOS name (no matter how it's parsed), then is it a
    server name or a workgroup name?  We're overloaded, so we allow
    either.

- It could be a DNS name.  (For that matter, the string "192.168.101.50"
  could be a NetBIOS name, a partially qualified DNS name [these days
  number-only names are allowed--ick], or a DNS name--double ick].

  + It could represent a W2K Domain, in which case we might try requesting
    the Active Directory service list, just as we would have requested the
    browse list if it had been a NetBIOS name.

  + If it's a DNS name or IP address, it might still point to an smb/nbt
    service.

Very ouch.  We have to try a lot of combinations until we get a "hit".  
This is true (though slightly less so) even if we don't allow cifs/tcp
semantics.


> also, what happens if you get a port redirection
> response from an smb/nbt server on port 139 which
> tells you to connect to port 445?

Right.

> even if netbios is not deprecated, how do you
> detect the difference between cifs/tcp:portnumber
> and smb/nbt:portnumber at the moment?

Right.

> oh, what, if it's port 139 then it's _definitely_
> smb/nbt, and if it's port 445, then it's _definitely_
> cifs/tcp?

No.  Definitely not.  Your argument is quite correct and using port number
to identify semantics is a very bad idea.

> uh...
> 
> so i think that it is incredibly important to have
> the distinction between the cifs/tcp style [netbios
> sessionless] and smb/nbt style [full netbios] file
> sharing, and for this to be reflected in the
> url naming convention.

That was my original direction.  Again, I have two (TWO!) vendors already
implementing this the other way.  I tend to agree with you, and I would
prefer to use smb:// for smb/nbt and cifs:// for cifs/tcp.  Since this is
an open process, it is reasonable for me to have to state a very clear
reason that the two must be distinct.

Since any client may try the NetBIOS Session Setup and may further handle
an error as well as it handles success (that is, simply ignore the result
and proceed), I have no solid argument that says smb:// and cifs:// can't
be used for both types of SMB transport.

The only sticking point is access to the browse list.  That's handled
under smb/tcp.  I do not know how to do this under cifs/tcp so I don't
know if we can easily add this additional layer of overloading.

Oh, I should mention that one way to handle a lot of this is to start
multiple queries at the same time (I think that's what we do in jCIFS).  
For example, when given "name.this.that" one might do:

  NBT query for "name<1D>" in scope "this.that" (broadcast)
  NBT query for "name<20>" in scope "this.that" (broadcast)
  NBT query for "name<20>" in scope "this.that" (NBNS)
  DNS query for "name.this.that"

..all at the same time.  Furuther queries for

  NBT query for "name.this.that<1D>"
  NBT query for "name.this.that<20>"

might also be done at the same time, or could be delayed in hopes of
reducing network traffic.

This is why I include a SCOPE tag as an option for the ? query field.

> otherwise, you're going to have to add an extra
> parameter that says, "hey, i _know_ this is on
> port 139, but i _really_ want a cifs/tcp style
> netbios sessionless here.  pleeease?"

Yes, that makes sense.  I was thinking of

NBT="TRUE|FALSE"

> > That said, the original smb:// URL form was [is] designed to handle both
> > SMB shares *and* browse list access.  So:
> > 
> >   smb://           - would return the list of local workgroups.
> 
> cool idea.
>
> >   smb://workgroup/ - would return the servers in the workgroup.
> 
> urr... not obvious.

Richard Sharpe originally came up with most of this.  I'm working on
refining it.  The idea is to be able to do in a browser (eg. KDE's graphic
shell) what you can do when you click the Network Neighborhood.  That is,
traverse the somewhat twisted hierarchy from workgroup to servers in a
workgroup to shares in a server to directories, etc. and back up again.

Yes, it's overloaded and a little kludgy, but this is the SMB/CIFS
protocol suite we're talking about...

> >   smb://server/    - would return the shares offered by the server.
> 
> well, that's just like a directory listing, so if you treat the
> shares as directories, then it's obvious.

Exactly.

> my concern is that you'd have to distinguish the server-list in
> the workgroup from a directory listing.

That can be done semantically.  The underlying implementation knows which
service type it contacted to get its information.  How it chooses to
display the information (to distinguish a workgroup from a server) is
application-specific.

Note that there is one very nasty piece here, and that is:  It is rare
(and indicates a misconfigured NBT network) but possible that both
name<1D> and name<20> will exist within the scope of the network.  Ugly,
but true.  An application must have a means for dealing with such
occurances.

> Content-type=text/servers for a server list and
> Content-type=[usual directory format] for shares and directories

Not needed, since the client application uses different semantics to
retrieve the information so it knows which type of data it recieved.  
Also, the above would need to come from the server, and I don't know of
any SMB servers out there that would support it.

The SMB URL is entirely a client-side syntax.  Applications which
implement support for this format will be talking to Windows, TNG, Samba,
etc.

> > Yes, that's overloaded.  It's also convenient and there are mechanisms
> > (outlined in the draft appendix) for determining whether smb://name/
> > represents a workgroup or a server.  The mechanisms are semantic, rather
> > than syntactic, and do involve some network traffic.
>  
> don't think it's going to be enough.

That is exactly the question.

> for example, on an NT5 PDC, RestrictAnonymous defaults to 0x2.

I don't understand what you're saying here.

> this terminates any possibility of performing anonymous
> browse list requests.

Ah.

> according to the appendix c, you must not treat a smb_name
> as a workgroup if there is any auth info sent.
> 
> conflict :)

Hmmm... Well, that may have to change.  :)

That's why it's a draft, after all.

So, if you *do* supply auth info, then you can access the browse list?

Thanks!

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