Debugging browsing problems is difficult to say the least... | ||
| --Benjamin Carter in an e’mail message to the Samba-Technical mailing list | ||
Trouble in the Network Neighborhood? What could possibly happen to disrupt the peace and prosperity of such a stable, well run, and deliberately happy place?
Well, any society that puts presentation ahead of principle is bound to suffer. The Network Neighborhood is far from being an exception. Many things, most of them trivial, can throw a monkey-wrench into the works. To its credit, the Browse Service is fairly resilient and recovers quickly once the problem has been rectified. It also helps that it’s a non-critical system. Still, fixing the problems generally requires intervention by a qualified expert. Unfortunatly, there aren’t many of those around so trained professionals wind up with the job, poor dears. Let’s see what we can do to help them...
One of the most common and obvious problems, once you know what to look for, is a misconfigured host. Things that can go wrong include:
The wrong workgroup name in the configuration
Perhaps you entered “
WROKGROPE” when you meant to type in “WEIMARANER”.
Browser services disabled
Browser services over-enabled
A misconfigured or missing NBNS server address
P mode
User not authenticated
Prolific protocol bindings
This is the biggie.
In the old IBM/Sytec days there were these things called LANAs (LAN Adapters). We would call them NICs (Network Interface Cards) today. The original NetBIOS software spoke directly to the LANAs so, logically, when you build an emulated NetBIOS LAN you also have virtual LANAs.
On some systems, such as Windows, you can “bind” the NetBIOS layer to several different protocols. We have focused on NetBIOS over TCP/UDP/IP, but Windows can also bind NetBIOS to NetBEUI and to something called NWLink (which is Microsoft’s implementation of Novell’s IPX/SPX). Each binding represents another virtual LANA. That means that a Windows system with NetBIOS bound to multiple transport protocols is a multi-homed host, as shown in Figure 25.1.
A node with NetBIOS bound to two transport protocols is logically connected to two separate virtual NetBIOS LANs.
Consider what happens when node
STEFFONDwins the Browser Election on the IP LAN, after which nodeCONRADcalls for an election on the NetBEUI LAN and wins. The two nodes are not on the same (virtual) LAN, so they do not know that they are competing.Figure 25.1. Multiple virtual networks
One potential result of this configuration is an election storm, in which the RequestElection frames keep getting sent out (via both virtual LANAs, in some cases) but there is never any clear winner, so the elections have to start all over again. The Leach/Naik Browser draft addresses this issue by warning that a broswer node must be aware of the separate virtual LANs to which it is connected.[1]
Network configuration errors can also upset the teacart.
No DMB
If there’s no Domain Master Browser, then cross-subnet browsing won’t work (unless you set up Samba’s extensions correctly).
Separated namespaces
Namespace manglement is a big deal in the CIFS world, in part because it is so easy to mess it up. The NBT namespace can be fractured if multiple, unsychronized NBNS servers are used or if P, B, and M/H nodes are mixed in the same environment.
The Browse Service relies heavily on the NBT Name Service, so it is important to make sure that the NBT namespace is consistent. Otherwise, the Browsers, Providers, and Consumers won’t be able to find one another.
Figure 24.1 showed what this problem looks like. Unless workgroups are physically mixed on the same LAN, the LMBs won’t find one another and won’t exchange
DomainAnnouncementframes. That means that the workgroups will remain isolated.
This is unverified,[2] but reliable sources report that Windows 9x systems running as Local Master Browsers do not bother to synchronize properly with the Domain Master Browser. If true, it would cause a bit of a problem with cross-subnet browsing. The common solution is to grab an old, outdated PC and load an Open Source OS on it. Then install Samba and configure it to win elections.
Back several years, there was a bug in a release of Samba (somewhere in the 1.9.16 series) that would cause a Samba server to register the <1B> DMB name instead of the <1D> when it won a local election and became an LMB. This bug caused all sorts of trouble, particularly with regard to the Primary Domain Conroller which, due to the rules of NetBIOS naming, was unable to register itself.