Salut !

J'ai beaucoup de difficulté à implémenter les options DHCPv4 code 125 et DHCPv6 code 17 dans odhcpd.
J'en suis à ma énième réécriture. Le code doit réaliser une analyse syntaxique de lignes de configuration.
Cette option spécifique au vendeur encapsule des sous-options. Il faut s'assurer qu'une sous-option n'est
pas dupliquée pour un même vendeur.

Je me suis basé sur le format ci-dessous, inspiré par dnsmasq.

id,code,data

id,option4:code,aa:bb:cc:dd (format hexadécimal en IPv4)
id,code,aabbccddee (format hexa. en IPv6)
id,code,"AOS-Switch:Top:Tokyo,3ffe:501:ffff:100::abcd,aruba123" (format texte)

J'ai rencontré des difficultés sur les allocations mémoires et la recherche d'une option en parcourant les mémoires tampon.
odhcpd emploie blob et blobmsg de l'API libubox. J'ai abandonné l'idée d'employer cette API. Je ne parviens pas à saisir
comment cela pourrait s'imbriquer dans le code existant. Sinon, les données ont chacune leur propre occupation mémoire.
Avec méconnaissance j'ai essayé d'écrire deux ou trois algorithmes mais sans parvenir à un résultat probant. J'ai aussi
beaucoup sollicité ChatGPT pour étudier certaines possibilités. Je lui ai posé des questions. Pour finir, je lui ai demandé
d'intégrer l'option lui-même. Mais il n'a pas appliqué ou trouvé les algorithmes adéquats. Pour finir, j'ai choisi d'élaborer
une machine à états. Le souci c'est que j'ai une vingtaine d'états différents à implémenter. Cela me donne tellement
l'impression de rater le coche. 

C'est stupéfiant, le nombre de possibilités qui apparaît avec des variantes. Même ChatGPT me propose des variantes d'algorithmes sur des déclinaisons.
Je suis bloqué (pas simple, ou « principe KISS ») mais je retrouve différentes parties de procédés lors de mes interactions avec l'IA. C'est pas Eurêka !

Autre exemple de code généré par ChatGPT.

struct option_entry {
uint32_t vendor_id;
int protocol; // 4 for DHCPv4, 6 for DHCPv6
union {
uint8_t u8;
uint16_t u16;
} option_code;
size_t data_len;
uint8_t *data;
};

struct vendor_options {
option_entry *entries;
size_t count;
size_t capacity;
};

On peut passer par qsort() et trier la liste d'options par protocole, par vendeur et enfin par code option. Mais il faut ensuite compacter les données et autres champs dans la même mémoire tampon.

Je lui demande si c'est performant.

5. Est-ce coûteux ?

- Coût mémoire : vous n'avez qu'une seule allocation, ce qui est généralement efficace.
- Coût temps : vous faites une seule passe pour calculer la taille, puis une autre pour copier. Cela reste raisonnable.
- Accès : accéder aux options nécessite de parcourir le tampon en avançant selon la taille de chaque option, ce qui est acceptable si vous traitez tout en bloc.

---

6. Résumé et recommandations

- La solution consiste à allouer un tampon unique, puis à copier `option_entry` et leurs données dedans, en ajustant les pointeurs.
- Cela évite plusieurs allocations et peut améliorer la performance en cache.
- Cependant, cela complique la gestion (libération, accès), donc à utiliser si la performance ou la réduction de fragmentation est essentielle.

Re :

Il faudrait également ajouter un nouveau champ dans la structure vendor_options pour établir le lien avec les différents tampons vendeurs.

[19:48]

Le champ serait un pointeur vers une structure afin de spécifier comment partitionner le tampon « protocole » lors de l'envoi d'une instance
de l'option 125 ou 17. Il suffirait d'indiquer la taille totale des sous-options d'une option vendeur pour recopier la mémoire en bloc.

Finalement, cela ne va pas le faire. C'est trop complexe comme solution. On peut faire plus simple.

#define dhcpv6_for_each_option(start, end, otype, olen, odata)\
   for (uint8_t *_o = (uint8_t*)(start); _o + 4 <= (end) &&\
      ((otype) = _o[0] << 8 | _o[1]) && ((odata) = (void*)&_o[4]) &&\
      ((olen) = _o[2] << 8 | _o[3]) + (odata) <= (end); \
      _o += 4 + (_o[2] << 8 | _o[3]))

#define dhcpv4_for_each_option(start, end, opt)\
   for (opt = (struct dhcpv4_option*)(start); \
      &opt[1] <= (struct dhcpv4_option*)(end) && \
         &opt->data[opt->len] <= (end); \
      opt = (struct dhcpv4_option*)&opt->data[opt->len])

Ces deux macros définies dans odhcpd permettent de parcourir une liste d'options. C'est très bien pour vérifier qu'une nouvelle option n'est pas un duplicata.

Salut,

est-ce que cela fera l'objet d'un PR ?