Rework default route handling.

[jkroonza]

1. replacedefaultroute option is being removed.
2. default route will now always be appended at defaultroute-metric (both IPv4 and IPv6) if defaultroute{.6} is given.

Closes: #473

[jkroonza]

There is also this reference to replacedefaultroute in pppd/ipcp.c in ipcp_clear_addrs:

2055     /* If replacedefaultroute, sifdefaultroute will be called soon
2056      * with replacedefaultroute set and that will overwrite the current
2057      * default route. This is the case only when doing demand, otherwise
2058      * during demand, this cifdefaultroute would restore the old default
2059      * route which is not what we want in this case. In the non-demand
2060      * case, we'll delete the default route and restore the old if there
2061      * is one saved by an sifdefaultroute with replacedefaultroute.
2062      */

I reckon this means further code adjustments may be required around there.

[jkroonza]

Need to add o_uint option.

[jkroonza]

By default iproute2 uses RTPROT_BOOT, somehow that doesn't seem right, but with this we get:

default *proto unspec* scope link metric 10000 

strace from ip ro ad shows (reformatted for readability):

sendmsg(3, {
  msg_name={
    sa_family=AF_NETLINK,
    nl_pid=0,
    nl_groups=00000000
  },
  msg_namelen=12,
  msg_iov=[
    {iov_base=[
      {
        nlmsg_len=44,
        nlmsg_type=RTM_NEWROUTE,
        nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK|NLM_F_CREATE|NLM_F_APPEND,
        nlmsg_seq=1736279032,
        nlmsg_pid=0
      },
      {
        rtm_family=AF_INET,
        rtm_dst_len=0,
        rtm_src_len=0,
        rtm_tos=0,
        rtm_table=RT_TABLE_MAIN,
        **rtm_protocol=RTPROT_BOOT**,
        rtm_scope=RT_SCOPE_LINK,
        rtm_type=RTN_UNICAST,
        rtm_flags=0
      },
      [
        [{nla_len=8, nla_type=RTA_PRIORITY}, 10000],
        [{nla_len=8, nla_type=RTA_OIF}, if_nametoindex("ppp0")]
      ]
    ],
    iov_len=44
  }],
  msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 44

[Neustradamus]

@paulusmack, @sthibaul: Can you look this @jkroonza PR which solves one ticket :)

[Neustradamus]

@paulusmack, @sthibaul: Can you look this @jkroonza PR which solves one ticket :)

[jkroonza]

@paulusmack I would appreciate some feedback on this, especially in the light off the concept #546. Given that I'm wondering if the newly added netlink route/add options should take a prefix in addition. sockaddr_t + socklet_t + some unsigned option.

Then a pair of sifroute functions for adding arbitrary routes which can be called from the radius module.

Currently we handle static routes external to pppd in ip-up and ipv6 up, which is fine, and that can stay there, but we're going to need plumbing for IPv6 PDs anyway, so might just as well handle Framed-Route and IPv6-Framed-Route radius options too.

[paulusmack]

Is 0 really a good choice for the default metric? Shouldn't the metric be somewhat reflective of the bandwidth of the network device (which is often lower for PPP links than other types of network)?

[jkroonza]

That's the current default. And how do you know what the bandwidth on the client side of a ppp link will be?