Re: Making dhcpcd work on diskless clients

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

On 05/02/2015 23:28, John D. Baker wrote:
> On Tue, 3 Feb 2015 21:47:17 +0100, Martin Husemann <martin%duskware.de@localhost>
> wrote:
> 
>> This did not work well: midway through the dhcpcd startup, NFS started
>> erroring out with EHOSTUNREACH.
> 
> I posted about the same thing not too long ago:
> 
>   http://mail-index.netbsd.org/current-users/2014/12/13/msg026297.html
> 
> My observation has been this only affects non-x86 diskless clients.  If
> the diskless client is sparc{,64}, macppc, evbmips-mips64el (all I've
> tried lately), then I observe the same failure as reported here
> 
> If the diskless client is i386 or amd64, configuration via 'dhcpcd'
> during startup works just fine.

There are no arch differences in the code, so I find this surprising.
dhcpcd has grown a little bigger since the initial import, mainly due to
the configurable DHCP option engine to mimic dhclient and growing IPv6
functionality.

Another possible issue could be the fact that dhcpcd will remove and
re-add the routes (including subnet/prefix route) because it doesn't
know about existing routes and takes this approach to ensure routes are
setup correctly.

> In my case, I use the "dhcp" keywork in the client's "/etc/ifconfig.if"
> file, so a similar hack will be needed in the 'network' rc script since
> it invokes 'dhcpcd' directly.
> 
> Until somehow all of 'dhcpcd' can be made resident before it starts
> twiddling with the interface/routes/etc. without resorting to such
> subterfuge.

If it is just a code size problem, how do I force everything to load
into memory before messing around with the routes?

Another option would to be add some route learning code in if-bsd.c (and
ofc if-linux.c) so dhcpcd doesn't need to break existing routes even for
a split second.

Roy