Auteur Sujet: Orange DHCP conformité protocolaire 2023 - lire depuis le début du sujet (Lu 461049 fois)

jeremyp3 · « **Réponse #1404 le:** 20 avril 2026 à 15:56:10 »

Citation de: cyayon le 20 avril 2026 à 15:28:45

Salut,

je ne suis pas certain d'avoir tout compris, sur mikrotik mes userclass LB7 (XGS-PON/WAS110) :
ipv4 (userclass option 77) : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837
ipv6 (userclass option 15) : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837

Où tu vois un L / l ?

dans ton cas c'est bon les 2 L de Livebox7 sont bien en majuscule
4c697665626f7837 cette chaine veut dire Livebox7

par contre, si tu mets le l de livebox7 en minuscule, ça donne:
6c697665626f7837

et du coup, Orange, ils n'aiment pas

Jerem

zoc · « **Réponse #1405 le:** 20 avril 2026 à 16:16:47 »

Oui, clairement. Il n'y a pas de l/L en hexadécimal

Jusqu'à présent j'avais "Livebox4" en IPv4 et "livebox4" en IPv6 sans que ça n'ait jamais posé problème (surement parce qu'une version du FW LB4 devait envoyer la variante en minuscules). Du coup lors du passage en XGS-PON et W7 j'avais juste changé le dernier octet des options 15 et 77, mais Orange n'aime manifestement pas "livebox7".

cyayon · « **Réponse #1406 le:** 22 avril 2026 à 09:48:10 »

Citation de: jeremyp3 le 20 avril 2026 à 15:56:10

dans ton cas c'est bon les 2 L de Livebox7 sont bien en majuscule
4c697665626f7837 cette chaine veut dire Livebox7

par contre, si tu mets le l de livebox7 en minuscule, ça donne:
6c697665626f7837

et du coup, Orange, ils n'aiment pas

Jerem

merci !

unipo · « **Réponse #1407 le:** 27 avril 2026 à 20:13:44 »

J'ai un petit script de test de vie appliquant les recommandations du post #1, arping et ping6 des passerelles.

Depuis l'avoir mis en place, j'ai remarqué que les arping sur ma passerelle IPv4 échouent tout les jours vers les coups de 11h du matin.
Le reste du trafic à l'air de passer correctement. Mais si je laisse mon script tourner, il me relance mes deux stacks donc à ce moment car la passerelle IPv4 est injoignable durant 120s+10s+10s

C'est un comportement attendu? Une opération journalière côté orange?

simon · « **Réponse #1408 le:** 28 avril 2026 à 10:54:45 »

Peux-tu faire un ping (ICMP) plutôt qu'un arping (ARP) pour voir si cela fait une différence?

Orange a une machine à état de gestion des connexions côté BNG très... complexe, pour ne pas dire autre chose.

Jimbo-77 · « **Réponse #1409 le:** 30 avril 2026 à 09:05:00 »

Citation de: zoc le 20 avril 2026 à 16:16:47

Oui, clairement. Il n'y a pas de l/L en hexadécimal

Jusqu'à présent j'avais "Livebox4" en IPv4 et "livebox4" en IPv6 sans que ça n'ait jamais posé problème (surement parce qu'une version du FW LB4 devait envoyer la variante en minuscules). Du coup lors du passage en XGS-PON et W7 j'avais juste changé le dernier octet des options 15 et 77, mais Orange n'aime manifestement pas "livebox7".

je viens d'avoir la même blague.
Il y a du y avoir une intervention niveau Orange car mon lien fibre est tombé à 2h30 et derrière je récupérais un bail à 13h avec un préfix à 2a01:cfc6:78:e300::/64.

Et je suis retombé sur ce thread et bingo, j'avais un l minuscule. Modification de l'option et ça a fait le taffe.

Merci

renaud07 · « **Réponse #1410 le:** 06 mai 2026 à 00:56:57 »

Citation de: simon le 28 avril 2026 à 10:54:45

Peux-tu faire un ping (ICMP) plutôt qu'un arping (ARP) pour voir si cela fait une différence?

Orange a une machine à état de gestion des connexions côté BNG très... complexe, pour ne pas dire autre chose.

