dhcpcd-discuss

On 2015-08-15 17:14, Walrath, Paul wrote:
> This makes sense, although I'm not sure if you would ever
> see that done in practice.
>
> Further testing confirms this behavior.  Here's an
> Example of what I've seen occur.

Great, so we agree entirely here.

> The first RENEW6 shows that the DHCPv6 server is no longer
> providing the fqdn since $new_dhcp6_fqdn is empty.
>
> The second RENEW6 shows that $old_dhcp6_fqdn is empty
> due to the previous RENEW6 not providing $new_dhcp6_fqdn
>
> The first DHCPv4 RENEW shows that the DHCPv4 server is now
> providing the host name and domain name which show up in
> $new_host_name and $new_domain_name.
>
> need_hostname() always returns false, indicating that
> 30-hostname should not set the host name of the device.
>
> dhcpcd only remembers history one level back.  When the fqdn
> disappears from RENEW6, dhcpcd no longer knows how the
> device acquired its host name.  When the new information
> shows up in RENEW, dhcpcd does not want to use it to
> overwrite the current host name because it doesn't know
> if the current host name was set by some other process.
> One way to fix this would be to keep a history of
> the last hostname that dhcpcd set and use it to compare
> to the current hostname.  That would probably come with
> its own set of problems and corner cases.
>
> Logically, 30-hostname could set the host name to
> the empty string ("") when $old_dhcp6_fqdn matches
> the current host name and $new_dhcp6_fqdn is
> empty, however, I'm not sure that is a sound idea.
> There could be issues with removing a device's host
> name entirely.  This probably doesn't play
> well with the logic used to select a host name from
> multiple pieces of information.  There could be
> unforeseen complications.

Yup, you've pretty much hit the nail on the head.
I should probably document this in the hook script.

Roy