"remote announce": system broadcast addresses can't differ still?

[Neil Hoggarth]

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 at physiol.ox.ac.uk>                   Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/                  University of Oxford, UK