Perso, j'ai mis en place 2 ping vers ba0bab avec un timeout de 5 sec toutes les 3min au lieu de 2 (je suis volontairement plus large en cas de désync ADSL le temps que ça remonte) et je ne me préoccupe pas de l'IPv4. Les deux sont relancées en cas d'échec en v6 et pour le moment ça à l'air de bien se passer.

unipo · « **Réponse #1411 le:** **Hier** à 23:30:51 »

Citation de: simon le 28 avril 2026 à 10:54:45

Peux-tu faire un ping (ICMP) plutôt qu'un arping (ARP) pour voir si cela fait une différence?
[...]

Tout compte fait, le problème est tout autre, ce ne sont pas uniquement les arpings qui échouent, mais ma connection dans sa totalité. Cela ~24h après le premier lease à chaque fois.
C'est comme si je ne répondait pas correctement au renew initié par orange, cela invalidant ma session...

Un second utilisateur semble rapporter les même symptômes. Potentiellement un rapport avec la dernière version d'OpenWRT.

basilix · « **Réponse #1412 le:** **Aujourd'hui** à 08:19:35 »

@unipo:

Il faut simplifier pour isoler la cause probable. Procéder par élimination.

Éviter de permuter trop souvent la Livebox et le routeur tiers. Une permutation peut générer une IAID différente.
Par conséquent, le client DHCPv6 sollicite une IPv6 additionnelle au serveur Orange (ce qui est refusé). Il faut
libérer les baux DHCPv4/v6 avant d'entreprendre la permutation (en supposant que le DUID et la MAC de la
Livebox ont été bien cloné sur le routeur). Sinon, il faut éventuellement attendre des dizaines de minutes avec
la fibre débranchée.

Réaliser une capture réseau sur l'interface WAN du routeur durant plusieurs jours. Il faut vérifier la cohérence des données
avec ce qui est spécifié : PCP, DSCP, authentification...

Faire une configuration minimaliste : le plus proche de la configuration originale. Essayer de se poser les bonnes questions.
Complexifier progressivement.

unipo · « **Réponse #1413 le:** **Aujourd'hui** à 09:10:17 »

@basilix

Pas de permutation routeur perso <-> livebox, ça fait plusieurs années qu'elle est dans son carton au fond du garage.
Il me semble dans tout les cas que levieuxdorange ait indiqué précédemment que pour libéré les baux, si changement DUID & MAC faire un release propre. Si trop d'essais, patience le temps que le bail le plus ancien expire. Certain OTL effacent les baux si fibre absente, d'autre non.

J'utilise la même configuration depuis des années, basée sur le tuto de ubune, à la différence des marquages dscp & skprio conseillés ici.

Ce soucis est apparut au passage de OpenWRT 24.10.5 -> 25.12.0. Et toujours d'actualité sous 25.12.3.

Ce n'est pas un problème d'acquisition DHCP, j'ai bien les IPv4/IPv6 quand je relance l'interface.
Mais il semblerait un soucis au renew.

Je suppose donc que OpenWRT 25.12.X à changé quelque-chose, et que des personnes plus compétentes sur le sujet puissent potentiellement avoir un idée sur ce changement.

Quant aux captures sur le WAN, c'est la prochaine étape, quand j'en trouverai le temps.

Mjules · « **Réponse #1414 le:** **Aujourd'hui** à 14:44:20 »

Pour l'ipv6, avec la version 25.12, un DUID par défaut est généré lors du premier boot de cette version et qui n'est pas basé sur la MAC. C'est pas ça qui poserait problème ?

https://github.com/openwrt/openwrt/pull/20359

unipo · « **Réponse #1415 le:** **Aujourd'hui** à 17:01:17 »

Bien vu! Je n'y avais pas pensé !

C'est une bonne piste, mais il me semble bien que "option clientid" écrase le "DUID par défaut " que ce soit pour l'interface IPv4 ou pour l'IPv6...

Citer

The default DUID for this device, used when acting as a DHCP server or client. The client identifier can be overridden on a per-interface basis.
This identifier is randomly generated the first time the device is booted.