Re: Making dhcpcd work on diskless clients

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 10 Feb 2015 12:25:19 +0800
    From:        Alan Barrett <apb%cequrux.com@localhost>
    Message-ID:  <20150210042519.GY17229%apb-laptoy.apb.alt.za@localhost>

  | Quoting Roy Marples:
  | > But do you have an idea of how this can be fixed then without 
  | > dhcpcd having to learn the routing table at load time?
  | 
  | Do you currently use RTM_DELETE and RTM_ADD?  Can you use RTM_CHANGE
  | instead?

I think the crux of most of this is that on a diskless node, when dhcpcd starts
it is not configuring the network, it is renewing a lease already obtained.

[[The same actually ought to be true any time a node reboots while it held
  an unexpired valid address lease - that should also be treated as a
  renewal (though the network still needs to be configured in this case)
  but in practice is often treated as simply starting an unconfigured node,
  which results in seemingly identical behaviour, so no-one much cares.]]

If it is viewed that way (which may need some way of passing along the
lease info that was obtained before the root filesystem was mounted)
then either it all just works - or dhcpcd is much more broken than just
on diskless clients.

That is, in the case that a lease renewal (a normal lease renewal) results
in some change to the routing table (either a different default router
address, or different "static" routes) how does dhcpcd handle that?

If it is done by deleting what was there, and then adding new, it is
broken, as existing connections that were using the (still working) old
routes will fail if they happen to hit the small interval between delete
and replace.   That's unacceptable.

If all of this means that dhcpcd needs to be able to parse the existing
routing config, and then work out what to change, then so be it.
Alternatively, perhaps some new RTM (CHANGE_OR_ADD or something like that)
might help make it simpler to do the right thing.

kre