Auteur Sujet: Config OpenWRT derrière ONT Bouygues (Lu 32977 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:** **Hier** à 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:** **Hier** à 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:** **Aujourd'hui** à 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:** **Aujourd'hui** à 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é.