dhcpcd-discuss

Hi Roy,

I did a test and found that ISC dhcpd 4.2.4 DHCP server did not look at the E bit in Option 81 that is sent from the client.  Dhcpcd sent Option 81 with the E bit set but dhcpd returned Option 81 with the fqdn still ASCII encoded.  I had to configure dhcpd using "option fqdn.encoding true" in order to get it to return the fqdn using RFC 1035 encoding.  It appears as though ASCII is its default encoding, at least for the fqdn response that it returns to the client.  RFC 4702 says that a server MUST use the same encoding as that used by the client, so I don't understand this result.  It appears as though ISC dhcpd is not in compliance with RFC 4702.

Paul

-----Original Message-----
From: Roy Marples [mailto:roy@xxxxxxxxxxxx] 
Sent: Thursday, July 02, 2015 9:11 AM
To: dhcpcd-discuss@xxxxxxxxxxxx
Subject: Re: [dhcpcd-discuss] RE: DHCP Option 81 Client FQDN and new_fqdn

Hi Paul

On 02/07/2015 17:05, Walrath, Paul wrote:
> 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.

He, we sent our emails at the same time :)

You're absolutely spot on by the way.
Even though no code change was required, I did add some more error
handling in this area and some commentary so it's certainly not wasted time.

Roy