Protocols device and direct getting out of sync

[Tore Anderson]

Hi, I've noticed that when adding addresses, BIRD will notice (i.e.
"birdc show interface" will immediately show the newly-added address)
but the direct protocol isn't notified until the periodic device scan
triggers. The below console log with embedded comments shows what's
happening. I'm running BIRD 1.4.0 and the config file contains simply:

debug protocols all;
protocol device {}
protocol direct {}

$ bird -d &
[1] 22511
bird: device1: Initializing
bird: direct1: Initializing
bird: device1: Starting
bird: device1: Scanning interfaces
bird: device1: Connected to table master
bird: device1: State changed to feed
bird: Chosen router ID 87.238.42.150 according to interface em1
bird: direct1: Starting
bird: direct1: Connected to table master
bird: direct1: State changed to feed
bird: Started
bird: device1: State changed to up
bird: direct1 < primary address 127.0.0.0/8 on interface lo added
bird: direct1 < primary address 87.238.42.128/25 on interface em1 added
bird: direct1 > added [best] 87.238.42.128/25 dev em1
bird: direct1 < primary address 100.66.7.5/32 on interface tun0 added
bird: direct1 > added [best] 100.66.7.5/32 dev tun0
bird: direct1: State changed to up

$ birdc show route; birdc show interface
BIRD 1.4.0 ready.
100.66.7.5/32      dev tun0 [direct1 13:23:04] * (240)
87.238.42.128/25   dev em1 [direct1 13:23:04] * (240)
BIRD 1.4.0 ready.
lo up (index=1)
	MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536
	127.0.0.1/8 (Primary, scope host)
em1 up (index=2)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	87.238.42.150/25 (Primary, scope univ)
tun0 up (index=5)
	PtP Multicast AdminUp LinkUp MTU=1500
	100.66.7.6/32 (Primary, opposite 100.66.7.5, scope univ)

$ ip address add 192.0.2.1/32 dev lo
bird: direct1 < primary address 192.0.2.1/32 on interface lo removed
bird: direct1 < secondary address 127.0.0.0/8 on interface lo removed

The debug messages from BIRD show up instantly. Not sure why why they
say «removed», as 127.0.0.1 is unchanged, while 192.0.2.1 was *added*.

$ birdc show route; birdc show interface
BIRD 1.4.0 ready.
100.66.7.5/32      dev tun0 [direct1 13:23:04] * (240)
87.238.42.128/25   dev em1 [direct1 13:23:04] * (240)
BIRD 1.4.0 ready.
lo DOWN (index=1)
	MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536
	192.0.2.1/32 (Primary, scope univ)
	127.0.0.1/8 (Unselected, scope host)
em1 up (index=2)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	87.238.42.150/25 (Primary, scope univ)
tun0 up (index=5)
	PtP Multicast AdminUp LinkUp MTU=1500
	100.66.7.6/32 (Primary, opposite 100.66.7.5, scope univ)

So here it has clearly noticed that there's an new address on lo, but
for some reason it's not showing up in BIRD's routing table. Also, for
some reason "lo" is now marked DOWN?

bird: device1: Scanning interfaces
bird: direct1 < primary address 192.0.2.1/32 on interface lo added
bird: direct1 > added [best] 192.0.2.1/32 dev lo
bird: direct1 < secondary address 127.0.0.0/8 on interface lo added

$ birdc show route; birdc show interface
BIRD 1.4.0 ready.
100.66.7.5/32      dev tun0 [direct1 13:23:05] * (240)
87.238.42.128/25   dev em1 [direct1 13:23:05] * (240)
192.0.2.1/32       dev lo [direct1 13:24:05] * (240)
BIRD 1.4.0 ready.
lo up (index=1)
	MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536
	192.0.2.1/32 (Primary, scope univ)
	127.0.0.1/8 (Unselected, scope host)
em1 up (index=2)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	87.238.42.150/25 (Primary, scope univ)
tun0 up (index=5)
	PtP Multicast AdminUp LinkUp MTU=1500

So after the device scan, things look OK again. If I now proceed to add
another address, it will instantly show up in the routing table, so this
problem only appears to happen with the first address(es) I add (until
the first time the device scan has been done after adding addresses),
afterwards it seems to work fine.

The impact of this behaviour is that it takes much longer than necessary
for newly-added addresses to be advertised to the rest of the network
(using RIP or OSPF or whatever). I can reduce the impact of the problem
with using "protocol device { scan time 1; }" but it does seem a bit
wasteful to poll the interfaces that often.

Tore