Truc étrange, si je remet mon ancien range privé IPv6 (fd00::1/64), elle repart dans les choux. En chantant ça pour un autre /64, elle est plus réactive.

Ce serait une piste intéressante peut-être / un dénominateur commun ? Ou tout simplement l'IPv6 qui fout la grouille.  A voir ?

Je referai le test ce weekend. Juste remettre mon ancien préfixe sans rien changer d'autre.
Une analyse dans le network monitor de chrome m'avais indiqué que c'était pas la page front qui ramait, mais l'appel qu'elle faisait aux API. Je sait pas si il peut y avoir un lien.

Si quelqu'un a une BBox qui elle a bien vécu l'update et veux bien faire le test de changer son local prefix, je prends.

Et du coup, mon smokeping confirme tout ça, je n'ai plus mes grosses pertes de connectivité en pleine nuit.

Affaire à suivre

C'est une bonne nouvelle si ça fonctionne mieux  ! Concernant les appels aux API and co, j'ai souvent des erreurs 500 obscures et autres joyeusetés (firmware 178) ... En insistant ça passe...

D'ailleurs en parlant d'API j'ai pu récupérer quelques infos grâce à cette doc : https://api.bbox.fr/doc/apirouter/index.html

J'ai fait une demande aux devs pour avoir accès aux métriques qui nécessitent une authentification (il faut un token apparemment), ils m'ont répondu il y a quelques mois qu'ils prenaient me demande en compte mais toujours rien. Ils ont, à juste titre, autre chose à faire je pense !

Oui, c'est fixe en IPv6 et IPv4

UPNP ça compte pour pas basculer sur CG-NAT ?

UPNP fonctionnera pas en CG-NAT, c’est de l’ouverture de port automatique.

Le cgnat chez bytel c’est moins de 0.1% des clients n’ayant aucune règle de redirection de ports dans leur box, et un simple appel au service client règle le soucis si jamais. Donc tu peux ne pas en tenir compte, ça ne sera pas un soucis

IPv4 et préfixe IPv6 (si dispo, ce qui est un peu aléatoire pour l’instant) sont fixes. C’est pas contractuel, ça peut bouger si grosse modification de l’infra, mais dans les faits c’est totalement fixe.