dhcpcd-discuss

Hi David

On 02/05/2014 0:04, David Hauck wrote:
> I just received a report about something I thought I'd verified a
> couple months ago. However, I've now verified via Wireshark that my
> current v6.1.0 dhcpcd client isn't sending option 12 (hostname) in its
> initial DISCOVER packet, while the same configuration in v6.0.5 does.
>
> Here's the configuration file:
> # Inform the DHCPv4 server of our hostname for DDNS.
> # This has been superceded by the FQDN option below, but is included
> # by default for servers which do not understand it.
> hostname
>
> # Inform the DHCP server of our hostname for DDNS
> # and/or query for what it should be.
> fqdn

> # Be sure to handshake our vendor code (for interoperability with 
> NNIT).
> vendor 01,"0"
>
> There seems to be some interaction between hostname and fqdn options
> in 6.1.0: when I comment out 'fqdn' above I see option 12 (hostname)
> show up in the DISCOVER. So there seems to be some weird interaction
> between hostname and fqdn in 6.1.0 (this same interaction does not
> seem to be present in 6.0.5 - i.e., the above configuration works fine
> wrt option 12).
>
> Any explanation for why this might be?

I had to look some stuff up as to why!

From RFC4702

3.1. Interaction with Other Options


   Other DHCP options MAY carry data that is related to the Domain Name
   field of the Client FQDN option.  The Host Name option [12], for
   example, contains an ASCII string representation of the client's host
   name.  In general, a client does not need to send redundant data, and
   therefore clients that send the Client FQDN option in their messages
   MUST NOT also send the Host Name option.

Documented in the code here now.
http://roy.marples.name/projects/dhcpcd/fdiff?v1=40faa5f47107e2a2&v2=eaa54368628b9719&sbs=1

		/*
		 * 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.
		 */

Also see
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1088682

This is one RFC bit I disagree with as the client has no way of knowing 
if the server supports the FQDN option, but I don't think there's much I 
can do about it.

Thanks

Roy