J'aurais normalement abouti à la bonne solution d'ici peu.

Cela fut une grosse prise de tête. Diverses implémentations trop complexes. Et avec un degré d'abstraction insuffisant.
Perdu, quelque peu incompétent, et pas d'idée.

Merci aux IAs pour leurs suggestions d'amélioration. Dommage que je n'ai pas eu de retours humains. Dommage que
certains opérateurs m'aient apparemment censuré (black-listé ?) sur les canaux de communication OpenWrt. Je suis
sûrement trop nul mais est-ce une bonne raison ? Dégueulasse !

Au final, la solution retenue paraît plutôt simple. On parse les chaînes de caractères, on extrait les infos, on les stocke
dans une structure « option ». On relie les options dans une liste chaînée par vendeur. Les vendeurs sont aussi reliés.
On parcours les divers vendeurs. On construit un tampon par vendeur. On peut accèder à n'importe quel champ assez
simplement sans avoir à gérer l'accès à la mémoire en fonction du protocole. Même pas besoin d'union pour gérer le
boutisme (aka endianness). Même pas besoin de l'API OpenWrt blob pour simplifier l'allocation et l'accès mémoire (pas
simple d'ailleurs car le tampon résultant n'est pas identique au résultat souhaité et cela duplique du code).

De l'eau a coulé sous les ponts.

Finalement, mon implémentation est encore trop compliquée. On peut le constater en analysant l'implémentation odhcpd de prplos.
J'ai conçu mon implémentation à partir d'une représentation générique mais avec une mauvaise compréhension du code existant.

Notamment, ce qui ne va pas dans mon implémentation, c'est qu'un seul vendeur par interface sera défini dans la configuration.
Chaque interface est configurée séparément. Mais dans mon code tous les vendeurs sont regroupés dans une table de hachage.
Lire le passage ci-dessous.

Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the
Enterprise Number in that option. Servers and clients MUST NOT send more than one instance of the Vendor-specific Information option with the same Enterprise Number. Each instance of the Vendor-specific
Information option MAY contain multiple sub-options.

A client that is interested in receiving a Vendor-specific Information option:

• MUST specify the Vendor-specific Information option in an Option Request option.
• MAY specify an associated Vendor Class option (see Section 21.16).
• MAY specify the Vendor-specific Information option with appropriate data.

Source : 21.17.  Vendor-specific Information Option

Je suis à court d'idées. Je ne perçois pas vraiment comment reprendre mon code pour tenir compte du RFC (l'extrait ci-dessus) ou
s'il faudrait partir sur la même base que l'implémentation de l'option spécifique au vendeur de la variante odhcpd de prplos tout en
maintenant l'intégration de l'option en DHCPv4.