<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div>
<div>
<div dir="ltr">
<div dir="ltr">All options are supported. Just specify the number. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><dt><b>O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]</b></dt><dd>Specify different or extra options to DHCP clients. By default, dnsmasq sends some standard options to DHCP clients, the netmask and broadcast address are set to the same as the host running dnsmasq, and the DNS server and default route are set to the address
of the machine running dnsmasq. (Equivalent rules apply for IPv6.) If the domain name option has been set, that is sent. This configuration allows these defaults to be overridden, or other options specified. The option, to be sent may be given as a decimal
number or as "option:<option-name>" The option numbers are specified in RFC2132 and subsequent RFCs. The set of option-names known by dnsmasq can be discovered by running "dnsmasq --help dhcp". For example, to set the default route option to 192.168.4.4, do<span class="Apple-converted-space"> </span><b>--dhcp-option=3,192.168.4.4<span class="Apple-converted-space"> </span></b>or<span class="Apple-converted-space"> </span><b>--dhcp-option
= option:router, 192.168.4.4</b><span class="Apple-converted-space"> </span>and to set the time-server address to 192.168.0.4, do<span class="Apple-converted-space"> </span><b>--dhcp-option = 42,192.168.0.4<span class="Apple-converted-space"> </span></b>or<span class="Apple-converted-space"> </span><b>--dhcp-option
= option:ntp-server, 192.168.0.4</b><span class="Apple-converted-space"> </span>The special address 0.0.0.0 is taken to mean "the address of the machine running dnsmasq".<span class="Apple-converted-space"> </span>
<p>Data types allowed are comma separated dotted-quad IPv4 addresses, []-wrapped IPv6 addresses, a decimal number, colon-separated hex digits and a text string. If the optional tags are given then this option is only sent when all the tags are matched.</p>
<p>Special processing is done on a text argument for option 119, to conform with RFC 3397. Text or dotted-quad IP addresses as arguments to option 120 are handled as per RFC 3361. Dotted-quad IP addresses which are followed by a slash and then a netmask size
are encoded as described in RFC 3442.</p>
<p>IPv6 options are specified using the<span class="Apple-converted-space"> </span><b>option6:</b><span class="Apple-converted-space"> </span>keyword, followed by the option number or option name. The IPv6 option name space is disjoint from the IPv4 option
name space. IPv6 addresses in options must be bracketed with square brackets, eg.<span class="Apple-converted-space"> </span><b>--dhcp-option=option6:ntp-server,[1234::56]</b><span class="Apple-converted-space"> </span>For IPv6, [::] means "the global address
of the machine running dnsmasq", whilst [fd00::] is replaced with the ULA, if it exists, and [fe80::] with the link-local address.</p>
<p>Be careful: no checking is done that the correct type of data for the option number is sent, it is quite possible to persuade dnsmasq to generate illegal DHCP packets with injudicious use of this flag. When the value is a decimal number, dnsmasq must determine
how large the data item is. It does this by examining the option number and/or the value, but can be overridden by appending a single letter flag as follows: b = one byte, s = two bytes, i = four bytes. This is mainly useful with encapsulated vendor class
options (see below) where dnsmasq cannot determine data size from the option number. Option data which consists solely of periods and digits will be interpreted by dnsmasq as an IP address, and inserted into an option as such. To force a literal string, use
quotes. For instance when using option 66 to send a literal IP address as TFTP server name, it is necessary to do<span class="Apple-converted-space"> </span><b>--dhcp-option=66,"1.2.3.4"</b></p>
<p>Encapsulated Vendor-class options may also be specified (IPv4 only) using<span class="Apple-converted-space"> </span><b>--dhcp-option</b>: for instance<span class="Apple-converted-space"> </span><b>--dhcp-option=vendor:PXEClient,1,0.0.0.0<span class="Apple-converted-space"> </span></b>sends
the encapsulated vendor class-specific option "mftp-address=0.0.0.0" to any client whose vendor-class matches "PXEClient". The vendor-class matching is substring based (see<span class="Apple-converted-space"> </span><b>--dhcp-vendorclass</b><span class="Apple-converted-space"> </span>for
details). If a vendor-class option (number 60) is sent by dnsmasq, then that is used for selecting encapsulated options in preference to any sent by the client. It is possible to omit the vendorclass completely;<span class="Apple-converted-space"> </span><b>--dhcp-option=vendor:,1,0.0.0.0</b><span class="Apple-converted-space"> </span>in
which case the encapsulated option is always sent.<span class="Apple-converted-space"> </span></p>
<p>Options may be encapsulated (IPv4 only) within other options: for instance<span class="Apple-converted-space"> </span><b>--dhcp-option=encap:175, 190, iscsi-client0</b><span class="Apple-converted-space"> </span>will send option 175, within which is the
option 190. If multiple options are given which are encapsulated with the same option number then they will be correctly combined into one encapsulated option. encap: and vendor: are may not both be set in the same<span class="Apple-converted-space"> </span><b>--dhcp-option</b>.</p>
<p>The final variant on encapsulated options is "Vendor-Identifying Vendor Options" as specified by RFC3925. These are denoted like this:<span class="Apple-converted-space"> </span><b>--dhcp-option=vi-encap:2, 10, text</b>The number in the vi-encap: section
is the IANA enterprise number used to identify this option. This form of encapsulation is supported in IPv6.<span class="Apple-converted-space"> </span><br>
The address 0.0.0.0 is not treated specially in encapsulated options.</p>
<br class="Apple-interchange-newline">
<br class="Apple-interchange-newline">
<br>
</dd></div>
</div>
</div>
<div id="ms-outlook-mobile-signature">
<div></div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Dnsmasq-discuss <dnsmasq-discuss-bounces@lists.thekelleys.org.uk> on behalf of Joe Pfeiffer <joseph@pfeifferfamily.net><br>
<b>Sent:</b> Tuesday, November 29, 2022 2:25:59 PM<br>
<b>To:</b> dnsmasq-discuss@lists.thekelleys.org.uk <dnsmasq-discuss@lists.thekelleys.org.uk><br>
<b>Subject:</b> [Dnsmasq-discuss] Feature request: DHCP options 100 and 101</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">At present, dnsmasq supports DHCP option 2 (time-offset), but does<br>
not support options 100 (TZ-POSIX string) or 101 (TZ-Database<br>
String).<br>
<br>
It would be very helpful if options 100 and 101 could be supported, as<br>
they are more human readable and enable daylight savings time<br>
support. Also, option 2 is deprecated (per<br>
<a href="https://www.rfc-editor.org/rfc/rfc4833)">https://www.rfc-editor.org/rfc/rfc4833)</a><br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
Dnsmasq-discuss@lists.thekelleys.org.uk<br>
<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</div>
</span></font></div>
</body>
</html>