[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
> for redirection of a service request to another port. This can be done
> an RFC1001/1002 compliant way or, as has been pointed out to me, via
> 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.
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
> Note that complete implementation of the the SMB URL format--as
> specified--already requires a good deal of semantic twiddling. For
> example, consider what must be done to figure out what
> - 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
> - 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
> the Active Directory service list, just as we would have requested
> 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
> 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
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
> 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
> 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
> 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
NetBIOS session request, not setup.
> an error as well as it handles success (that is, simply ignore the
> and proceed), I have no solid argument that says smb:// and cifs://
> 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
> 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.
> > 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
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.
> I'm working on
> refining it. The idea is to be able to do in a browser (eg. KDE's
> shell) what you can do when you click the Network Neighborhood. That
> 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.
> > 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
> service type it contacted to get its information. How it chooses to
> display the information (to distinguish a workgroup from a server) is
> 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
> > 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.
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,
yehyeh, i realise that now :) getting confused by the URL
> > 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.
> > 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?
try running smbclient -L nt5pdc -U% you'll find that it fails.
More information about the jcifs