misc/184117: dhclient does not parse /etc/dhclient.conf correctly

Tomasz CEDRO cederom at tlen.pl
Wed Nov 20 12:30:02 UTC 2013


>Number:         184117
>Category:       misc
>Synopsis:       dhclient does not parse /etc/dhclient.conf correctly
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 20 12:30:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Tomasz CEDRO
>Release:        9.2-RELEASE
>Organization:
CeDeROM
>Environment:
FreeBSD mercury.rd.tp.pl 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013     root at bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
I need to send additional options with dhcp request, so I add "send" option for an interface in /etc/dhclient.conf, however options are non-standard and they are not sent in dhcp request. I have noticed that other options with names known to dhcp-options and other decimal numbers are sent correctly...

These options work with isc-42-dhcp-client port as they know the string alias for the option number...

I would expect base dhclient to work with any "option-nnn" decimal value provided, no matter if the string alias is defined for this option or not and what is the current IETF document release based upon :-)


Accorging to dhcp-options manual:

     The documentation for the various options mentioned below is taken from
     the IETF draft document on DHCP options, RFC 2132.  Options which are not
     listed by name may be defined by the name option-nnn, where nnn is the
     decimal number of the option code.  These options may be followed either
     by a string, enclosed in quotes, or by a series of octets, expressed as
     two-digit hexadecimal numbers separated by colons.  For example:

           option option-133 "my-option-133-text";
           option option-129 1:54:c9:2b:47;

     Because dhcpd(8) does not know the format of these undefined option
     codes, no checking is done to ensure the correctness of the entered data.

>How-To-Repeat:
Here is my example /etc/dhclient.conf configuation:

interface "em0"{
 send option-060 "vendor"; <-- does not go out in dhcp request
 send option-077 "user"; <-- does not go out in dhcp request
 send option-123 "blah123"; <-- goes out in dhcp request
 send root-path "blahroot"; <-- goes out in dhcp request
}
>Fix:
I expect dhclient to work with any "option-nnn" decimal value provided, no matter if the string alias is defined for this option or not and what is the current IETF document release based upon, that would make software more versatile and consistent :-) Thank you :-)

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list