dhcpcd-discuss

Hi Roy,

Here's what I have for a dhcpd configuration for DHCPv4:

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

subnet 192.168.2.0 netmask 255.255.255.0 {
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.2.255;
    option routers 192.168.2.1;
    option netbios-name-servers 192.168.2.1;

    option domain-name "example.org";
    option domain-name-servers 8.8.8.8, 8.8.4.4;

    range 192.168.2.100 192.168.2.199;
    default-lease-time 43200;
    max-lease-time	86400;
}

host testbed1 {
    # Replace this with your device's MAC address
    hardware ethernet 11:22:33:44:55:66;
    fixed-address 192.168.2.149;
    option host-name "testbed1";
    option fqdn.fqdn "t1.fqdn.walrath.name";
    option fqdn.encoded true;
}

I will try to use "ddns-update-style standard;" instead of "ddns-update-style none;" to see if it makes a difference.  Note that I am not doing DDNS so I'm not sure how dhcpd will take this.

Paul

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

Hi Paul

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

Could you share the fqdn part of your config? I can never get dhcpd to
send back any FQDN option.

But from the sounds of it, you are right that it does appear to be a bug
in dhcpd.

There are other areas where dhcpd/dhclient isn't entirely RFC compliant
so it doesn't come as any big surprise either.

Roy

Attachment: dhcpd.eth1.conf
Description: dhcpd.eth1.conf