[Samba] Re: Understanding the role of DMB/LMB on a net that has
a WINS server
John H Terpstra
jht at samba.org
Thu Oct 9 21:33:38 GMT 2003
On Thu, 9 Oct 2003, David Wuertele wrote:
> John> Have you read chapter 10 of the Samba-HOWTO-Collection.pdf?
> What I have already read is this:
> It looks like they contain the same text as the PDF to which you
> refer. Is it safe to assume that the HTML version I read is current?
> John> If this document does not clearly answer your questions please
> John> let me know so I can fix it.
> Question 1.
> Section 10.2 says:
> "To most people browsing means they can see the MS Windows and Samba
> servers in the Network Neighborhood, and when the computer icon for a
> particular server is clicked, it opens up and shows the shares and
> printers available on the target server."
> >From this, I gather that "browsing" is the act of enumerating and
> resolving published share names. Therefore, a workstation that
> doesn't publish any shares, and just uses smbclient or smbmount to
> access other servers' shares, must also make use of "browsing."
> Section 10.7.1 says:
> "Samba facilitates browsing. The browsing is supported by nmbd and is
> also controlled by options in the smb.conf file. Samba can act as a
> local browse master for a workgroup and the ability to support domain
> logons and scripts is now available."
> I was not able to discover whether nmbd is *required* to be running on
> a workstation that doesn't publish any shares, and just uses smbclient
> or smbmount to access other servers' shares.
Yes, nmbd is required - it provides the name resolution services for smbd.
> Question 2.
> The closest thing I found to a description of the actual process that
> a client goes through in order to "browse" was in 10.3.2 "TCP/IP
> without NetBios". This didn't go into any detail about the client's
> logic, but it did give the search order. Why this chapter is labeled
> "without NetBios" is unclear, since one of the client steps is to
> "3. Check the NetBios name cache". I couldn't find where it describes
> what a name cache is, but I guess it doesn't matter because the
> section that I really care about is 10.3.1 "NetBIOS over TCP/IP". But
> 10.3.1 does not go into detail of the client's resolution process.
In the absence of NetBIOS over TCP/IP the sole mechanisms for name
resolution are to use DNS or LDAP lookups. LDAP lookups involve DNS. This
means that when NetBIOS over TCP/IP has been disabled DNS becomes the
dominant factor in name resolution.
> For example:
> If I have a client that wants to enumerate and access shares on a
> subnet, and that client knows the IP of the WINS server, is there any
> need for the client to use the "browsing" services of a DMB or LMB?
A WINS server is nothing more than a resolved for NetBIOS names to
matching IP Addresses. WINS is to NetBIOS names what DNS is to fully
qualified domain names. WINS has NO knowledge of what machines are
available on a partciluar subnet - that is the role of the LMB.
The DMB simply collates all names that have been registered with all the
LMBs on the network. The DMB then updates the LMB with the names it
obtained from other LMBs.
> What is the order of operations of the client? Here is what I imagine
> to be the case:
> 1. client asks LMB for a list of all available shares
a) Client broadcasts for the LMB. Asks for an enumerated list of
> 2. LMB sends client the list of all known shares
b) Client finds from enumerated list (or from user input) a machine to
c) Client will ask WINS server to provide the IP Address of that machine
name. If no WINS server is present, client will broadcast to local network
segment seeking the owner of that name to respond - when owner responds
the client knows what IP Address the response came from.
d) Client connects to the IP Address and establishes a null session (null
user and null password) and asks for an enumerated list of resources.
> 3. for each name in the list of known shares, client asks WINS
> server for the server's IP address
WINS servers have no knowledge of shares. Have a look at the contents of
the wins.dat file on your samba server!
> 4. WINS server replies with each name resolution
It resolves only NetBIOS names to IP Addresses.
> I can't find anything in
> that describes what is really happening at this level. I also could not
> find anything that says whether LMBs or DMBs actually do name
> resolution. I also don't understand why we need LMBs if we can always
> access a DMB. I also could not find anything in this document that
> talked about the difference between Microsoft's "B" "M" "P" and "H"
LMBs provide only enumerated lists of machines on the local segment and
any machines that are present on remote network segments as obtained from
the DMB. LMBs provide the DMB with locally registered authoritative names.
WINS does name resolution, LMBs provide lists of machines only. You need
On the segment that has the PDC the LMB is generally the DMB.
The LMB and DMB functionality are service level roles alone. The DMB role
is purely browse list synchronization. The LMB role is purely to provide
lists of machines. The WINS server purely resolves names to addresses.
We did not set out to write a definitive book on every technical aspect of
the networking protocols. Suggest you refer to "Implementing CIFS: The
Common Internet File System" by Christopher Hertel (available from
Amazon.com). This book goes into the nuts and bolts of the protocols. The
Samba-HOWTO-Collection is NOT a book that is targetting a network
> If there is a WINS server, does there still have to be an LMB and DMB?
Yes. All three are implicit in the NetBIOS over TCP/IP protocol.
> If there is an LMB, why does the client need to access the WINS server
Because LMBs provide lists of machines and WINS does name resolution.
> Why not just have the LMB do the resolution?
Because that is not the role of the LMB. We did not write the protocol
specification! NetBIOS over TCP/IP is a horribble mess!
> It would result in less traffic.
Tell Microsoft, IBM, 3Com - they wrote the protocol.
Microsoft wrote the servers and clients that behave the way they do - the
samba-team did not do this, we simply set out to implement compatible
- John T.
John H Terpstra
Email: jht at samba.org
More information about the samba