samba - Aug 2000 - "remote announce": system broadcast addresses can't differ still?

We have 4 class C networks,
   199.129.206.*
   199.129.207.*
   199.129.208.*
   199.129.209.*
I see IP addresses from all 4 classes thru tcpdump.
Some of these computers broadcast as C-class computers; eg, to
   199.129.206.255
Some broadcast to
   255.255.255.255
Of course, several C class networks would induce me to use a
B-class broadcast,
   199.129.255.255
This works for the computers I work with!
Unfortunately, I don't exactly have permission to change their broadcast
addresses, though the computers with which I wish to use Samba use
C-class broadcast addresses like
   199.129.206.255
   199.129.207.255
So, I tried
   remote announce = 199.129.206.255  199.129.207.255  199.129.208.255
                                                        199.129.209.255
With this, network-neighborhood on the Windows 98 boxes show a 
terminal icon with "Olkin" on its right.
This reflects Olkin which is my Linux box running Samba.
However, clicking on the "olkin" icon produces
  \\Olkin is not accessible
  The computer or share could not be found.

So, my Samba server appears to make itself known to the Windows 98
computers, but they can not communicate back to the Samba server.
However, since my Samba server computer's IP address is
   199.129.208.230
then computers, using broadcast address 199.129.208.255,
with the following IP addresses can access my Samba server,
   199.129.208.*

Should these computers from all four C-class computers be able to 
access my Samba server when "remote announce" is set as above?
Why can't the non 199.129.208.* computers access my 199.129.208.230 
Samba server?

Thru tcpcump, I see these other broadcast addresses like
199.129.207.255 coming from the Windows 98 computers,
but Samba apparently isn't responding to them.
For example, when clicking the Windows 98  199.129.207.20
computer's "Olkin" button, I see on my Linux computer's
[Olkin] tcpdump
from 199.129.207.20 [Windows 98 computer] to 199.129.207.255 
   Name query NB OLKIN
But the Windows 98 computer still produces the error message,
  \\Olkin is not accessible
So, for some reason Samba on my Linux computer does not respond 
to the request.

On Thu, 10 Aug 2000, Burt wrote:
> We have 4 class C networks,
>    199.129.206.*
>    199.129.207.*
>    199.129.208.*
>    199.129.209.*
> I see IP addresses from all 4 classes thru tcpdump.
So all four "class C" network numbers are in use on a single physical
LAN?
> Some of these computers broadcast as C-class computers; eg, to
>    199.129.206.255
> Some broadcast to
>    255.255.255.255
> Of course, several C class networks would induce me to use a
> B-class broadcast,
>    199.129.255.255
> This works for the computers I work with!
Assuming that we're talking about one physical network, then it seems to
me that the correct parameters are netmask 255.255.252.0 and broadcast
199.129.209.255 (that is, in modern classless notation, you should be
thinking of single IP network 199.129.206.0/22).

If you were to reorganize the network in this way then I think that you
would find that all your Samba problems would go away and everything
would be much simpler.
> Unfortunately, I don't exactly have permission to change their
broadcast
> addresses ...
If you can't change the current network configuration then the
"correct"
thing to do is set the netmask and broadcast on your Linux machine
appropriate for the class C in which it resides. As you have found, this
then allows you to communicate okay with the Windows machines in the
same class C. As you have also found, you'll have problems with clients
on the other class Cs:
> ... For example, when clicking the Windows 98  199.129.207.20
> computer's "Olkin" button, I see on my Linux computer's
[Olkin] tcpdump
> from 199.129.207.20 [Windows 98 computer] to 199.129.207.255
>    Name query NB OLKIN
> But the Windows 98 computer still produces the error message,
>   \\Olkin is not accessible
What happening here is that your remote announce has informed the
Windows machine at 199.129.207.20 that a file server called "olkin"
exists. However, the Windows machine still doesn't have any way to turn
the NetBIOS name "olkin" into an IP address, so that it can talk to
the
server. When you click on "olkin" in the network neighbourhood the
Windows machine broadcasts a query which basically says "is there anyone
out there called 'olkin'". However, because Olkin and the Windows
machine are on "different" networks and they don't share an IP
broadcast
address Olkin doesn't pick up the query and never responds.

You now face the problem of setting up cross subnet name resolution and
browsing, just as though the four networks were physically seperate and
linked by routers. See the Samba documentation files BROWSING.txt and
BROWSING-Config.txt. Here are a couple of random alternatives:

1. Ideally you should set up a WINS server and then get all the Windows
machines and all the Samba machines to use it (then rather than sending
broadcasts to try and resolve names the Windows machines send directed
queries to the WINS server).

2. You can "hardwire" the Windows clients so that they know
Olkin's IP
address by creating a c:\windows\lmhosts file (the format is similar to
a Unix /etc/hosts file, and there should be some sample files in the
c:\windows directory for you to look at). This is probably only
practical if you have a relatively limited number of clients and servers
to worry about.

3. If you could get IP addresses on *all four* class C networks
allocated to the Linux machine then you could use IP aliasing to make it
appear on all four networks simultaneously and answer to all four class
C broadcast addresses.

Regards,
-- 
Neil Hoggarth                                 Departmental Computer Officer
<neil.hoggarth@physiol.ox.ac.uk>                   Laboratory of
Physiology
http://www.physiol.ox.ac.uk/~njh/                  University of Oxford, UK

[Burt <jameson@monumental.com>]
> We have 4 class C networks,
>    199.129.206.*
>    199.129.207.*
>    199.129.208.*
>    199.129.209.*
[etc]

Your problem is a little confusing.  You say you have four 24-bit
(class C) networks -- are these routed to each other, or are they one
physical LAN?  I'll assume the latter.

Possibly what is happening is that the Windows computers in (for
example) .206.* do not have routes set up to communicate with .207.*
etc.  If this is the case, `ping' will probably fail from the Windows
host to the Unix host.

The simplest solution to *that* may be to configure your Unix host with
multiple IP aliases, one in each subnet.  This is typically not all
that hard to do.

Another possibility is that the incorrect broadcast addresses are
causing the Windows hosts not to pick up broadcast messages.  This is a
can of worms you really want to avoid.  If you "do not have
permission"
to change the erroneous broadcast addresses, you should bug whoever
*does* have permission.  I have seen many communication problems go
away by fixing subnet and broadcast numbers.

To avoid the broadcast issue entirely, you can switch to WINS for name
resolution.  It sounds scary because with NT you have to set up a whole 
new service, but with Samba it's really easy: just use the smb.conf
parameter "wins support = yes" and tell your Windows boxes where to
find the WINS server, in their TCP/IP setup.  Note: some versions of
Windows have a bug where the WINS client won't work unless you have
both IP address fields filled in.  In this case set them both to the
same IP number.

WINS does not solve all browsing or lookup issues, but it sure solves a
lot of them.

Peter