Hello!

Je voudrais intégrer plusieurs options DHCPv4 dans le serveur odhcpd (codé en C). J'ouvre ce fil de discussion pour rester motivé et recevoir potentiellement un peu d'aide.
Il y a beaucoup de code à lire (plusieurs centaines de lignes). L'ensemble des sources odhcpd fait approximativement 10 000 lignes. Il faut également rajouter les sources
des bibliothèques : blob & Co. (blob.c, blobmsg.c), libuci... Cela me semble effectivement plus abordable de lire le code des bibliothèques au préalable. Mon problème est
que je ne suis pas sûr de bien comprendre le code. Il faut lire successivement plusieurs fonctions pour se faire une représentation car le code ne contient quasiment aucune
indication sous forme de commentaire et il n'y a pas de documentation (présentation très sommaire : c.f. libubox/blob.h).

Est-ce que les gens intéressés par odhcpd pourraient-ils répondre à quelques questions ?

Quelle est l'utilité de la constante BLOB_COOKIE (blob.h) ?

static inline struct blob_attr *
offset_to_attr(struct blob_buf *buf, int offset)
{
void *ptr = (char *)buf->buf + offset - BLOB_COOKIE;
return ptr;
}

static inline int
attr_to_offset(struct blob_buf *buf, struct blob_attr *attr)
{
return (char *)attr - (char *) buf->buf + BLOB_COOKIE;
}

bool
blob_buf_grow(struct blob_buf *buf, int required)
{
int offset_head = attr_to_offset(buf, buf->head);

if ((buf->buflen + required) > BLOB_ATTR_LEN_MASK)
return false;
if (!buf->grow || !buf->grow(buf, required))
return false;

buf->head = offset_to_attr(buf, offset_head);
return true;
}

static struct blob_attr *
blob_add(struct blob_buf *buf, struct blob_attr *pos, int id, int payload)
{
int offset = attr_to_offset(buf, pos);
int required = (offset - BLOB_COOKIE + sizeof(struct blob_attr) + payload) - buf->buflen;
struct blob_attr *attr;

if (required > 0) {
if (!blob_buf_grow(buf, required))
return NULL;
attr = offset_to_attr(buf, offset);
} else {
attr = pos;
}

blob_init(attr, id, payload + sizeof(struct blob_attr));
blob_fill_pad(attr);
return attr;
}

Elle semble intervenir dans un décalage relatif (offset) par rapport à l'adresse initiale de l'emplacement mémoire utilisé comme tampon (buf->buf).
Mon problème est le suivant : il me semble qu'on ajoute sa valeur à offset sauf qu'on finit par la soustraire, et donc, on annule son valeur.  Du coup,
je ne saisis pas quel est l'effet recherché.

Code source : bibliothèque blob.c

@xp25 :

Je ne pense pas non plus. Je n'ai pas eu de réponse sur le forum OpenWrt. Néanmoins, il semble y avoir beaucoup de visites sur le forum lafibre. De plus, le langage C
est un langage assez courant. On pourrait penser que cela inciterait éventuellement des gens connaissant le C et utilisant OpenWrt à jeter un coup d’œil aux sources.
C'est aussi un moyen de rester motivé et exploiter pleinement l'accès au code (licence libre ou ouverte).

Option d'authentification (90)

Le code d'authentification de message peut être généré par divers protocoles (et algorithmes).

Protocol Name Space Values

0    configuration token    [RFC3118]
1    delayed authentication    [RFC3118]
2    Delayed Authentication (Obsolete)    [RFC8415]
3    Reconfigure Key    [RFC8415]
4    Split-horizon DNS    [RFC-ietf-add-split-horizon-authority-14]

Source : Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces

Orange utilise le protocole « configuration token » avec l'algorithme du même nom. Dans ma capture réseau, la valeur du champ Replay Detection reste à 0.

The configuration token authentication mechanism is vulnerable to interception and provides only the most rudimentary protection
against inadvertently instantiated DHCP servers.

Il n'est pas précisé dans le RFC 3118 ce qu'apporte l'option d'authentification générée avec le protocole « configuration token », celle contenue dans un message client.

Conclusion :

Je pourrais sûrement tricoter une option 90 dans odhcpd sans y passer trois plombes pour faire fonctionner la téléphonie Orange fixe.