8.2. Network Browsing
Browsing was developed by Microsoft to help users find shared resources on the network. In a networked computing environment where users can add or remove shares at any time, it is important to have some automatic means of keeping track of the shared resources and allowing users to "browse" through them to find the ones they wish to use.
Before browsing was added to SMB networking, when anyone added a new share, the people with whom they wished to share the data or printer would have to be informed of the share's UNC, using some relatively low-tech method such as speaking to them in person or over the phone. Already this was very inconvenient in large organizations. To further complicate matters, the users working on client computers had to type in the share's UNC to connect to it. The only way to get around typing in the share's UNC every time it was used was to map a network drive to it, and with a large number of shares on the network, this could easily get out of hand.
8.2.1. Browsing in a Windows Network
To keep things simple, we first describe network browsing in a network that contains only Windows systems, and then show you how to add a Samba server.
The basic way browsing works is that one computer in the network takes on the role of the local master browser (LMB) and keeps a list of all the computers on the local subnet that are acting as CIFS servers. You might also see the LMB referred to as the browse master, the browse server, or simply the master browser. The list of computers is called the browse list and includes Samba servers, Windows NT-based systems, and any Windows 9x systems that have the File and Printer Sharing for Microsoft Networks networking component installed. The browse list also contains the names of all workgroups and domains. At this level, browsing is limited to the local subnet, because the browsing protocol depends on broadcast packets, which are typically not forwarded to other subnets by routers.
A user at any Windows system can view the browse list by opening up the My Network Places, as you saw in Chapter 1. Alternatively, the net view command can be used from a Windows command prompt to display the servers in our workgroup:
C:\> net view Server Name Remark ---------------------------------------------------------- \\RAIN Samba 3.0.22 \\LETTUCE Lee Zard's WinXP development box \\XPOP Office Print Server \\TRINITY Office File Server The command completed successfully.
Then, net view can be used with a computer name as an argument to contact a server directly and list the resources it is sharing:
C:\> net view \\RAIN Shared resources at \\RAIN Samba 3.0.22 Share name Type Used as Comment ---------------------------------------------------------- data Disk Test share for ACLs hp2100 Print HP LaserJet 2100 Series PCL 6 lizard Disk H: Home directory of lizard netlogon Disk Net Logon service pdfgen Print public Disk P: Public Access The command completed successfully.
The computers on the network involved in browsing are more than just the master browser and its clients. There are also backup browsers, which maintain copies of the browse list and respond to client requests for it. Backup browsers are therefore able to take over the role of master browser seamlessly in case it fails. The master browser usually doesn't serve the browse list directly to clients. Instead, its job is mainly to keep the master copy of the browse list up-to-date, and also periodically update the backup browsers. Clients are expected to get their copies of the browse list from backup browsers, selecting among them randomly to help to distribute the load on the backup browsers more evenly. Ideally, the interaction between any client and the master browser is limited to the client announcing when it joins or leaves the network (if it is a server) and requesting a list of backup browsers.
There can be more than one backup browser. A workgroup will have a backup browser if two or more computers on the subnet are running a Windows desktop operating system with file and print sharing enabled. For every 32 additional computers, another backup browser is added.
In addition to acting as the local master browser, the Primary Domain Controller (PDC) acts as the domain master browser (DMB), which ties subnets together and allows browse lists to be shared between master and backup browsers on separate subnets. This is how browsing is extended to function beyond the local subnet. Each subnet functions as a separate browsing entity, and the domain master browser synchronizes the master browsers of each subnet. In a Windows-only network, browsing cannot function across subnets unless a PDC exists on the network.[*]
By default, each computer that participates in a browse election is considered a potential browser. It can be ordered by the browse master to become a backup browser or can identify itself as a backup browser and accept the role on its own.
8.2.2. Browser Elections
When no master browser is running on the subnet, potential browsers choose a new master browser among themselves in a process called an election. An election is started by a computer in the subnet when it discovers that no master browser is currently running. If a master browser is shut down gracefully, it broadcasts an election request datagram, initiating an election by the remaining computers. If the master browser fails, the election can be started by a client computer that requests a list of backup browsers from the master browser or by a backup browser that requests to have its browse list updated from the master browser. In each case, the system fails to receive a reply from the master browser and initiates the election.
Browser elections are decided in multiple rounds of self-elimination. During each round, potential browsers broadcast election request datagrams containing their qualifications to notify other potential browsers that an election is happening and that if the recipient is more qualified, it should also broadcast a bid. When a potential browser receives an election request datagram from a more qualified opponent, it drops out, disqualifying itself from becoming the master browser. Otherwise, it responds with its own election request datagram. After a few rounds, only one potential browser is left in the election. After an additional four rounds of sending out an election request datagram and receiving no response, it becomes the master browser and sends a broadcast datagram announcing itself as the local master browser for the subnet. It then assigns runners-up in the election as backup browsers, as needed.
A potential browser's qualifications include the following:
If the potential browser has lost an election recently, it immediately disqualifies itself. The version of the election protocol it is running is checked, but so far, all Windows systems (and Samba) use the same election protocol, so the check is not very meaningful. The election criteria usually determine which computer becomes the LMB. There are two parts to the election criteria, shown in Tables 8-2 and 8-3.
The operating system type is compared first, and the system with the highest value wins. The values have been chosen to cause the PDC, if there is one, to become the local master browser. Otherwise, a Windows NT/2000/XP/2003 system wins over a Windows for Workgroups or Windows 95/98/Me system.
When an operating system type comparison results in a tie, the role of the computer is compared. A computer can have more than one of the values in Table 8-3, in which case the values are added together.
A domain master browser has a role value of 128 to weigh the election so heavily in its favor that it also becomes the local master browser on its own subnet. Although the PDC (which is always the domain master browser) will win the election based solely on its operating system value, sometimes there is no primary domain controller on the network, and the domain master browser would not otherwise be distinguished from other potential browsers.
Systems that are using a WINS server for name resolution are weighted heavily over ones that use broadcast name resolution with a role value of 32.
A preferred master is a computer that has been selected and configured manually by a system administrator to be favored as the choice master browser. When a preferred master starts up, it forces a browser election, even if an existing master browser is still active. A preferred master has a role value of 8, and the existing master browser gets a value of 4.
A backup browser that has recently been a master browser and still has an up-to-date browse list is given a role value of 2, and a potential browser that has been running as a backup browser gets a value of 1.
If comparing the operating system type and role results in a tie, the computer that has been running the longest wins. In the unlikely event that the two have been up for the same amount of time, the computer that wins is the one with the NetBIOS name that sorts first alphabetically.
You can tell if a machine is a local master browser by using the Windows nbtstat command. Place the NetBIOS name of the machine you wish to check after the -a option:
C:\> nbtstat -a rain Local Area Connection: Node IpAddress: [192.168.1.88] Scope Id:  NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- RAIN <00> UNIQUE Registered RAIN <03> UNIQUE Registered RAIN <20> UNIQUE Registered .._ _ _MSBROWSE_ _.<01> GROUP Registered GARDEN <00> GROUP Registered GARDEN <1B> UNIQUE Registered GARDEN <1C> GROUP Registered GARDEN <1D> UNIQUE Registered GARDEN <1E> GROUP Registered
The resource entry that you're looking for is .._ _MSBROWSE_ _.<01>. This entry indicates that the server is currently acting as the local master browser for the current subnet. The group entry with the workgroup name and a resource byte of <1D> is also indicative of a host operating as the LMB. All hosts that participate in browsing elections register the <1E> group name. The <1B> group name is registered only by the domain master browser. As mentioned before, Windows clients do not differentiate between the DMB and the primary domain controller function, so we also know that RAIN is the PDC for the GARDEN domain. As you will see in Chapter 9, all domain controllers register the <1C> group name.
Each instance of a workgroup on a given subnet has its own LMB, so the <1D> group name is never registered with WINS. You must use a broadcast query to resolve the name and should receive only one reply. The -M option to the nmblookup command can be used to locate the local master browser for a workgroup. The following example locates the LMB for the GARDEN workgroup at address 192.168.1.88:
$ nmblookup -M garden querying garden on 192.168.1.255 192.168.1.88 garden<1d>
If the machine is a Samba server, you can also check the Samba nmbd logfile for an entry such as this:
nmbd/nmbd_become_lmb.c:become_local_master_stage2(406) ***** Samba name server RAIN is now a local master browser for workgroup GARDEN on subnet 192.168.1.0
It is possible to find all machines that are potential browse servers on a subnet by performing a broadcast querying the <1E> group name:
$ nmblookup 'garden#1e' querying garden on 192.168.1.255 192.168.1.88 garden<1e> 192.168.1.10 garden<1e> 192.168.1.132 garden<1e>
The domain master browser name is registered with the WINS server, because all LMB servers must be able to locate it. You can query the WINS server for the DMB's address by sending a directed name query to the WINS server at 192.168.1.74 (-U option) and setting the recursion bit in the request packet (-R option):
$ nmblookup -U 192.168.1.74 -R 'garden#1b' querying garden on 192.168.56.1 192.168.1.88 far scape<1b>
8.2.3. Server Announcements
Each server on the network announces itself to the network to allow the master and backup browsers to build their browse lists. When first joining the network, a host sends server announcements every minute, but the interval is gradually stretched out to every 12 minutes. When a server is shut down gracefully, it sends an announcement that it is going offline to allow the master and backup browsers to remove it from the browse list. However, when a server goes offline by crashing or by some other failure, the master browser notices its disappearance only because it stops receiving server announcements. The master browser waits for three of the server's announcement periods before deciding that it is offline, which can take up to 36 minutes. Because backup browsers have their browse lists updated from the master browser once every 15 minutes, it can take up to 51 minutes for clients to be informed of a failed server.
For more detailed information on Microsoft's browsing protocols, consult the Microsoft documents "Browsing and Windows 95 Networking" and "CIFS/E Browser Protocol." You can find these by searching for the titles on the Microsoft web site: http://www.microsoft.com.
8.2.4. Configuring Samba for Browsing
Samba has full support for network browsing and can participate as a master browser, a backup browser, a domain master browser, a potential browser, or just a server that doesn't participate in browsing elections. By default, nmbd participates in elections. If you want to prevent this, simply disable the local master parameter in smb.conf:
[global] local master = no
Usually, Samba should be available as a local master or at least a backup browser. In the simplest case, you don't need to do anything, because Samba's default is to participate in browsing elections with its operating system value set to 20, which beats any Windows system less than a domain controller (see Table 8-2). The operating system value Samba reports for itself in browser elections can be set using the os level parameter:
[global] os level = 33
The preceding value allows Samba to beat even a Windows server acting as a primary domain controller. As we show in the following section, though, forcing Samba to win this way is not recommended.
If you want to allow a Windows XP system to be the master browser, you need to set Samba lower:
[global] os level = 8
The maximum value for os level is 255. Supposing we wanted to make absolutely sure that our Samba server is the local master browser at all times, we might say:
[global] local master = yes os level = 255 preferred master = yes
The addition of the preferred master parameter instructs nmbd to initiate a browser election as soon as it starts up, and the os level of 255 allows it to beat any other system on the network. This includes other Samba servers, assuming they are configured properly. If another server is using a similar configuration file (with os level = 255 and preferred master = yes), the two will fight each other for the master browser role, winning elections based on minor criteria, such as uptime or their current role. To avoid this, other Samba servers should be set with a lower os level and not configured to be the preferred master.
8.2.5. Samba As the Domain Master Browser
Previously, we mentioned that for a Windows workgroup or domain to extend into multiple subnets, one system has to take the role of the domain master browser. The DMB propagates browse lists across each subnet in the workgroup. This works because each local master browser periodically synchronizes its browse list with the domain master browser. During this synchronization, the local master browser passes on the name of any server that the domain master browser does not have in its browse list, and vice versa. Each local master browser eventually holds the browse list for the entire domain.
There is no election to determine which machine assumes the role of the domain master browser. Instead, it has to be manually configured by an administrator. By Microsoft's design, however, the domain master browser and the PDC both register a resource type of <1B>, so the rolesand the machinesare inseparable. If you have a Windows server on the network acting as a PDC, do not configure Samba to become the domain master browser. More about Samba's domain controlling functions is covered in Chapter 9.
If there is no existing PDC, Samba can assume the role of a domain master browser for all subnets in the workgroup with the following options:
[global] domain master = yes preferred master = yes local master = yes os level = 33
The final three parameters ensure that the server is also the local master browser, which is vital for it to work properly as the domain master browser. You can verify that a Samba machine is in fact the domain master browser by checking the nmbd logfile:
nmbd/nmbd_become_dmb.c:become_domain_master_stage2(118) ***** Samba name server RAIN is now a domain master browser for workgroup GARDEN on subnet 192.168.1.0
You previously saw how to query a WINS server for the <1B> group name, but you can also use a broadcast name query, as shown here:
$ nmblookup 'GARDEN#1b' Sending queries to 192.168.1.255 192.168.1.88 GARDEN<1b>
8.2.6. Samba Browsing Enhancements
You must remember three rules when creating a workgroup/domain that spans more than one subnet:
If your entire browsing infrastructure is run by Samba, some additional features are available to work around deviations from the standard LMB/DMB/WINS browsing architecture. Consider the subnets shown in Figure 8-1.
Figure 8-1. Multiple subnets with Samba servers
Under normal circumstances, hosts on one subnet would learn of servers on another subnet by browse list propagation through the workgroup's DMB. Samba, however, is not tied to the DMB requirement and can use the remote announce configuration option to make sure that computers in different subnets are sent broadcast announcements about itself, which has the effect of ensuring that the Samba server appears in the browse lists of foreign subnets. To achieve this effect, the directed broadcasts must reach the local master browser on the other subnet. Be aware that many routers do not allow directed broadcasts by default; you might have to change this setting on the router for the directed broadcasts to get through to its subnet.
With the remote announce option, list the broadcast or IP addresses that should receive the announcement. For example, to ensure that machines in the 192.168.220 and 192.168.222 subnets get broadcast information from your Samba server, specify the following:
[global] remote announce = 192.168.220.255 192.168.222.255
Instead of supplying the broadcast address of the remote subnet, you can specify the exact address where broadcasts should be sent if the local master browser on the foreign subnet is guaranteed to always have the same IP address, such as when a Samba host has been configured to always win the browse election.
If you would like the Samba server to appear in more than one workgroup, you can append a workgroup name to the address to each address using the forward slash character (/). The remote announce setting allows you to send server announcements for arbitary workgroups, including additional groups on your own subnet. The following example allows Samba to be seen in the PARK and PICNIC workgroups in addition to our own on the 192.168.221 subnet:
remote announce = 192.168.221.255/PARK 192.168.221.255/PICNIC
Be aware that even though the Samba server will now appear in the workgroup list on the remote subnet, clients must still be able to resolve the server's name to an IP address in order to access it. This is why WINS is considered a requirement for any widespread use of browsing within a large network.
Another means of implementing some level of cross subnet browsing without a domain master browser is to have the Samba local master browser synchronize its browse list directly with one or more Samba servers, each acting as a local master browser on a different subnet. For example, let's assume that our Samba server is configured as a local master browser, and that Samba local master browsers also exist at 192.168.220.100 and 192.168.222.120. We can use the remote browse sync option to sync directly with the remote Samba servers, as follows:
[global] remote browse sync = 192.168.220.100 192.168.222.120
You can also use directed broadcasts with this option if you do not know specific IP addresses of local master browsers. However, the remote browse sync functionality works only with other Samba servers.
8.2.7. Browsing Options
Table 8-4 shows options that specify how Samba should handle browsing tasks.