From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 20 12:30:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF4FA78C for ; Wed, 20 Nov 2013 12:30:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2D0526D8 for ; Wed, 20 Nov 2013 12:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAKCU1fX033619 for ; Wed, 20 Nov 2013 12:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAKCU1Mp033618; Wed, 20 Nov 2013 12:30:01 GMT (envelope-from gnats) Resent-Date: Wed, 20 Nov 2013 12:30:01 GMT Resent-Message-Id: <201311201230.rAKCU1Mp033618@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Tomasz CEDRO Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 108E059B for ; Wed, 20 Nov 2013 12:23:33 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAEDE266D for ; Wed, 20 Nov 2013 12:23:32 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rAKCNWju046976 for ; Wed, 20 Nov 2013 12:23:32 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rAKCNWNu046960; Wed, 20 Nov 2013 12:23:32 GMT (envelope-from nobody) Message-Id: <201311201223.rAKCNWNu046960@oldred.freebsd.org> Date: Wed, 20 Nov 2013 12:23:32 GMT From: Tomasz CEDRO To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: misc/184117: dhclient does not parse /etc/dhclient.conf correctly X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:30:02 -0000 >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@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: