[last?] Re: nmbd & netbios name -> many addreses

Pierre MONDIE pm at univ-evry.fr
Fri Mar 12 14:57:06 GMT 1999


	I am definitively unaware of how Samba handles all this, but 

>> >From the point of view of the NetBIOS system (and we'll ignore the
>> mulitple virtual LANAs that NT uses--thanks to John T for explaining that
>> bit of bloop), there is no NBNS, no routing, no IP addresses.  It only
>> knows NetBIOS names.
>
>.. and the separation is done very poorly.  a multi-homed nt machine
>actually receives MULTIPLE requests and goes "argh, a duplicate name
>exists on the network, ERROR, can't browse that workgroup!" when in _fact_
>it's receiving its own response, but from another subnet!!!!!

You've got it, but I agree with the following too. WINS name registration
proxying and NetNeigh Segment master browser lists replication through
mechanisms designed to provide browsability through MS NT Domains aren't
related to each other.

>peter, this could possibly be part of the problem, not samba.

This is also a workstation side network neighb param. problem. NetNeibgh is
a LAN, peer-to-peer oriented protocol, using "elections". This implies that
from the centralized SAMBA PoV, an admin wishing to be the boss on this
service must find a way to control every station parameters. A known-good
method to handle thos is MS-DHCP options that allow you to set node mode (p
is générally what an admin thug wants), "WINS" servers, NetBIOS scope (a
darn cool feature for multiple IP networks over a single physical Eth bus).
SAMBA PoV principle about netneigh "elections" seems to be : "I don't want
elections I wanna be the Boss, shappap you shoggy wkstas". This can work if
The Boss can handle all possible elections therefore can work only if every
workstation know the Boss for what it is.

Furthermore, NetBIOS name registration and net. neighb aren't related to
each other. NetNeighb is a pure NetBIOS service : every node wishing to use
it must have a "NetBIOS unique name". Every NetBIOS node must register its
name to one of its local NBNS servers beofre using this name. The only
thing a netNeighb client does is to say "Hello local NetBIOS network : I'm
DUMMY<00>, could please the guy in charge of maintaining the browse list
(Segment Master Browser aka SegMB) send it to me ?".

The MS wksta then sums the different lists it got from every query on every
NetBIOS->NetworkProtocol binding, then shows the list to the App. layer.

Don't forget that MS stations also wish to become potential browsers :-),
answering "Hey, Dummy<00>, know what ? The SMB's dead, here's the list I
got from it some time ago : I forgot, guys, what about new elections ?" and
the packet storm comes again.

An MS Windows station with MS Lan Client can NOT handle multiple NetBIOS
names : this is by design.

So what is MS philosophy on this ?

MS assumes every combination of LAN/protocol has some kind of a good SegMB
and WINS server. This is cool because a NTServer is required for each LAN.
Of course, the MS admin can handle WINS databases replications. If, during
replication, a given WINS server sees a record concerning a NetBIOS name it
already knows, it just ignores it.

And guess what ? It works like MS wants : with an NT server on every net,
even if multiprotocol over NetBIOS envs., except in SOME precise cases :

-a PDC, which is by also design the Domain Master Browser -father of SegMBs
has multiple IP. In fact, THE PDC is always the DomMB. By design, DomMB is
an unique name, and if recorded on a NBNS database.
-A NetBIOS node tries to register itself twice to the same *physical* NBNS
-in fact, unique NBNS database, through multiple bindings between NetBIOS
names to IPadress each referencing the SAME physical NBNS box -whatever
mechanism they use to join it : the first will succeed, the other won't,
and the 2nd NetBIOS bind 2nd will fail. MS servers implementations does not
allow multiple instances of NBNS servers, one bent to one IP and the other
to another IP.

>> The LAN on which those names exist is "created" by
>> the local broadcast name resolution system and the NBNS server.  It's that
>> level in between the TCP/UDP/IP protocols and the NetBIOS protocols--the
>> level at which NBNS exists--that I'm calling an emulation.
>
>ok.
> 
>> I do think we're in sync here.

--
Pierre MONDIE : SSR : 74-78


More information about the samba-technical mailing list