smb://

[Christopher R. Hertel]

> There's one scenario I'm still concerned may pose a practical problem, I'm
> hoping someone can tell me if this is a real danger or not.  Most SMB clients
> on a Netbios network that spans subnets are hybrid nodes; they will query a
> WINS server, and fall back to broadcast if the name is not found.  However,
> particularly on networks lacking centralized IT (e.g., university networks),
> it's possible to have a hybrid node that shares a subnet with (misconfigured)
> broadcast nodes.  If a machine on a remote subnet registers the server name
> BLEE with the WINS server, and a machine on the local subnet declares itself
> the LMB for workgroup BLEE, then I believe existing clients will be able to
> ignore the conflict and see both workgroup BLEE and server BLEE.  If we
> overload <name> in the URL smb://<name>/ to mean
> either-a-workgroup-or-a-server,-depending, then one of the two above will not
> be addressable with a URL (well, unless you default to workgroup and address
> the server by name).

Yes, you would have a problem.  As you point out, though, this is a
misconfiguration.  RFC1001/1002 warn against it as being very, very bad. 
It messes up the namespace.  You could solve the problem by putting a WINS
proxy on your local LAN. 

I just sent out a message regarding the special handling of the Local 
Master Browser name by WINS.  Basically, you can only find an LMB via 
broadcast.  So, if you have an H node, it will find the server before it 
finds the (misconfigured) LMB.

Note, too, that if even *one* of the members of workgroup BLEE is 
configured to see the WINS server, then you will get a name conflict and 
the problem is solved.  Hmm... for that matter, if *no* member of 
workgroup BLEE can use the WINS server...

Right.  You can have this situation:
A local LAN which contains a workgroup named BLEE.
A remote subnet with an H or M mode server named BLEE.
Since the two do no see each other, they are in separate name spaces and 
immune to each other.

Enter an H-mode node in workgroup SPOO on the same IP subnet as workgroup
BLEE.  It calls for "smb://", and will get "BLEE" in the list.  If it now 
calls for "smb://BLEE/" will it get the workgroup or the server?

Note first that this is *still* considered an improperly configured 
network by RFC standards.  Also, a WINS proxy would fix the problem.  
However, the other solution is to try both BLEE#1D and BLEE#20.  If you 
get replies from both then list both.

> This is a pathological scenario, but I know first-hand that there are plenty
> of pathological Windows networks out there in the world. 

Most certainly.

> Question is, does this configuration work with existing clients, and if
> so, what do we do about it?

Basically, it's a messed-up namespace.  The client node can see both the
local B nodes and remote nodes that use the WINS server, but the remote
nodes cannot see the local B nodes and vice versa, which is bad all
around.  It's not just workgroup and server names.  In this situation, our
client might be able to see two servers with the same name.  Once
registered locally via B mode, and one from a remote subnet via the WINS
server. 

> Do we ignore the problem and blame it on the broken network, or do we
> adapt the URL syntax so that we never have to query the network to resolve an
> ambiguity?

My suggestion is punt.  This is fairly standard for SMB and related 
protocols.  As described, list both.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz