dhcpcd-discuss

Hi Roy,

I discovered the cause of the issue.  If the E flag is set Option 81, dhcpcd sets new_fqdn with the fqdn value.  The E flag being set indicates that the fqdn value is encoded in the canonical wire format specified in RFC 1035 Section 3.1.  The E flag being cleared indicates that the fqdn value is  ASCII encoded.  Dhcpcd must be requiring that the value be in RFC 1035 format.  The E flag is specified in Section 2.1 of RFC 4702.  I think this clears up the issue.  I don't see a need right now for dhcpcd to support the ASCII encoding.

Paul Walrath

From: Walrath, Paul
Sent: Wednesday, July 01, 2015 7:45 PM
To: dhcpcd-discuss@xxxxxxxxxxxx
Subject: RE: DHCP Option 81 Client FQDN and new_fqdn

dhcpcd -U eth0 shows the following:

fqdn_flags='0'
fqdn_rcode1='0'
fqdn_rcode2='0'

but fqdn_fqdn is not listed.

From: Walrath, Paul
Sent: Wednesday, July 01, 2015 4:28 PM
To: dhcpcd-discuss@xxxxxxxxxxxx<mailto:dhcpcd-discuss@xxxxxxxxxxxx>
Subject: DHCP Option 81 Client FQDN and new_fqdn

Hi Roy,

I'm seeing an issue that may be a defect in dhcpcd or it may be operator error :).  I have the dhcpcd client configured to request DHCPv4 Option 81 Client FQDN.  The Wireshark trace shows Option 81 being included in the DHCPv4 Option 55 Parameter Request List in the DHCPREQUEST message and the ISC dhcpd DHCPv4 server returns DHCPv4 Option 81 in the response with a fully qualified domain name.  The issue is that, when 30-hostname is executed, the value of new_fqdn is empty.  The FQDN from the server response should be in new_fqdn shouldn't it?   I've tried version 6.7.1 and the latest 6.9.0 with the same result.

Paul Walrath