La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: alainco le 25 août 2022 à 00:26:05
-
Bonjour,
J'ai un PC Windows 11 family, et une Freebox révolution.
Je suis en FTTH coté box, et relié en ethernet (via un hub et un adaptateur USB-ethernet).
J'arrive bien au début à être connecté en IPV6, et je ping bien, le télécharge en http ipvg.google.com...
Et puis pile 30 minutes après, ma route par defaut disparait. je vois que l'adresse link local de la box est marquée "caduque"...
je ne suis pas en DHCPv6 sur la box, donc en SLAAC.
Mais si je fais un ipconfig /renew6, la route revient, et disparait 30 minutes après.
J'ai joué avec le firewall (icmpv6 autorisé sur tout), avec netsh
netsh interface ipv6 set interface 6 advertisedrouterlifetime=65000 ou 60 ou 600 ...
rien ne change...
Visiblement ca doit être les RA/Router Advertisement qui ne passent pas...
j'ai des routeurs openwrt (en mode PA, sans DHCP ni service ipv6 RA/Proxy... rien) qui eux se connectent bien...
Y a t'il une subtilité avec windows 11, avec une freebox revolution...
j'ai regardé quelques messages ici, mais j'ai testé en vain toutes les idées... firewall notamment...
y compris désactiver le mode économie d'énergie pour le dongle ethernet/usb...
si quelqu'un à une piste... c'est peut-être un truc connu?
-
Aucun RA arrive après 30 minutes ou pendant ses 30 minutes un RA arrive à passer ? y'a moyen de faire un capture Wireshark ?
-
le truc c'est qu'installer Wireshark, et s'en servir... la dernière fois que l'ai utilisé un sniffer, yavait de l'IPX et du SNA sur le réseau token-ring. je regarde...
mais c'est comme une horloge, 30 minutes pile... parcontre dès que le PC est inutilisé, mise en veille, et il redémarre avec IPv6...
ok, j'avance j'ai vu un RA (filtre: icmpv6.type == 134)
router lifetime 1800, un recursive dns server fd0f:..::1 lifetime 86400,
from fe80::... ma box, la gatewy
une prefix information qui pointe sur mon préfixe externe en 2a01:...::/64 prefered/valid lifetime 86400
destination ff02::1 (broadcast?) (la MAC adresse est celle de ma box)
+540 sec idem
+400 seconde après, même style
+400 +450 +550...
j'ai dépassé les 1800 seconde, wireshark a changé le comportement
bizare ca se met à marcher
J'ai coupé la capture et ca continue à fonctionner (la route default fonctionne)...
L'installation de Wireshark semble avoir réparé le PC ?
Pourtant j'avais Winpcap 1.60 avant...
j'ai installé usbPcap par contre...
peut être un reboot, mais j'ai rebooté souvent depuis le souci...
Je n'y comprend rien.
Ce matin, perte ipv6/gateway pendant la nuit.
Je lance wireshark, en 5 minutes je capture une RA, et ipv6 revient...
Bug de Schrödinger
-
Ce matin, perte ipv6/gateway pendant la nuit.
Je lance wireshark, en 5 minutes je capture une RA, et ipv6 revient...
30 minutes, c'est 1800 secondes tout pil, et exactement le router lifetime des router advertisements émis par la freebox.
La freebox émet bien des RA périodiques comme tu as pu le constater avec Wireshark, et vu que les firmwares sont peu nombreux et gérés par Free, je mettrai ma main à couper qu'elle fonctionne correctement.
Je mets un billet (un gros, on va dire $100) sur le driver de la carte réseau de ton PC, et à fortiori sur le scénario suivant:
1) la carte réseau s'initialise car le PC démarre ou sort de veille. Le driver configure (entre autre) le filtrage multicast pour accepter les RAs émis vers 33:33:00:00:00:01 (ff02::1).
2) l'OS émet un router sollicitation, recoit un RA et configure la connectivité IPv6.
À partir de ce moment, la connectivité IPv6 est opérationnelle (indépendament d'IPv4 d'ailleurs).
3) un bug dans le driver de la carte réseau fait que le filtre multicast pour 33:33:00:00:00:01 (ff02::1) disparaît de la liste des adresses multicast acceptées. L'OS arrête donc de recevoir les RAs périodiques envoyés par la freebox.
4) comme aucun RA n'est recu par l'OS, le timer d'expiration de la route par défaut de 1800s n'est jamais réarmé et finit par expirer. L'OS retire la route par défaut, comme il se doit de le faire.
5) La connectivité en dehors de ton réseau local (le 2a01:...::/64 que tu mentionnes) est perdue, car même si les adresses IPv6 configurées par SLAAC sont valides pour encore longtemps (86400 - 1800 secondes, peu ou prou), la machine n'a plus de route par défaut active.
Le fait que tu lances une capture Wireshark/Winpcap désactive le filtre multicast de la carte réseau, car Wireshark veut recevoir toutes les trames Ethernet recues (c'est configurable, mais c'est le comportement par défaut car c'est le but de l'outil. C'est ce qu'on appelle "promiscuous mode".). Dès lors:
6) l'OS recoit à nouveau les RAs (ils ne sont plus filtrés par la carte réseau). Il reconfigure une route par défaut et réarme tous les timers (router lifetime, mais également les timers preferred et valid lifetime des adresses IP autoconfigurées et RDNSS).
La machine retrouve une connectivité IPv6 et retrouve le comportement attendu.
7) lorsque tu stoppes ta capture Wireshark, le filtre multicast est réactivé par le driver de la carte réseau. À nouveau, l'OS ne voit plus les RA périodiques et le router lifetime de 1800s expire: la route par défaut est retirée.
Savoir exactement où se trouve le problème est toujours (très) compliqué sous Windows, et les utilisateurs sont encouragés à redémarrer pour résoudre le problème: ca fonctionne bien dans ton cas :) Sauf que reboot toutes les 30min, c'est un peu problématique...
Ce que je ferai à ta place:
1) tenter de mettre à jour le driver de ta carte réseau, pour voir si ca donne quelque chose. J'utilise très peu Windows, mais mon experience me dit qu'utiliser Windows Update et/ou le Device Manager pour mettre les drivers à jour donne de meilleurs résultats que de télécharger et installer un pilote depuis le site du constructeur (en plus d'éviter des malwares).
Si cette méthode ne donne rien (pas de mise à jour), tu pourras te diriger vers le site du constructeur de ta carte réseau, ou si le PC était livré avec un logiciel de mise à jour pour pilotes. bios, etc. utiliser cela.
2) si pas de mise à jour driver disponible, ou que tu perds toujours la route par défaut 30min après un reboot après mise à jour, explore les paramètres du driver de la carte réseau. Si il y est fait mention d'un filtre multicast, et que tu peux le désactiver, fais le. L'impact sur les performances sera plus que minime sur un réseau domestique.
3) si toujours pas d'amélioration, essayer d'emprunter un adaptateur Ethernet-USB pour te connecter et voir si le problème persiste peut éventuellement aider.
4) si tu as des logiciels "network optimizers" éventuels installés sur ton PC, désactive les et désinstalle les. Ils ne servent plus à rien en 2022, voire sont contre-productifs.
5) certains antivirus ont également un "network scanner" ou autre firewall ou filtre dynamique qui mérite d'être désactivé pour le test, si présent.
Dans tous les cas, lorsqu'une modification de paramètres ne produit pas les résultats escomptés, n'oublie pas de restaurer les paramètres antérieurs à la modification pour ne pas t'en créer d'autres. Je pense notamment aux firewalls qu'il faut bien entendu réactiver après les tests pour protéger la machine.
Bon courage pour le debug!
-
Merci,
je partage votre analyse...
Merci pour le conseil d'installer Wireshark, plus simple que je ne pensais...
Le pilote du dongle USB ne se met pas à jour, mais je vais voir si j'en trouve une version constructeur...
j'ai trouvé mon circuit, un Asix 88179 et un pilote plus récent
https://www.asix.com.tw/en/product/USBEthernet/Super-Speed_USB_Ethernet/AX88179
après une journée, et des mise en veille, des 1800 secondes, et pas de wireshark, le nouveau pilote asix 88179 v2.22.3.0 semble avoir résolu lespertes d'IPV6 (pertes de ICMPV6 RA)... dommage qu'il soit pas dans les update officielles de windows.
-
Bonjour,
A lire votre post sans tout comprendre des abréviations employées, j'ai le sentiment d'avoir un problème proche du votre si ce n'est le même.
Je suis client Free fibre (freebox revolution) et j'ai un serveur FTP chez moi (proftpd sur Truenas core 13) il est accessible par IPV4 et IPV6 (récent)
IPV4 est stable alors qu'avec IPV6 je m'arrache le peu de cheveux qui me restent.
Depuis que l'IPV6 est activée sur le serveur FTP, il a une IPV6 permanente, malgré tout de manière aléatoire, l'accès depuis internet vers cette IP ne se fait plus.
Souvent pour contournement, je me connecte à l'admin de la Freebox et j'active le DHCP V6, cela réactive de suite l'accès sans comprendre pourquoi, puis après un certain temps, il me faut me reconnecter à l'admin de la box pour cette fois décocher le DHCP V6 pour que cela se remette à fonctionner.
Je vous avoue ne rien comprendre à ce comportement, pensez vous qu'il s'agisse d'un bug de la box en IPV6?
Si vous avez des explications ou controles à me suggerer, essayez de rester compréhensible à un non expert de ce genre de soucis. Merci :)
-
Lorsque tu as des pertes de connectivité, quelle est la configuration IPv6 sur ce truenas ? Peux-tu faire deux captures d'écrans, une lorsque tout fonctionne et une lorsque tu as le souci ? Tu peux éventuellement masquer les 3 groupes de chiffres après "2a01:" dans les adresses IP, si tu as peur de poster les adresses IPv6 de ton NAS ici.
-
Bonjour, merci pour votre réponse,
en fait sur le TrueNAS rien ne change, l'IPV6 est toujours dispo et elle répond au ping sur le réseau local.
-
Et pendant que tu ne peux plus accéder à ton nas depuis l'extérieur, si tu te connectes sur le terminal du NAS et que tu pingues ping6.online.net
ça fonctionne ?
-
Bonjour, pour le moment c'est opérationel et donc le ping demandé passe sans soucis.
l'ipv6 du NAS est statique, configurée sur l'interface du NAS en plus de l'IPV4
-
OK. Pour qu'on sache si ce sont les router advertisements qui ne sont plus recus ou autre chose, tu peux également exécuter les commandes suivantes :
ifconfig
netstat -nr
ndp -an
lors d'un souci de connectivité.
-
pour répondre , voici le résultat des 3 commandes
pour IFCONFIG
Pour NETSTAT
Pour NDP (la ligne surlignée en jaune , je ne sais pas ce que c'est)
je viens de perdre la connectivité V6 et lorsque je fais un ping ping6.online.net sur la console du serveur , j'obtiens
Ping: UDP connect : No route to host
-
Je ne sais pas si cela aide mais:
quand depuis internet je n'ai plus accès, si je paramètre dans filezilla un compte FTP (donc depuis un pc sur le même LAN que le NAS) en tapant sur le FQDN qui résoud bien sur l'ipv6 du NAS, la connexion FTP est réussie sans soucis.
Autre test depuis un pc du LAN quand il n'y a plus d'accès depuis internet
si je pingue l'IPV6 du NAS cela répond et de même si je pingue le FQDN c'est bien résolu sur l'ipv6.
Je viens de voir qu'il n'y avait pas de passerelle par défaut IPv6 configurée sur le NAS et donc j'ai mis comme valeur fe80::1 et en console je parviens à avoir une réponse en pinguant ping6.online.net alors que cela ne passait pas sans passerelle. l'accés depuis internet reste KO après un certain temps on obtient une erreur 504.
-
Yes, on voit bien qu'il n'y a pas de default route IPv6. Je suppose que le fait de désactiver/réactiver DHCPv6 relance radvd et ré-émet un router advertisement.
Si tu laisses le serveur DHCPv6 désactivé, le problème se produit-il toujours ? Note que DHCPv6 n'est pas nécessaire, SLAAC est suffisant pour configurer IPv6 sur tous types de systèmes. D'ailleurs, je ne suis pas sûr que freenas supporte DHCPv6...
-
Ce matin j'ai rebooté la FB et il y a eu une MAJ en 4.7.8, depuis je n'arrive plus à avoir accès en IPV6 que ce soit avec DHCPV6 activé ou non.
Ce qui reste stable c'est uniquement en IPV4 sur l'IP publique de la box, pour les machines distantes , elles ont IPV4 et IPV6 d'actifs et dès lors la première résolution DNS etant en IPV6 l'accès ne fonctionne pas avec IPV4. je dois donc modifier tous les réglages pour ne plus utiliser de FQDN pour essayer de joindre le FTP sur le NAS et remplacer par l'IP publique V4.
C'est très pénible et vraiment IPV6 je suis largué dans ce genre de problèmes. :(
LE NAS c'est un TrueNAS core V13 pas Freenas et oui IPV6 est supporté sans soucis.
-
Peux-tu faire une capture wireshark avec un PC connecté en Ethernet à la box, si possible en te branchant dans le même port que celui que tu utilises d'habitude pour ton NAS ? Laisse la tourner ~1-2h. Tu peux mettre comme filter icmp6 si tu ne veux pas que ta capture soit énorme.
Le but est de voir si 1) il y a des router advertisements et 2) ce qu'ils contiennent.
-
Je me souviens qu'il y a très longtemps, les box free en plastique blanc style tupperware (crystal?) supportaient IPv6, mais aucun router advertisement n'était émis après le reboot suivant une mise à jour. Il fallait manuellement reboot une fois de plus pour avoir IPv6.
C'était l'époque où on devait l'activer dans l'espace client, j'espère bien que c'est révolu.
-
durant le weekend j'ai modifié la configuration réseau coté NAS, puis j'ai mis à jour la FBx Revolution en V4.7.8 (sans changement notable) puis j'ai de nouveau rebooté la box et comme le NAS était en autoconfiguration IPV6, il a reçu une config fonctionnelle cette fois ci.
Depuis les pings IPv6 sortent sans soucis et les accés FTP externes sont redevenus fonctionnels. Je ne sais pas ce qui merdait, ca me dépasse de trop loin, mais pour le moment tout fonctionne.
JE reste en surveillance pour la stabilité sur la durée???
J'espère qu'a chaque reboot je ne devrais pas faire un second reboot comme tu l'indiques pour que cela rétablisse le fonctionnement.
-
Si ca t'intéresse, tu peux me donner le hostname/IPv6 de ton NAS, et je l'ajoute à ma plateforme de supervision qui ping toutes les minutes. Je te ferai ensuite un graphe sur quelques semaines pour vérifier la stabilité.
Bon courage en tout cas!