Salut Simon, merci pour le test 👍

De ce que je vois ça a l’air plutôt propre : pas de perte jusqu’à la destination et la latence se stabilise autour de ~40 ms une fois arrivé côté Hetzner. 

Il y a un peu de variation sur un hop avant Hetzner mais comme la destination finale reste stable et sans perte, ça ne semble pas poser de problème réel côté trafic.

En tout cas merci d’avoir pris le temps de poster le test, c’est toujours utile d’avoir des points de comparaison 👍

@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 ?

Merci pour l'info.
Au final, après avoir débranché l'ONT un bon quart d'heure, l'ipv6 est de retour.
Sans ajout de l'option iaid ni suppression de la nouvelle option 'dhcp_default_duid' comme je pensais le faire au début.
Bref, j'ai laissé la chaîne générée par défaut.

config globals 'globals'
        option dhcp_default_duid '***'
Je pense que le fait d'avoir éteint momentanément l'ONT a dû aider.
Testé avec deux routeurs (mips et x86-64)

Oui, c'est aussi décalé.

Bonjour,

   Merci Mastah sur le suivi de ce sujet et en particulier la mise à jour du wiki. L''ONT WAS-110 à 60 euros fait rêver  (j'ai payé mon ONT FS pour 250 euros...). Par contre j'ai plusieurs questions :
- Est ce que la commande de l'ONT WAS-110 sur Alibaba a été testé ? Possible de faire un retour sur la commande de cet ONT ? La qualité est la même que sur les autres liens Aliexpress et fibermall ?
- Quel modèle prendre sur Alibaba ? Pour moi ce n'est pas clair du tout (Pas seulement pour cet ONT, mais pour tout Alibaba ...  )

Merci pour ton retour

De nombreux téléviseurs ne gèrent pas H.264 niveau 4.2, niveau est nécessaire pour avoir 50 images par seconde.

Par contre, je n'ai pas bien compris, si j'ai une source 25p, le fluc est converti en 25i, mais les deux demi images sont présentées à des moments temporels différents, non ?