Daniel Hilst 50ebc0af43 fix(dhcp): accept both encodings of the xNBA user class on ISC ...

A chainloaded second stage announces itself in the user class, option 77, and
must be handed a script URL rather than the loader it just ran -- otherwise it
chainloads itself forever and the machine never finishes booting.

RFC 3004 length-prefixes each string in option 77. Plenty of firmware sends the
bare string instead, and the same loader sends either depending on how it was
built, so both encodings have to be recognised. The Kea policy has always
accepted both. The ISC side compared only `option user-class-identifier =
"xNBA"`, which is the bare form, so a conforming loader booting against an ISC
management node loops -- and does so silently, since from the server's side
every exchange looks like a normal first-stage boot.

Put the test in one place, isc_xnba_user_class_test, and use it from both the
per-network architecture chain and the three per-node statements. The per-node
ones reach dhcpd through omshell, so the helper takes the quoting its caller
needs. `substring(option user-class-identifier, 1, 4)` skips the length byte;
option 77 is declared as a plain string, and the same construct is already used
by the onie_vendor branch a few lines below.

2026-09-10 10:03:31 -03:00

..

perl/xCAT

fix(template): take the install mirror from the ports archive off amd64

2026-09-08 22:01:27 -03:00

xcat

fix(dhcp): accept both encodings of the xNBA user class on ISC

2026-09-10 10:03:31 -03:00