dhcpcd-discuss

I guess a final thought on this would be, when dhcpcd sets a device's host name, it doesn't remember it - perhaps it should.  If it ever decides it might need to set the host name again, given newly received information from a DHCPv4 or a DHCPv6 server, it can check the current host name against the one that it previously set and decide if it should our should not update the host name.  If the current host name does not match the host name that dhcpcd previously set, then some other process must have set the host name and dhcpcd should leave it alone, that is, unless the current host name matches one of the host names considered an initial host name like "(none)" or "localhost".

In the case I detailed earlier, if dhcpcd remembered that it set "web6.fqdn6.walrath.name" the last time it set the host name and it sees the DHCPv4 server providing "webhost4" and "webdomain4.walrath.name" it will see that the current host name matches what it set previously and update the host name to "webhsot4.webdomain4.walrath.name".

-----Original Message-----
From: Roy Marples [mailto:roy@xxxxxxxxxxxx] 
Sent: Saturday, August 15, 2015 11:55 AM
To: Walrath, Paul
Cc: dhcpcd-discuss@xxxxxxxxxxxx
Subject: RE: [dhcpcd-discuss] Does old_fqdn take on the value of new_dhcp6_fqdn?

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