<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Ah, that explains how the opaque-data is parsed, thank you.<br>
<br>
-Erik<br>
<br>
<hr width="100%" size="2"><br>
For the list's reference, here is what I used to get the PXE-HTTPv6
netboot to work under qemu-uefi:<br>
<br>
<br>
<font face="monospace"><font face="monospace"><font face="monospace">
// Client-class definition - <br>
// Vendor Class, System Architecture Type, and software
revision (in this case "x64 UEFI HTTP") - think qemu UEFI w/o
secure boot.<br>
</font></font> { "name": "PXE_uefi-http",</font><br>
<font face="monospace"> "test":
"member('VENDOR_CLASS_HTTPClient:Arch:00016:UNDI:003001')",<br>
"option-data": [<br>
<br>
// The web server system is using fedora's version of
cobbler, apache, and python; /httpboot/ can be setup to be any
type of alias, directory, etc.<br>
// bootx64-http.efi is manually created by grub v
2.11's grub-mkimage including net drivers and<br>
// a hard coded, included grub.cfg that chains to the
webserver's dynamic grub.cfg<br>
{ "name": "bootfile-url", "data": "http://<http
web server ip or dns name>/httpboot/bootx64-http.efi" },<br>
<br>
// vendor-class(16), vendor-id: 343 is the intel/qemu/uefi
required number. It only boots with a match of ID and complete
string<br>
// the 0021 leading the string is the 2-byte-long,
base16, byte count for the remaining string, the remainder is
(base16): </font><font face="monospace"><font face="monospace">HTTPClient:Arch:00016:UNDI:003001</font><br>
// This was tested without "lenient-option-parsing"
enabled.<br>
{ "name": "vendor-class", "data": "343,
002148545450436C69656E743A417263683A30303031363A554E44493A303033303031"
},<br>
{ "code": 60, "data": "Anything here. PXE-UEFI
requires it but grub, as of 2.11, ignores this field." }<br>
] // Closes option-data<br>
} // Close PXE_uefi-http client-class<br>
</font><br>
<hr width="100%" size="2"><br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">According to the code and the RFC 8415 the vendor-class format is an
enterprise ID (unsigned 32 bits) followed by tuples so pairs of lengths
(unsigned 16 bits for v6) and values. Note it is possible to relax
tuple parsing using the lenient-option-parsing compatibility parameter.
In the standard definition file the option is defined a a record of
an unsigned 32 bit integer followed by a binary field so I expect you
should give the content (after the enterprise ID) as a hexadecimal value
i.e. encode the tuple yourself.
Regards
Francis Dupont <a class="moz-txt-link-rfc2396E" href="mailto:fdupont@isc.org"><fdupont@isc.org></a></pre>
</blockquote>
On 11/22/21 06:12, Francis Dupont wrote:<br>
<blockquote type="cite"
cite="mid:20211122121245.DBF793449A@bikeshed.isc.org">
<pre class="moz-quote-pre" wrap="">Erik Edwards writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">{ "name": "vendor-class", "data": "HTTPClient" }>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
=> IMHO you mean vendor-class-identifier (option 60): there is no option
named vendor-class in the DHCPv4 option space.
Regards
Francis Dupont <a class="moz-txt-link-rfc2396E" href="mailto:fdupont@isc.org"><fdupont@isc.org></a>
</pre>
</blockquote>
<br>
</body>
</html>