Christopher R. Hertel crh at
Mon Apr 15 09:05:01 GMT 2002

Jürgen Appel wrote:
> Hash: SHA1
> Hi!

Hi.  I am interested in these patches, but I have some questions first.

> Here at Göttingen University we networked all dormitories and build
> up a large samba-network.

You will, of course, be at the Samba Expo in Göttingen in less than two
weeks, right?  :)

> Our WINs server is a linux machine running samba. Also in each
> dormitoriy  (=each subnet) there is a SAMBA machine running as DMB
> (and most time also as LMB).


  1) Ignoring the subnets, I assume that you have separate workgroups
     for each dorm.  There can only be one DMB per workgroup.

> Two issues came up be solved, which needed modification of samba
> code:
> a)
> First we encountered the problem of never disappering ghost-
> workgroups described in man smb.conf which was solved by the
> introducion of the new "enhanced browsing" option. This option
> disables transfering the list of workgroups from one DMB to another
> (without ever making them invalid by e.g. a TTL counter).

To be clear, disabling enhanced browsing causes Samba to fall back to
"normal" browsing behavior.  That is, it emulates Windows.  When
enhanced browsing is turned on Samba basically tries harder to
synchronize browse lists with other DMBs.  The only problem with this is
that "ghost" workgroups will be propogated to all DMBs and may 'live
forever'.  I think the correct way to solve this is likely to be a more
careful exchange of lists between DMBs, but I'll need to look at the
problem more closely.

> But setting enhanced browsing = True  also made the DMBs stop looking
> for other workgroups by resolving *#1b via the WINS server.

Huh?  Should be the opposite.  Enhanced browsing is turned on by

   enhanced browsing (G)
          This option enables a couple of enhancements to cross-subnet
          browse propagation that have been added in Samba but which
          are not standard in Microsoft implementations.
          The first enhancement to browse propagation consists of a
          regular wildcard query to a Samba WINS server for all Domain
          Master Browsers, followed by a browse synchronization with
          each of the returned DMBs. The second enhancement consists
          of a regular randomised browse synchronization with all
          currently known DMBs.
          You may wish to disable this option if you have a problem
          with empty workgroups not disappearing from browse lists.
          Due to the restrictions of the browse protocols these
          enhancements can cause a empty workgroup to stay around
          forever which can be annoying.
          In general you should leave this option enabled as it makes
          cross-subnet browse propagation much more reliable.
          Default: enhanced browsing = yes

> So what was needed was the possibility to partly disable enhanced
> browsing so that only the call to "sync_all_dmbs" would be avoided.
> The appended patch does this for us by making it possible to set
> enhanced browsing= Partly
> This patch is necessary for each DMB.

So, what the patch does is enable the syncing via WINS but disables the
random sync with the list of "known" DMBs.

I'm not sure what this does to fix the ghost problem.  I need to look at
the specifics of enhanced browsing...

> b)
> Also we noticed that it is very comfortable to browse the "Network
> Neighborhood" by linux programs like the (KDE-) konqueror which
> make use of libsmb.
> But when looking up a master browser for a workgroup WORKGROUP
> to get the names of all computers within that workgroup libsmb only
> searches for WORKGROUP#1d (the LMB-group-tag) and only in its own
> subnet, because there are no WORKGROUP#1d-entries in the
> WINS-database.

Right.  Microsoft kludged their WINS system such that it will accept
registration requests for #1D names, and then silently drop them on the
floor.  Samba does the same, I'm afraid, because it must in order to be

Searching only the local subnet for the #1D LMB name is normal Browse
Service behavior.

> If, like in our case, there are not LMBs of every workgroup in every
> subnet, these searches will sometimes fail.

Again, this is a design problem.  The assumption made by Windows systems
is that members of a workgroup will always look for their *own* LMB on
the local subnet.  I could go into more detail, but I'll skip that for
now.  Basically, given that Windows puts the NBT stack into the kernel
and that, in general, any system above W/95 can act as an LMB, it is
rare that a Windows system will ask for its local LMB and not find it on
the local subnet.

> So I made libsmb first look whether there is a DMB
> for the workgroup in question (lookup WORKGROUP#1B via WINS e.g.).

jCIFS also has this enhancement (Mike talked about it, I think it's in
the code).  It should, however, be the second step, not the first.  Look
for the LMB on the local LAN first.

> If there is, ask this host about its workgroup members, else try the
> conventional way by finding a LMB for WORKGROUP without WINS.
> This made it possible to browse even workgroups which don't have a
> LMB in my subnet.

Yep.  It's a good idea.

> This change is necessary for everyone who wants to browse the network
> neighborhood comfortably.

...but it won't help anyone who is using Windows.

> Maybe someone finds these changes worthy and enters them to the samba
> CVS tree.

I will take a look at them.

Chris -)-----

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

More information about the samba-technical mailing list