Re: Making dhcpcd work on diskless clients

[Roy Marples <roy%marples.name@localhost>]

On 13/02/2015 16:56, Roy Marples wrote:
> On 08/02/2015 14:10, Greg Troxel wrote:
>> Roy Marples <roy%marples.name@localhost> writes:
>>> I don't fully understand what you are saying. But do you have an idea of
>>> how this can be fixed then without dhcpcd having to learn the routing
>>> table at load time?
>>
>> It seems to me that on a diskless client, the only really sound approach
>> is to ensure that the DHCP client startup does not change the address
>> and subnet route (and maybe the default route).  That requires a process
>> of checking the routes and fixing if different, vs remove/add.  That
>> might not be too hard, to be able to go an RTM_GET and look at the
>> result.
> 
> I've taken this approach and it's mostly working.
> dhcpcd cannot detect the first IPv6 route added (the kernel says it's
> not there, which is a lie - need to look at this more) but finds every
> other route I can throw at it.

It turns out this isn't a very good approach because RTM_GET returns the
winning route, not the actual routing table entry. Of course, this is
fine for NetBSD but not for other OS's like Linux and OpenBSD where it's
possible to have the same routes split by metric.

So I have a new approach where there kernel's routing table is loaded
just before building our own routing table. dhcpcd will then take the
best action it can so that the existing route is preserved whenever
possible.

> I've not testing anything else, like moving a subnet to another
> interface and that might be quite broken now.

The above still applies, but I've also fixed a few regressions in the
last test build. I have only tested on NetBSD and Linux as well, so
here's a new test if anyone wants to try it.

http://www.netbsd.org/~roy/dhcpcd-6.7.99.2.tar.bz2

Roy