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 that is provided for netifd. Does this tickles anyone's memory? via <default gateway> dev <dev for default gateway> proto static linkdown

where 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 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, 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 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! 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.

1 Like

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

+1 here, I had to remove this line from it was inserting a /32 route to the remote endpoint server public IP using the local router as target, made no sense.