Subject: Problems with in_addprefix not adding a prefix and notifying the routing
To: None <tech-net@NetBSD.ORG>
From: Martin Husemann <martin@duskware.de>
List: tech-net
Date: 09/16/2001 17:02:00
Help, someone understanding the routing code please help me:

I noticed I do not get any messages on the routing socket for POINTTOPOINT
interface based on sys/net/if_spppsubr.c (in this case: PPPoE interfaces).
I checked and found that the code there does (IMHO) proper calls to in_ifinit.
This calls in_addprefix and in_scrubprefix, which then decide to do nothing,
cause they find another "prefix route" matching the updated one. I added
some printfs, output below.

This may be due to the way this interface/route is setup: initially (with no
PPP connection) the interface is assigned the address 0.0.0.1 (this is a hack
we inherited from FreeBSD with the lmc driver that brought if_spppsubr.c into
our tree, indication the PPP code may accept any remote address). Then a
default route via this address is added (with -iface).

Later the interface gets an address assigned and tries to update the routing
entry, but fails to do so because it finds a route to 127.0.0.1 matching the
update request! I don't understand at all how this happens.

Here is the output of route -n show:

Internet:
Destination      Gateway            Flags 
default          0.0.0.1            U      
127.0.0.1        127.0.0.1          UH     
192.168.150.0    link#1             U      
192.168.150.7    0:0:c0:87:5f:f2    UH     
192.168.150.17   0:50:ba:1d:9c:5    UH     
...

The ifconfig output for the relevant interfaces when IPCP is up and the PPPoE
interface has an IP address assigned is:

lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
        inet 127.0.0.1 netmask 0xff000000
pppoe0: flags=a851<UP,POINTOPOINT,RUNNING,SIMPLEX,LINK1,MULTICAST> mtu 1492
        inet 217.0.157.96 -> 0.0.0.1 netmask 0xff000000

When the interface comes up, my debug printfs show:

pppoe0: setting new address = d9009d78
in_addprefix: not doing anything, already got same prefix: 127.0.0.1

And when it goes down (the old address is deleted by calling in_ifinit
with scrub = 1 and new address 0):
pppoe0: setting new address = 0
in_addprefix: not doing anything, already got same prefix: 127.0.0.1
pppoe0: disconnecting

And going up one more time:
pppoe0: session 0xcaf6 connected
pppoe0: setting new address = d90571a9
in_addprefix: not doing anything, already got same prefix: 127.0.0.1
pppoe0: setting new address = d9009d60
in_addprefix: not doing anything, already got same prefix: 127.0.0.1

Please, someone explain this to me and tell me if it is a bug in 
in_{add,scrub}prefix or an expected effect due to the 0.0.0.1 hack and
the -iface default route. I need to address this, someway or another.

Martin