Hi!
Ich habe hier einen Fedora Core release 3 (Heidelberg) server welcher DHCP Dienste mit anbietet.
Das Verteilen von IP/SM/GW geht einwandfrei, doch jetzt brauche ich eine zusätzliche Variable die mit übergeben werden soll.
also man dhcp-options, syntax ist wie folgt:
option var-name code 128 = typ;
im globalen Teil der .conf deklariert, im netz-spezischen teil dann:
option var-name wert;
eingetragen.
service dhcpd restart, er meckert auch nicht (wenn was mit der Syntax falsch ist würde er meckern)
am Client ipconfig /release/renew, aber die variable "var-name" mit dem wert "wert" wird nicht übernommen.
dann hab ich mit ethereal mitgesnifft, und im DHCP-Offer/Ack wird die option mit nicht mit übergeben!
lease-time, domain server, usw. übergit er alle. Wenn ich aber einen vordefinierten Wert nehme und den mit übergeben will geht das auch nicht :(
woran kann das liegen?
ThX
-----------------------------------------------------------------
DHCPD.CONF
option domain-name-servers 192.168.0.111 , 192.168.0.112;
ddns-update-style ad-hoc;
max-lease-time 2419200;
default-lease-time 2419200;
deny unknown-clients;
authoritative;
option dhcp-max-message-size 1024;
option var-name code 128 = text ;
subnet 192.168.10.0 netmask 255.255.255.0 {
option netbios-name-servers 192.168.0.113 ;
option domain-name-servers 192.168.0.114 , 192.168.0.115 ;
option routers firewall;
option var-name "wert" ;
#
# Test PCs
#
host vmware1 {
hardware ethernet FF:FF:FF:FF:FF:FF;
fixed-address test1.unsere.domain.de;
}
}
-----------------------------------------------------------------
[root@sg-test01 etc]# rpm -qa|grep dhcp
dhcp-devel-3.0.1-11
dhcp-3.0.1-11
dhcpv6-0.10-8
dhcpv6_client-0.10-8
-----------------------------------------------------------------
MfG
kannst du grad mal die manpage quoten? frei definierbare wertefelder gibt es in meiner man nicht. auch macht das keinerlei sinn.
der interessante Teil aus der dhcp-options
DEFINING NEW OPTIONS
The Internet Systems Consortium DHCP client and server provide the capability to define new options. Each DHCP option has a name, a code, and a
structure. The name is used by you to refer to the option. The code is a number, used by the DHCP server and client to refer to an option. The
structure describes what the contents of an option looks like.
To define a new option, you need to choose a name for it that is not in use for some other option - for example, you canāt use "host-name" because
the DHCP protocol already defines a host-name option, which is documented earlier in this manual page. If an option name doesnāt appear in this
manual page, you can use it, but itās probably a good idea to put some kind of unique string at the beginning so you can be sure that future options
donāt take your name. For example, you might define an option, "local-host-name", feeling some confidence that no official DHCP option name will
ever start with "local".
Once you have chosen a name, you must choose a code. For site-local options, all codes between 128 and 254 are reserved for DHCP options, so you
can pick any one of these. In practice, some vendors have interpreted the protocol rather loosely and have used option code values greater than 128
themselves. Thereās no real way to avoid this problem, but itās not likely to cause too much trouble in practice.
The structure of an option is simply the format in which the option data appears. The ISC DHCP server currently supports a few simple types, like
integers, booleans, strings and IP addresses, and it also supports the ability to define arrays of single types or arrays of fixed sequences of
types.
New options are declared as follows:
option new-name code new-code = definition ;
The values of new-name and new-code should be the name you have chosen for the new option and the code you have chosen. The definition should be
the definition of the structure of the option.
The following simple option type definitions are supported:
BOOLEAN
option new-name code new-code = boolean ;
An option of type boolean is a flag with a value of either on or off (or true or false). So an example use of the boolean type would be:
option use-zephyr code 180 = boolean;
option use-zephyr on;
INTEGER
option new-name code new-code = sign integer width ;
The sign token should either be blank, unsigned or signed. The width can be either 8, 16 or 32, and refers to the number of bits in the integer.
So for example, the following two lines show a definition of the sql-connection-max option and its use:
option sql-connection-max code 192 = unsigned integer 16;
option sql-connection-max 1536;
IP-ADDRESS
option new-name code new-code = ip-address ;
An option whose structure is an IP address can be expressed either as a domain name or as a dotted quad. So the following is an example use of the
ip-address type:
option sql-server-address code 193 = ip-address;
option sql-server-address sql.example.com;
TEXT
option new-name code new-code = text ;
An option whose type is text will encode an ASCII text string. For example:
option sql-default-connection-name code 194 = text;
option sql-default-connection-name "PRODZA";
DATA STRING
option new-name code new-code = string ;
An option whose type is a data string is essentially just a collection of bytes, and can be specified either as quoted text, like the text type, or
as a list of hexadecimal contents separated by colons whose values must be between 0 and FF. For example:
option sql-identification-token code 195 = string;
option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
ENCAPSULATION
option new-name code new-code = encapsulate identifier ;
An option whose type is encapsulate will encapsulate the contents of the option space specified in identifier. Examples of encapsulated options in
the DHCP protocol as it currently exists include the vendor-encapsulated-options option, the netware-suboptions option and the relay-agent-informa-
tion option.
option space local;
option local.demo code 1 = text;
option local-encapsulation code 197 = encapsulate local;
option local.demo "demo";
ARRAYS
Options can contain arrays of any of the above types except for the text and data string types, which arenāt currently supported in arrays. An
example of an array definition is as follows:
option kerberos-servers code 200 = array of ip-address;
option kerberos-servers 10.20.10.1, 10.20.11.1;
RECORDS
Options can also contain data structures consisting of a sequence of data types, which is sometimes called a record type. For example:
option contrived-001 code 201 = { boolean, integer 32, text };
option contrived-001 on 1772 "contrivance";
Itās also possible to have options that are arrays of records, for example:
option new-static-routes code 201 = array of {
ip-address, ip-address, ip-address, integer 8 };
option static-routes
10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,
10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,
10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;
VENDOR ENCAPSULATED OPTIONS
The DHCP protocol defines the vendor-encapsulated-options option, which allows vendors to define their own options that will be sent encapsulated
in a standard DHCP option. The format of the vendor-encapsulated-options option is either a series of bytes whose format is not specified, or a
sequence of options, each of which consists of a single-byte vendor-specific option code, followed by a single-byte length, followed by as many
bytes of data as are specified in the length (the length does not include itself or the option code).
The value of this option can be set in one of two ways. The first way is to simply specify the data directly, using a text string or a colon-sepa-
rated list of hexadecimal values. For example:
option vendor-encapsulated-options
2:4:AC:11:41:1:
3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
The second way of setting the value of this option is to have the DHCP server generate a vendor-specific option buffer. To do this, you must do
four things: define an option space, define some options in that option space, provide values for them, and specify that that option space should be
used to generate the vendor-encapsulated-options option.
To define a new option space in which vendor options can be stored, use the option space statement:
option space name ;
The name can then be used in option definitions, as described earlier in this document. For example:
option space SUNW;
option SUNW.server-address code 2 = ip-address;
option SUNW.server-name code 3 = text;
option SUNW.root-path code 4 = text;
Once you have defined an option space and the format of some options, you can set up scopes that define values for those options, and you can say
when to use them. For example, suppose you want to handle two different classes of clients. Using the option space definition shown in the pre-
vious example, you can send different option values to different clients based on the vendor-class-identifier option that the clients send, as fol-
lows:
class "vendor-classes" {
match option vendor-class-identifier;
}
option SUNW.server-address 172.17.65.1;
option SUNW.server-name "sundhcp-server17-1";
subclass "vendor-classes" "SUNW.Ultra-5_10" {
vendor-option-space SUNW;
option SUNW.root-path "/export/root/sparc";
}
subclass "vendor-classes" "SUNW.i86pc" {
vendor-option-space SUNW;
option SUNW.root-path "/export/root/i86pc";
}
As you can see in the preceding example, regular scoping rules apply, so you can define values that are global in the global scope, and only define
values that are specific to a particular class in the local scope. The vendor-option-space declaration tells the DHCP server to use options in the
SUNW option space to construct the vendor-encapsulated-options option.
SEE ALSO
dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131, draft-ietf-dhc-agent-options-??.txt.
AUTHOR
The Internet Systems Consortium DHCP Distribution was written by Ted Lemon under a contract with Vixie Labs. Funding for this project was provided
through Internet Systems Consortium. Information about Internet Systems Consortium can be found at http://www.isc.org.
dhcpd-options(5)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.