Auteur Sujet: Config OpenWRT derrière ONT Bouygues (Lu 38832 fois)

Antoinel · « **Réponse #60 le:** 01 juillet 2026 à 19:44:38 »

Probablement un breaking change comme Openwrt sait le faire (mélangé des nouvelles fonctionnalités et des correctifs, oui c'est une critique).

https://github.com/openwrt/openwrt/issues/23965

nico1881 · « **Réponse #61 le:** 01 juillet 2026 à 22:49:09 »

Je confirme, la config suivante ne marche plus avec 25.12.15

Code: [Sélectionner]

config interface 'wan6'
    [...]
    option reqprefix '64'

Mais marche bien avec:

Code: [Sélectionner]

config interface 'wan6'
    [...]
    option reqprefix 'auto:1'

Merci d'avoir partagé l'info c'est apprécié :-)

basilix · « **Réponse #62 le:** 02 juillet 2026 à 11:30:04 »

@Antoinel

L'hypothèse ne tient pas forcément.

Car ce sont des problèmes différents :

délégation d'un préfixe en amont par le serveur Bouygues
délégation d'un préfixe en aval à l'une des interfaces du réseau local

Il faudrait vérifier si le routeur reçoit bien un préfixe du serveur Bouygues.

Code: [Sélectionner]

ubus call network.interface.wan status

@nico1881

La configuration du fil a des incohérences.

Code: [Sélectionner]

config interface 'wan6'
	option device '@wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix '64'
	option ip6assign '64'

L'option ip6assign est spécifiée pour une interface du réseau local (pas à wan6).

L'option reqprefix avec une longueur 64 empêcherait de segmenter le réseau local bien que le serveur DHCP du FAI peut choisir un préfixe de longueur différente.

nico1881 · « **Réponse #63 le:** 02 juillet 2026 à 21:14:42 »

@basilix si tu as des suggestions pour corriger la conf par défaut elles sont bienvenues! Et je mets à jour le premier post avec une conf qui marche.
J'avoue ne pas avoir tout compris aux options IPv6 sous OpenWRT. Vais faire un peu de lecture aussi.

basilix · « **Réponse #64 le:** 03 juillet 2026 à 10:06:07 »

@nico1881

Malheureusement, la documentation OpenWrt, très technique, suppose déjà une bonne maîtrise du sujet.

Retire l'option ip6assign de la section wan6.

J'ai un doute concernant reqprefix. Si le serveur Bouygues ne délègue pas de préfixe alors spécifier cette option ne résoudra pas le problème.
Le problème cité par @antoinel n'apparaît que lors de la délégation d'un préfixe spécifique (ip6class) à une interface du réseau local (« downstream »).

Spécifier l'IAID de l'interface WAN n'est pas systématique. Il faudrait comparer avec une capture réseau émise par la box fournie par Bouygues. Il est possible
que le réseau Bouygues vérifie l'adéquation des différentes valeurs entre elles.

On peut spécifier les paramètres requis par Bouygues sans forcément les inscrire dans la config. si leur valeur est identique à celle par défaut. C'est une
question de style : on évite de surcharger la configuration inutilement. Exemple : mentionner reqaddress sans l'inscrire ou inscrire reqprefix à ":1" et pas
"auto:1" en indiquant explicitement qu'on initialise l'IAID.

basilix · « **Réponse #65 le:** 03 juillet 2026 à 18:46:10 »

J'ai compris le problème en approfondissant les recherches.

Ce n'est pas un bogue à proprement dit. Le procédé de génération des IAID entre les IA_NA et IA_PD a été harmonisé.

On se retrouve avec la même désynchronisation qui s'était produite lors du changement de DUID. Je l'avais déjà remarqué
auparavant (voir le texte en magenta).

Citation de: basilix le 09 mars 2026 à 11:00:00

@zof @simon :

Il vaut mieux suivre les recommandations de l'opérateur réseau.

@nando11 :

L'application d'un correctif à odhcpd a abouti sur une cascade de modifications : DUID global + IAID. Pour en savoir plus, lire le commentaire de Noltari dans le ticket « 25.12.0-rc3 breaks static DHCP from network ».

dhcp.sh

Code: [Sélectionner]
[ -z "$clientid" ] && clientid="$(proto_dhcp_get_default_clientid "$iface")" [ -n "$clientid" ] && clientid="-x 0x3d:${clientid//:/}"
Commit e24ac1c (odhcp6c)

Code: [Sélectionner]
diff --git a/src/dhcpv6.c b/src/dhcpv6.c index fa0c2a1..2075006 100644 --- a/src/dhcpv6.c +++ b/src/dhcpv6.c @@ -479,9 +479,11 @@ static void dhcpv6_send(enum dhcpv6_msg type, uint8_t trid[3], uint32_t ecs) ia_na_entries /= sizeof(*e); struct dhcpv6_ia_hdr hdr_ia_na = { - htons(DHCPV6_OPT_IA_NA), - htons(sizeof(hdr_ia_na) - 4), - htonl(1), 0, 0 + .type = htons(DHCPV6_OPT_IA_NA), + .len = htons(sizeof(hdr_ia_na) - 4), + .iaid = htonl(ifindex), + .t1 = 0, + .t2 = 0, }; struct dhcpv6_ia_addr pa[ia_na_entries]; @@ -1156,7 +1158,7 @@ static int dhcpv6_handle_reply(enum dhcpv6_msg orig, _unused const int rc, continue; // Test ID - if (ia_hdr->iaid != htonl(1) && otype == DHCPV6_OPT_IA_NA) + if (ia_hdr->iaid != htonl(ifindex) && otype == DHCPV6_OPT_IA_NA) continue; uint16_t code = DHCPV6_Success;
En résumé, il n'y a que le changement de DUID qui est potentiellement impactant. Dans la requête d'intégration, on voit que la modif. correspond à IA_NA et pas à IA_PD.

Édit : D'ailleurs c'est assez curieux que IA_PD ne soit pas traité. Un oubli ?

Voir scripts: dhcpv6: harmonize IAID between IA_NA and IA_PD requests

Code: [Sélectionner]

diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.sh b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
index 6e257e11cb..71777bc4e1 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
@@ -1,6 +1,7 @@
 #!/bin/sh
 
 . /lib/functions.sh
+. /lib/functions/network.sh
 . ../netifd-proto.sh
 . /lib/config/uci.sh
 init_proto "$@"
@@ -9,7 +10,7 @@ proto_dhcpv6_init_config() {
 	renew_handler=1
 
 	proto_config_add_string 'reqaddress:or("try","force","none")'
-	proto_config_add_string 'reqprefix:or("auto","no",range(0, 64))'
+	proto_config_add_string reqprefix
 	proto_config_add_string clientid
 	proto_config_add_string 'reqopts:list(uinteger)'
 	proto_config_add_string 'defaultreqopts:bool'
@@ -85,7 +86,25 @@ proto_dhcpv6_setup() {
 	[ -n "$reqaddress" ] && append opts "-N$reqaddress"
 
 	[ -z "$reqprefix" -o "$reqprefix" = "auto" ] && reqprefix=0
-	[ "$reqprefix" != "no" ] && append opts "-P$reqprefix"
+	[ "$reqprefix" != "no" ] && {
+		# append interface IAID if none specified
+		local iaid=$(echo -n $reqprefix | sed -nr 's/^.*:([0-9A-Fa-f]{1,8})$/\1/p')
+		[ -z "$iaid" ] && {
+			network_generate_iface_iaid iaid "$iface"
+			reqprefix="$reqprefix:$iaid"
+		}
+		# validate prefix/length hint
+		local hint=${reqprefix%:$iaid}
+		[ "${hint#/}" -le "128" ] 2>/dev/null && {
+			reqprefix=${reqprefix#/}
+		} || {
+			validate_data cidr6 "$hint" 2>/dev/null || {
+				reqprefix="0:$iaid"
+				logger -p warn -t dhcpv6 "$iface: ignoring invalid prefix hint"
+			}
+		}
+		append opts "-P$reqprefix"
+	}
 
 	[ -n "$clientid" ] && {
 		clientid="$(hexdump_2hex "$clientid")"

Hyperlien : https://github.com/openwrt/openwrt/pull/23758/commits/f08cd5ce5d66d76fa6e282d6e3f29bab9cdf8023

Si l'IAID n'est pas spécifié explicitement alors il prend pour valeur le code de hachage du nom de l'interface. Cela génère une demande pour une nouvelle liaison DHCPv6 côté FAI, ce qui est rejeté.

nico1881 · « **Réponse #66 le:** 03 juillet 2026 à 21:27:14 »

Merci pour tous ces pointeurs!
Est-ce qu'on peut en conclure que ceci doit marcher à tous les coups?

Code: [Sélectionner]

config interface 'wan6'
    option device '@wan'
    option proto 'dhcpv6'
    #option ipassign '60' <--- à utiliser seulement pour splitter en sous-réseaux
    option reqaddress 'try'
    option reqprefix 'auto:1'
    option norelease '1'
    option clientid '00030001xxxxxxxxxxxx'  <--- remplacer xxx par MAC de la box

basilix · « **Réponse #67 le:** 04 juillet 2026 à 07:02:05 »

Code: [Sélectionner]

config interface 'wan6'
    option device '@wan'
    option proto 'dhcpv6'
    option reqprefix ':1'
    option norelease '1'
    option clientid '00030001xxxxxxxxxxxx'   <--- remplacer xxx par MAC de la box

L'option ip6assign ne doit pas figurer dans la section wan6 car cela n'aurait aucun sens.

Il aurait fallu libérer l'ancien bail DHCPv6 puis demander un nouveau (avec l'IAID OpenWrt). Par conséquent, il n'aurait pas été nécessaire de spécifier l'option reqprefix.
Je ne sais pas exactement comment réaliser cela. Chez Orange, on peut éventuellement débrancher la fibre pendant une dizaine de minutes pour réinitialiser en quelque
sorte les équipements réseaux du FAI. On rebranche ensuite le routeur OpenWrt et celui-ci lance un nouveau cycle SARR (avec le nouveau IAID).

nico1881 · « **Réponse #68 le:** 04 juillet 2026 à 12:43:41 »

Le post initial est modifié. Merci de ton aide!

rqdb · « **Réponse #69 le:** **Aujourd'hui** à 10:47:58 »

salut à tous,
je suis sur un BPI-R3 avec OpenWrt version 25.12.5, avec un ONT externe fonctionnel, et je n'arrive pas à attraper une IP, ni V4 ni V6. J'ai testé quasiment tout ce que j'en trouvé dans les différents messages mais rien n'y fait. Quelqu'un pourrait-il partager sa configuration fonctionnelle actuelle ? Quelqu'un d'autre à un est sur un BPI-R3 ?