dhcpcd-discuss

Hi Kenny

On 14/02/2018 15:52, Kenny Napier wrote:
>     I found a old discussion that explains well that the RFC 4702 says 
> you must not send both option 12 and option 81 since this is redundant 
> data.   The main part of this discussion was around the fact that the 
> client does not know if the server supports this option or not.
>
>   I am running into servers that seem to support option 81 but the lack 
> of option 12 is the key factor in the server making the decision to 
> change my host name with a server generated name.

From which point are you coming from - the host dervies it's hostname 
from DHCP or the host instructs the DHCP server it's hostname?

For the former, dhcpcd only sets the hostname using a strict set of 
rules based on what the current hostname is and the if it matches the 
last hostname sent by DHCP.

> This new name is communicated back in the Option 81 response 'Offer' and 
> 'ACK' packets.
>
> If I change dhcpcd to always include option 12 the sever does not 
> auto-generate
> a new hostname and correctly builds the expected option 81 responses 
> that tell us if it will
> update the dns records or not.
>
> I have seen some servers contain a configuration option that says 
> auto-generate a host name if the client does not provide one.   So it 
> appears these servers are treating the absence of option 12 as lacking a 
> host name even when they seem to have some knowledge of option 81 that 
> has the host name included.
>
> I sampled a few other dhcp clients and found windows 10 is working in 
> this manner.
> It will -not- send option 81 in the discover packet - only option 12.
> It will then send both in the request packet.
> It looks like someone was trying to work around the same server behavior.
>
>   I am curious if someone has ran into this issue before or have any 
> thoughts on the best way to be compatible.   It feels like a fully 
> complaint server would just ignore duplicate data from option 12.
>   A  comment in the code around this suggests including both caused a 
> issue in the past for windows.
>
>                  /*
>                   * RFC4702 3.1 States that if we send the Client FQDN 
> option
>                   * then we MUST NOT also send the Host Name option.
>                   * Technically we could, but that is not RFC conformant and
>                   * also seems to break some DHCP server implemetations 
> such as
>                   * Windows. On the other hand, ISC dhcpd is just as non RFC
>                   * conformant by not accepting a partially qualified FQDN.
>                   */

It sounds like your node already knows it's hostname, so this is just 
for getting the DHCP server to update DNS yes?

Regardless, the comment is correct and the RFC is quiet explicit. dhcpcd 
is correct on this matter and will not change unless the RFC does.

Luckily dhcpcd has several options, if you set `fqdn disable` in 
dhcpcd.conf then it only sends option 12 which should work around these 
faulty DHCP servers as you describe.

>    I am using 6.11.5 at the moment.

dhcpcd-7 is no different here.

Roy