Re: Retiring dhclient

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

On Tue, 2011-11-15 at 17:10 +0100, Joerg Sonnenberger wrote:
> The second important item is that dhcpcd by default depends on working
> link state management in the driver. Sadly, quite a few of our older
> drivers don't do it properly. Typical issue is calling if_reset from
> if_ioctl e.g. to update multicast filters. This is a two fold issue:
> (1) Fixing kernel drivers to not do this.
> (2) Documenting the work arounds (aka crippling dhcpcd with -K)
> Building a list of drivers affected would be a good start.
> 
> What other items are missing?

I don't know if you covered it, but currently dhcpcd by default requests
an MTU from the DHCP server and if given and valid, sets it.
A lot of drivers reset their link on MTU change. Infact, about 90% of
the dhcpcd bug reports I get is about this very behaviour. So much so
I'm sorely tempted to stop dhcpcd from doing this by default. Opinions
on what dhcpcd should do by default are welcome :)

See PR #42367 as a good example of this.

As the developer for dhcpcd I don't feel it's my place to argue for the
removal of dhclient even though I'm a NetBSD developer as well. But I'm
happy to debate the merits of dhcpcd vs dhclient, discuss improvements
to dhcpcd and time permitting even write some code!

Thanks

Roy