Injection of Bogus Routes; netifd proto_add_host_dependency()

Installing and Using OpenWrt Network and Wireless Configuration
1

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.

2

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
3

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.

4

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

1 Like
5

Thanks, I'll check that pathway!

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

6

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
7

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

8

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