[Fwd: Re: [jcifs] Re: SMB URL]

Luke Kenneth Casson Leighton lkcl at samba-tng.org
Thu Sep 13 08:37:01 EST 2001


On Wed, Sep 12, 2001 at 05:03:30PM -0500, Christopher R. Hertel wrote:
> 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.
 
precisely.

> > 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.  

TNG only activates cifs/tcp on port 445, by replacing
the not-received-netbiosname with gethostname().

> 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.
 
so, this is a good justification to support
smb://... to represent smb/nbt, regardless of
port number, and
cifs://... to represent cifs/tcp, regardless of
port number.

> 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.
 
well, if it's cifs://... then i think you should forget
NetBIOS altogether and simply hand the name over to
the ip/dns resolver.

if it's smb://... then you should follow the standard
ms-specified rules (the one about whether the name is
over 15 chars etc etc etc) which isn't an issue or
anything different from what you've outlined in
the draft rfc.


> > 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.
 
gooood.

> > 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.  

oh, dearie me.  well, they'll be non-conformant with
the rfc, then, won't they, which will cause them problems,
including losing sales because it doesn't interoperate
with other products that _do_ conform to the rfc specification.


> 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.

yep.

> Since any client may try the NetBIOS Session Setup and may further

NetBIOS session request, not setup.

> 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.
 
well, that's good enough.  saving round-trips - over the internet -
is a big enough reason.

i mean, microsoft removed the NetBIOS session request to save
a round-trip because they added CAP_EXTENDED_SECURITY which
resulted in an extra round-trip being added, net result, no
additional round-trips.


> The only sticking point is access to the browse list.  That's handled
> under smb/tcp.  

you mean smb/nbt, i hope :)

> 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.
 
well, you _can_ fall back to the same methods as used in
smb/nbt, except you can't do anonymous browse lists when
RestrictAnonymous = 0x2.

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

> > 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"
 
it's messy, but it'd do the job.

different semantics for smb://... and cifs://... is
a lot cleaner.

> > > 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.  

cool.

> 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...
 
teehee :)

> > >   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.
 
urr... *click*.

oh, i'm stupid.  i'm thinking this would be coming from
a web page *grin*.

> The SMB URL is entirely a client-side syntax.  Applications which
> implement support for this format will be talking to Windows, TNG,
> Samba,
> etc.
 
yehyeh, i realise that now :)  getting confused by the URL
syntax :)

> > 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?

correct.

try running smbclient -L nt5pdc -U% you'll find that it fails.

luke





More information about the jcifs mailing list