Browsing / nmbd issue with subnetting for VPN

[Benjamin Carter]

[Following up to myself.  Writing this earlier post helped me think a
little more closely about what was actually going on, so I made a few
changes and I am reporting on my results.]

On Sat, Jul 29, 2000 at 03:37:48PM -0500, Benjamin Carter wrote:
> I get a netmask of FF.FF.FF.00 on the Windows (client) side.  The only
> other option for their VPN client is to set up a default route to the
> other side (which I definitely do not want.)  I assume this is getting
> picked up from the fact that it is a class-C network.
> 
> As far as the Linux machine is concerned, the netmask is FF.FF.FF.FF (it
> recognizes it as a point-to-point link and the routing entry signifies
> that it is for a single host rather than a network.)

This is essentially the cause of my problems; Windows will happily send
out segment broadcasts over the PPP link.  The other end recognizes it
as a PPP connection and does not support aggregation of multiple links
into a virtual subnet or forwarding of 'broadcast' packets that come
over the link.

So the solution I came up with was:

     1) ifconfig the dummy net device as 192.168.2.254 netmask FF.FF.FF.00

     2) tell samba:
	interfaces = 192.168.2.254/24 127.0.0.1/8
	bind interfaces only = true
	This allows samba to ignore any traffic that might come from a
	source other than the PPTP client connections.

     3) All clients have to have manually disabled browse mastering
	(their machine cannot participate in browser elections.)  The
	reason for this is because when client A sends out broadcast
	packets for the PPP link, they go to the other end (the samba
	server) and terminate there.  The samba server will attempt to
	respond, but all broadcast packets from samba will go nowhere
	(to the dummy device which is the networking equivalent of
	/dev/null.)  The client ends up thinking that it is the only
	node on the subnet, and samba ends up thinking the same thing.
	So they both elect themselves LMB for the subnet.  Fortunately,
	as far as all the other clients are concerned, the samba server
	is still the LMB for the subnet, and their announcements make it
	to the server.  Apparently some unicast packets occur during the
	exchange with the browse-capable client, because it usually ends
	up with a browse list of all the machines in samba's browse
	list, plus itself.  Samba never does get this machine in its
	browse list, for whatever reason - I assume for not responding
	to something during the election process.

This is really a hobbled-together solution, but it works as long as all
the parties involved agree on who is the LMB.  I realized that having a
DMB is irrelevant at this point as all parties involved believe
themselves to be on the same broadcast-capable subnet.  That this is not
the case proves to not matter much because name resolution still works
because of WINS; the only thing remaining (AFAIK) is the election
process, which I have effectively circumvented by disabling LMB
capability on all the client nodes.

It is also worth noting that this behaviour is just from Win95 clients;
I do not have any other systems handy to test it with.  And, of course,
any other software that uses TCP/IP broadcast messages will only find
one neighbor.

To do what I was trying to do (each client is his own LMB and the samba
server is the DMB) would require that samba and the clients both
distinguish between all the interfaces as separate subnets.  I may look
into doing this, but as I share the attitude of "If it ain't broke,
don't fix it" I doubt I will spend much more effort on it.

This would require either A) a separate /30 subnet for each interface or
B) convincing the client that it has a unicast interface.  Either way,
it needs to route to the entire subnet through this interface.  I cannot
think of a way to do this without manually manipulating the routing
tables.

> > > I also have problems with the interfaces line; nmbd seems to disbelieve
> > > my subnet settings.  If I set interfaces=192.168.2.254/32, it tells me
> > > 'bcast addr = 255.255.255.255, netmask=0.0.0.0' - this is obviously
> > > incorrect.
> > 
> > Um, no.  /32 *is* bcast addr = 255.255.255.255, netmask=0.0.0.0  You 
> > probably want /30.
> 
> Technically, shouldn't /32 imply a unicast address?  And it should be an
> alias for a netmask of 255.255.255.255 (which is definitely NOT 0.0.0.0)
> regardless of what is an appropriate broadcast address.

I checked and if I explicitly specified 192.168.2.254/255.255.255.255 it
picks up the settings the way I had desired.  Of course, then broadcast
address = 192.168.2.254, and broadcast packets to this address come back
in over the loopback interface...

But /31 or /32 netmasks do not make much sense in a subnetting sense,
because of the network and broadcast addresses taking up two of the
addresses (only 2 available in /31 leaving no hosts) and /32 is only
meaningful when it is understood to be taken to mean a unicast address.

> I understand that not starting smbd prevents the file sharing - but I
> was unsure whether smbd or nmbd was the process that registered the
> server IP under "netbios-name<20>" which corresponds to the file and
> print sharing service and has the effect of causing the computer name to
> show up in the browse list.
> 
> In any case, the server string (comment) will not be found as IPC$ is
> not being served if smbd is not running - this _probably_ prevents the
> name from showing even if name<20> is registered.

I tried not running smbd, but name<20> was still registered in the WINS
service (which is unsurprising as I rather expected nmbd to handle that
aspect), however I could not get browsing to work correctly without smbd
running.  I suspect the real reason is buried in the guts of the
browsing protocol somewhere.

-- 
-Ben Carter
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so. - Douglas Adams, "Last Chance to See"