Documentation bug with dhcp-client-identifier and leading zero byte
Jonah Petri <[email protected]> Tue, 26 May 2026 15:38:36 -0400
| Newsgroups | gmane.network.dhcp.isc.dhcp-client |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0460195087996459056==
Content-Type: multipart/alternative;
boundary="------------nwF3fFe7cn1ISvQOwWHghwvY"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------nwF3fFe7cn1ISvQOwWHghwvY
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hello,
I spent quite a while chasing what turned out to be a documentation
issue with the correct use of dhcp-client-identifier. I wanted to write
to the list in the hopes that someone in the future could be saved from
the trouble I went through.T
The documentation correctly states that DHCP clients will prepend a zero
byte to a ASCII dhcp client identifier. However, the example given in
dhcp-options.5 for how to deal with this is wrong and will not work.
The string parser in the config file grammar, implemented in conflex.c
read_string(), expects 3 digits of octal after the backslash escape, and
it will ignore any backslash escapes with less than this number of octal
digits. So the example "\0foo" will NOT be read as having a leading
zero byte. It will instead be read as identical to "foo". If you want
to have a leading zero byte, you must spell the string as "\000foo".
The alternative is to spell out the entire thing in colon-separated
bytes, like 00:66:6F:6F. There appears to be hex escape parsing as well
but since that's not documented anywhere I saw, I won't mention it further.
I would also ask that the docs be updated to reflect the correct usage,
but I know that the project is EOL and there might be no capacity to do so.
All the best,
Jonah
--------------nwF3fFe7cn1ISvQOwWHghwvY
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>
</p>
<div class="moz-text-flowed"
style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">Hello,
<br>
<br>
I spent quite a while chasing what turned out to be a
documentation issue with the correct use of
dhcp-client-identifier. I wanted to write to the list in the
hopes that someone in the future could be saved from the trouble I
went through.T
<br>
<br>
The documentation correctly states that DHCP clients will prepend
a zero byte to a ASCII dhcp client identifier. However, the
example given in dhcp-options.5 for how to deal with this is wrong
and will not work.
<br>
<br>
The string parser in the config file grammar, implemented in
conflex.c read_string(), expects 3 digits of octal after the
backslash escape, and it will ignore any backslash escapes with
less than this number of octal digits. So the example "\0foo"
will NOT be read as having a leading zero byte. It will instead
be read as identical to "foo". If you want to have a leading zero
byte, you must spell the string as "\000foo". The alternative is
to spell out the entire thing in colon-separated bytes, like
00:66:6F:6F. There appears to be hex escape parsing as well but
since that's not documented anywhere I saw, I won't mention it
further.
<br>
<br>
I would also ask that the docs be updated to reflect the correct
usage, but I know that the project is EOL and there might be no
capacity to do so.
<br>
<br>
All the best,
<br>
<br>
Jonah
<br>
<br>
</div>
<p><br>
</p>
</body>
</html>
--------------nwF3fFe7cn1ISvQOwWHghwvY--
--===============0460195087996459056==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
--===============0460195087996459056==--