Injection of Bogus Routes; netifd proto_add_host_dependency()

Edit: Actual injection of the route appears to be done in a call to proto_add_host_dependency()

I've now traced down the appearance of a completely bogus static route to the call to resolveip done within the gre.sh that is provided for netifd. Does this tickles anyone's memory?

172.16.1.9 via <default gateway> dev <dev for default gateway> proto static linkdown

where 172.16.1.9 is a private address of a remote host on a network that is not (yet) link-local to a configured interface. The address was supplied verbatim to resolvip, not as a DNS name.

This becomes a significant issue as once network connectivity is established for the 172.16.1.0/nn net, that static route not only continues to be wrong, but is apparently taken over the less-specific, but correct routing for the subnet.

Yes, wireguard.sh also inserts such route which has caused me problems. As a work-around I think it should be possible to configure the interface to not insert the route.

1 Like

Does wireguard.sh call resolveip?

I was quite surprised by this as the script involved is "core" OpenWRT

Edit: Looking at resolveip.c it doesn't seem to be doing anything "strange" in there, just a call to getaddrinfo() and inet_ntop(). It doesn't look like a call that should modify the routing table.

The route is inserted by netifd if I remember correctly, triggered by the call to proto_add_host_dependency().

1 Like

Thanks, I'll check that pathway!

wireguard.sh doesn't seem to call resolveip itself.

There is a bug in netifd in 17.01.4 that affects the route lookup which may cause problems since it selects the least specific route instead of the most specific route.

https://bugs.openwrt.org/index.php?do=details&task_id=1358

1 Like

Thanks -- yes, I can confirm that what I am seeing is