Cross-Subnet-Browsing

[Jürgen Appel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!

On monday, April 15th  2002 18:03, you wrote:

> > 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?  :)  www.sambaxp.org

I cannot promise yet. :-(

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

Yes. That is the way we designed our setup:

Every dorm has its own subnet and one workgroup name assigned.
In each dorm there is a linux router running samba and playing DMB for
the dorm's Workgroup.

> 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.

If there were a TimeToLive-counter associated with each workgroup name
one could decrease it with each redistribution. But that's not the way
it is implemented currently with enhanced browsing on (and I don't know
whether this would be possible while maintaining compatibility with
Windows). Whenever a DMB drops a workgroup name, it will get it back
when it syncs with another DMB next time.

If a user enters a wrong workgroup name in his computer this will be
told to the DMB who adds this name to its list. Give it a while and
every DMB would have it in its list of workgroups now.

Normally the entry would disappear if the "bad guy" switched off his
computer or corrected the entry. But with enhanced browsing on, memory
of this wrong workgroup name will be kept alive by (re)distributing it
again and again between DMBs.

Since you cannot set  a windows computer's workgroup name by DHCP as far
as I know, wrong workgroup names happen quite often.

So we ended up with more than 1000(!) workgroup names which rendered the
windows "network neighborhood" quite useless since the vast majority of
them were not browseable, of course.

> > 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.
It is. Sorry. I meant "= False".

With enhanced browsing switched off totally, Samba won't ever get
information about workgroups, which have no member in your subnet, it
seems to me.

Since I have not access to that many windows computers, i could not
figure out how and if windows would overcome this subnet barrier.

> So, what the patch does is enable the syncing via WINS but disables
> the random sync with the list of "known" DMBs.
Exactly. In fact an earlier version of this patch only consisted of
commenting out that particular line :-)

> I'm not sure what this does to fix the ghost problem.  I need to look
> at the specifics of enhanced browsing...
The ghost problem is caused only by syncing with the other DMBs.
Eleminating that sync eleminates the ghost workgroups.

> 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 compatible.
And since there is exactly one #1D in your local subnet this somehow
makes sense.


> > 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.

How does original Windows then get a list of members of a foreign
workgroup then?

>
> > 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.

Ok, that would be possible. I choose to ask the DMB first because in
some rare occsions LMB-DMB - syncing seems to be a little bit
difficult: e.g. if they cannot reach each other by broadcasts. So the
DMB's list seemed more reliable and complete to me. But that would take
some more thorough investigations.
So asking the LMB first would not change the concept. It would maybe be
a little bit more Windows-like.

> > This change is necessary for everyone who wants to browse the
> > network neighborhood comfortably.
> ...but it won't help anyone who is using Windows.

Somehow, and I have not figured out how yet, there is no problem with
browsing in Windows. Under Windows all works well in our network. All
that was necessary war the
enhanced browsing = Partly patch and
setting
  option netbios-name-servers ip-of-our-central-wins;
  option netbios-node-type 2;
in the DHCP config-file.

So either Windows machines also ask the DMBs or they do it a yet unknown
different way.

> I will take a look at them.
Thanks a lot,
        Jürgen

- --
GPG key:
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=jappel%40linux01.gwdg.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjy7BhMACgkQ7h8HhBg+h9XkyQCbBQbmwhWhrJDVm/KucdNYP7rt
WbIAoKxIAyD0PgJd8JoRDqJm8Mt9pgWX
=FDT4
-----END PGP SIGNATURE-----