La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Orange / Sosh => 
5G Home Orange => Discussion démarrée par: vivien le 06 juillet 2025 à 22:58:36
-
Perte de la connectivité IPv6 sur la Flybox 5G (en 5G NSA) sous Windows / Ubuntu
Edit : les paquets IPv6 partent bien vers internet, le problème est que le retour n'est pas possible.
J'ai une Flybox 2 5G Organe (box Nokia Wi-Fi 6) depuis plus d'un an. Je capte la bande 3,5 GHz, mais je suis en 5G NSA (la 5G SA est réservée aux nouveaux clients).
Depuis plusieurs mois, je note qu'au reboot de ma box, je peux ne pas avoir d'IPv6. Je dirais un reboot sur 4 (mais ce n'est pas si grave, car je débranche rarement ma box).
L'APN est bien IPv6 only et l'IPv4 fourni par la box passe par du 464XLAT.
Quand je perds l'IPv6, c'est sur tous mes périphériques sauf mon Pixel 6 connecté en Wi-Fi. J'ai plusieurs PC connectés en Wi-Fi et un en Ethernet (directement à la box). Dans tous les cas Windows, comme Ubuntu, je n'ai plus de connectivité IPv6. Un vieux Samsung S6 Edge sous Android 7.0 connecté en Wi-Fi perd également l'IPv6. Sur mon Pixel 6 (Android 16) l'IPv6 fonctionne parfaitement et c'est bien l'IPv6 de la box 5G, pas celle de mon opérateur mobile.
Voici une petite vidéo montrant le problème : (à la fin, c'est mon fils qui se plaint que l'application France TV Okoo refuse de fonctionner sur le S6 Edge)
https://lafibre.info/videos/ipv6/202507_flyxbox_5g_perte_ipv6.mp4
De nombreuses applications qui ont un fallback IPv6 vers IPv4 très lent ou absent posent alors un problème. Comme le DNS est un DNS64 il tente de partir en IPv6 pour tous les sites, même ceux IPv4 only, avant de basculer en IPv4. Même un SpeedTest dans le navigateur peut mettre beaucoup de temps avant de se lancer.
Je ne sais pas trop comment avancer sur cette problématique. Comme un reboot résout le problème, je ne pense pas que le support pourra faire quelques chose.
La capture Wireshark en intégralité : 202507_flyxbox_5g_perte_ipv6.pcapng.gz (https://lafibre.info/images/wireshark/202507_flyxbox_5g_perte_ipv6.pcapng.gz) (fichier lisible avec Wireshark)
-
Le PC Dell sous Windows s'attribue 2 IPv6 par autoconfiguration, et en récupère une autre via DHCPv6.
Il utilise uniquement l'une des deux IP d'autoconfiguration, et la Flybox ne répond à rien (peut-être qu'elle filtre, et ne répond pas à n'importe quelle IP, mais je ne vois pas pourquoi).
Le ping vers l'Android fonctionne parce qu'il est envoyé directement à l'adresse MAC du téléphone.
Est-ce que l'adresse MAC du Pixel 6 reste la même à chaque connexion ?
Selon https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior, il y a des cas où elle pourrait changer, mais normalement un simple reboot de la Flybox ne suffirait pas.
-
Bonjour,
J'ai un souci IPv6 assez proche avec ma Livebox 3.
Bizarre que cela fasse un blocage IPv6 sur de la box (mobile dans ce sujet) très récente...
La Livebox 3, il y a des années, avait un souci pire (la box n'avais même plus de préfixe IPv6)... mais c'était à chaque reboot de la connexion internet de la Box, sans reboot de la box elle-même: le moindre reboot complet de la box réglait le souci (et d'ailleurs j'avais contacté le service client pour ce problème et c'était leur seul préconisation).
Depuis quelques temps, le souci est bien plus proche qu'ici: la Livebox 3 récupère quand même un préfixe IPv6 de façon normale, mais mon PC n'a plus d'IPv6 publique à chaque reboot internet de la box, sans qu'il y ai reboot complet de la box (ce dernier règle encore le problème, donc bon je n'appelle plus le service client pour ça vu mon expérience passé avec quand le souci était proche).
-
Est-ce que l'adresse MAC du Pixel 6 reste la même à chaque connexion ?
Mon Pixel6 est configuré par défaut avec "Utiliser une adresse MAC aléatoire" toutefois je ne sais pas si la MAC est différente à chaque 1ère connexion à un SSID, mais je se sais pas si elle change une fois qu'on est connecté au SSID.
(https://lafibre.info/testdebit/android/202507_pixel6_android16_confidentialite_wifi.webp)
J'ai un souci IPv6 assez proche avec ma Livebox 3.
N'hésite pas à demander une box plus récente (c'est facturé 10€).
-
Mon Pixel6 est configuré par défaut avec "Utiliser une adresse MAC aléatoire" toutefois je ne sais pas si la MAC est différente à chaque 1ère connexion à un SSID, mais je se sais pas si elle change une fois qu'on est connecté au SSID.
Quand il est connecté au wifi, les propriétés du réseau devraient donner l'adresse MAC.
-
Testé : l'adresse mac aléatoire est fixe et ne change pas : c'est 7e:5f:44:27:b8:c9 même après avoir éteint puis redémarré mon téléphone.
-
C'est cohérent, ça fonctionne comme ça aussi chez Apple. J'ai cru voir que sur Linux (au moins Fedora KDE) cependant, ça change à chaque connexion, je trouve ça un peu excessif.
-
Sous Ubuntu, j'ai un comportement similaire à Android.
Il y a plus de choix de configuration :
(https://lafibre.info/testdebit/ubuntu/202507_ubuntu_2504_confidentialite_wifi.webp)
-
Testé : l'adresse mac aléatoire est fixe et ne change pas : c'est 7e:5f:44:27:b8:c9 même après avoir éteint puis redémarré mon téléphone.
Normalement la MAC générée est stable pour un SSID donné, donc ton téléphone devrait conserver la même MAC pour toutes les connexions à un SSID donné, peu importe l'AP (BSSID) sur lequel il se connecte.
-
Je ne sais pas trop comment avancer sur cette problématique. Comme un reboot résout le problème, je ne pense pas que le support pourra faire quelques chose.
Peux-tu faire un traceroute vers des destinations IPv6 lorsque le bug se produit ?
As-tu moyen de voir les routes installées dans la FlyBox pour comparer ?
Vu que le CLAT de la box fonctionne, soit la box filtre/ne route pas le /64 qu'elle annonce sur son LAN (le seul qui lui soit délégué par le réseau mobile), soit c'est un souci de core network où l'APN sur lequel tu tombes n'a pas d'accès IPv6.
-
Le problème de perte d'IPv6 s'est de nouveau reproduit. Sur ma Flybox 5G, j'ai bien la plage IPv6 2a01:cb01:1055:bc08:: (elle ne donne malheureusement rien d'autre pour IPv6).
Sur mon Android 16, j'ai bien une connectivité IPv6 fonctionnelle avec une IP de la plage 2a01:cb01:1055:bc08::
Sous Linux, je récupère bien une IPv6 de la bonne plage :
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb01:1055:bc08::fd4/128 scope global dynamic noprefixroute
valid_lft 83386sec preferred_lft 40186sec
inet6 2a01:cb01:1055:bc08:4cf2:32f5:c1c:6e75/64 scope global temporary dynamic
valid_lft 86150sec preferred_lft 42950sec
inet6 2a01:cb01:1055:bc08:2e7b:3f2a:cc2d:eaa2/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86150sec preferred_lft 42950sec
inet6 fe80::53f7:fcb1:63e2:f834/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Route par défaut pour sortir sur internet :
$ ip -6 route show
2a01:cb01:1055:bc08::fd4 dev wlp2s0 proto kernel metric 600 pref medium
2a01:cb01:1055:bc08::/64 dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 1024 pref medium
default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 20600 pref medium
Quand je fais un traceroute, je n'ai donc aucun saut qui s'affiche :
$ mtr -rwc10 google.com
Start: 2025-07-14T09:25:15+0200
HOST: HP Loss% Snt Last Avg Best Wrst StDev
Redémarer l'ordinatuer ne change rien.
Je n'ai pas redémarré ma flybox, donc je peut faire d'autres tests.
-
pour moi la route par défault est bien là
-
La route /64 est là, elle est juste sur la 2ème ligne :
2a01:cb01:1055:bc08::/64 dev wlp2s0 proto ra metric 600 pref mediumMais elle permet juste de joindre les IPv6 globales des autres machines sur le LAN, elle ne sert à rien pour Internet.
C'est l'adresse link-local qui sert au routage.
Les paquets ont l'IP du serveur en destination, mais envoyés à l'adresse MAC du routeur : c'est la même logique qu'en IPv4 (la différence est qu'il n'y a pas de NAT : l'IP source des paquet est globale).
"ip route get 2a0b:cbc0:10:1af1:b2e::1f0" doit donner "2a0b:cbc0:10:1af1:b2e::1f0 from :: via fe80::xxxx ....".
-
Le Router Advertisement de la Flybox a les flags M (DHCPv6 stateful, qui n'est pas présent pour une Livebox) et O.
Mais il contient aussi le préfixe, avec le flag A (qui indique que le préfixe peut être utilisé pour l'autoconfoguration SLAAC).
Le Linux a donc 3 IPv6 :
- une obtenue via DHCPv6 : 2a01:cb01:1055:bc08::fd4/128
- deux via SLAAC : 2a01:cb01:1055:bc08:4cf2:32f5:c1c:6e75/64 et 2a01:cb01:1055:bc08:2e7b:3f2a:cc2d:eaa2/64
Android ne fait pas de DHCPv6.
Peut-être que la Flybox a un problème quand un client fait à la fois SLAAC et DHCPv6.
Là ton PC a normalement utilisé 2a01:cb01:1055:bc08:4cf2:32f5:c1c:6e75 comme source.
Je me demande si la Flybox répondrait aux autres IPv6 ou pas.
Qu'est-ce qui se passe si tu supprimes les IPv6 SLAAC ?
Ce serait quelque chose comme :
ip -6 addr del 2a01:cb01:1055:bc08:4cf2:32f5:c1c:6e75/64 dev wlp2s0
ip -6 addr del 2a01:cb01:1055:bc08:2e7b:3f2a:cc2d:eaa2/64 dev wlp2s0
(par défaut elles risquent de revenir assez rapidement)
Le PC devrait se mettre à utiliser l'IP DHCPv6 comme source (ce qu'on peut confirmer avec "ip route get xxxxx" avec n'importe quelle IPv6 globale sur Internet).
-
Peux-tu faire un ip neigh pour voir si l'adresse link-local du routeur est bien resolue ?
Aussi, peux-tu faire un tcpdump -pns0 -i $interface icmp6 et attendre de voir passer un router advertisement, pour qu'on voit ce que la box annonce ?
Profites en pour faire un ping 2a0b:cbc0:10:1af1:b2e::1f0 pour qu'on voit si 1) le ping est bien émis par ton PC et 2) la flybox renvoie éventuellement un destination unreachable.
Si tu as une connectivité sur Android et pas sur un PC qui fait une requête DHCPv6, ca peut valoir le coup de continuer à capturer jusqu'à ce que le tcpdump capture un échange DHCPv6.
Et désactiver DHCPv6 sur le PC, pour voir si cela change quelque chose (car c'est une des différences entre Android et un laptop : pas de support DHCPv6).
Si c'est bien un souci lié à DHCPv6, ca serait bien qu'on puisse trouver le souci dans la capture... mais peut-être que désactiver DHCPv6 sur la box est une bonne idée. Cela ne sert pas à grand chose de toute façon, SLAAC fait déjà tout ce qu'il faut.
EDIT: comme le dit hwti, avoir une link-local en tant que route par défaut est OK, pas de souci. J'ai cela aussi sur mes machines et je n'ai aucun problème :
$ ip -6 r
2a01:cb08:xxxx:xxxx::/64 dev ens1 proto ra metric 100 pref medium
fe80::/64 dev ens1 proto kernel metric 1024 pref medium
default via fe80::da7e:xxxx:xxxx:xxxx dev ens1 proto ra metric 100 pref high
-
La seule option de la Flybox concernant IPv6, c'est la désactivation de DHCP v6.
(https://lafibre.info/images/ipv6/202507_flyxbox_desactivation_dhcpv6.webp)
Je l'ai désactivé, mais toujours pas d'IPv6 sous Ubuntu ou Windows.
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e/64 scope global temporary dynamic
valid_lft 86083sec preferred_lft 42883sec
inet6 2a01:cb01:1055:bc08:2e7b:3f2a:cc2d:eaa2/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86083sec preferred_lft 42883sec
inet6 fe80::53f7:fcb1:63e2:f834/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Route :
$ ip -6 route show
2a01:cb01:1055:bc08::/64 dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 1024 pref medium
default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 20600 pref medium
-
$ ip neigh
192.168.1.1 dev wlp2s0 lladdr a8:fb:40:d2:3c:4f REACHABLE
fe80::aafb:40ff:fed2:3c4f dev wlp2s0 lladdr a8:fb:40:d2:3c:4f router STALE
$ sudo tcpdump -pns0 -i wlp2s0 icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:12:44.078714 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 1, length 64
16:12:45.088353 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 2, length 64
16:12:46.112386 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 3, length 64
16:12:47.136297 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 4, length 64
16:12:48.160284 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 5, length 64
16:12:49.184361 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 6, length 64
16:12:49.312234 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:12:49.314950 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:12:50.208276 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 1, seq 7, length 64
16:12:54.420856 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:12:54.420915 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:13:16.398711 IP6 fe80::22df:b9ff:febf:c2cc > ff02::1:ff27:b8c9: ICMP6, neighbor solicitation, who has fe80::7c5f:44ff:fe27:b8c9, length 32
16:13:46.144336 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:13:46.146077 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:13:51.285197 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:13:51.285271 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
-
Coté Android 16, plus de connectivité IPv6, que ce soit avec DHCPv6 activé ou non.
Pourtant, c'était bien fonctionnel sous Andorid 16 (pas avec mon Android 7.0) la dernière fois, avec le préfixe Orange de ma Flybox.
-
OK, on voit que le default router (fe80::aafb:40ff:fed2:3c4f) répond bien aux neighbor discoveries. Il devrait donc passer en REACHABLE si tu refais ip neigh pendant que ton ping tourne ou peu après l'avoir lancé.
On voit que les paquets sont bien émis par ton PC avec une de ses IP source dans le /64 délégué (2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e), très probablement vers la flybox. Tu pourrais retenter en ajoutant l'option -e à tcpdump pour voir si l'adresse MAC de destination est bien a8:fb:40:d2:3c:4f, mais au vu de tes tables de routage et NDP, je suis quasiment sûr que c'est le cas.
Se pose maintenant la question de savoir si le trafic est droppé dans le sens LAN -> internet ou dans l'autre sens. Si je te passe une adresse IP en MP, tu peux faire un ping dessus ?
À cause du firewall du réseau mobile, je n'ai aucune réponse si j'envoie des pings vers ton PC depuis chez moi.
-
Coté Android 16, plus de connectivité IPv6, que ce soit avec DHCPv6 activé ou non.
Pourtant, c'était bien fonctionnel sous Andorid 16 (pas avec mon Android 7.0) la dernière fois, avec le préfixe Orange de ma Flybox.
Est-il possible que le téléphone ait utilisé sa connectivité cellulaire plutot que wifi quand il s'est rendu compte que le wifi n'arrivait pas à joindre internet ? iOS fait ca pour sûr si on ne désactive pas expressément "Wifi assist".
-
Aussi, peux-tu faire un tcpdump -pns0 -i $interface icmp6 et attendre de voir passer un router advertisement, pour qu'on voit ce que la box annonce ?
Profites en pour faire un ping 2a0b:cbc0:10:1af1:b2e::1f0 pour qu'on voit si 1) le ping est bien émis par ton PC et 2) la flybox renvoie éventuellement un destination unreachable.
Il y a déjà une capture dans le premier message.
On voit les pings envoyés par le PC, qui semble corrects (envoyés à l'adresse MAC de la Flybox), et aucune réponse.
-
Se pose maintenant la question de savoir si le trafic est droppé dans le sens LAN -> internet ou dans l'autre sens. Si je te passe une adresse IP en MP, tu peux faire un ping dessus ?
À cause du firewall du réseau mobile, je n'ai aucune réponse si j'envoie des pings vers ton PC depuis chez moi.
Le traceroute est vide, donc ça donne l'impression que la Flybox ne route rien du tout.
Normalement, à moins d'une configuration un peu bizarre, elle devrait répondre avec son IPv6 sur le premier saut, quel que soit le comportement du réseau mobile.
-
Vivien ping depuis le LAN de la flybox vers une de mes machines. Voici ce que je vois de mon côté, sur la machine en question :
16:27:57.706485 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a01:cb08:xxxx:xxxx:8820:12a:74d0:79b: ICMP6, echo request, id 2, seq 112, length 64
16:27:57.706535 IP6 2a01:cb08:xxxx:xxxx:8820:12a:74d0:79b > 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e: ICMP6, echo reply, id 2, seq 112, length 64
16:27:57.736727 IP6 2a01:cb01:1055:bc08:0:47:315f:bb01 > 2a01:cb08:xxxx:xxxx:8820:12a:74d0:79b: ICMP6, destination unreachable, unreachable route 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e, length 112
Donc:
- tes paquets sont bien routés vers internet
- les réponses sont bien routées vers ta FlyBox, puisque c'est elle qui génère les ICMP destination unreachable (2a01:cb01:1055:bc08:0:47:315f:bb01)
- ta FlyBox pense ne pas avoir de *route* vers le préfixe qui lui est délégué (2a01:cb01:1055:bc08::/64).
Cela confirme mon intuition d'il y a quelques messages : la flybox a bien une connectivité IPv6 fonctionnelle (je m'en doutais car la connectivité v4 via son CLAT fonctionne), elle a juste "oublié" sa route vers son LAN.
As-tu moyen de laisser tourner le ping et de continuier à capturer les ICMPv6? Je voudrais voir si la flybox émet des neighbor discoveries vers 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e (voire vers n'importe quelle autre adresse GUA, ce que je pense qu'elle ne fera pas du fait de la perte de route).
-
Est-il possible que le téléphone ait utilisé sa connectivité cellulaire plutot que wifi quand il s'est rendu compte que le wifi n'arrivait pas à joindre internet ? iOS fait ca pour sûr si on ne désactive pas expressément "Wifi assist".
Non, j'avais vérifié que c'était le bon préfixe IPv6 qui était utilisé quand je vais sur https://ip.lafibre.info/
-
As-tu moyen de laisser tourner le ping et de continuier à capturer les ICMPv6? Je voudrais voir si la flybox émet des neighbor discoveries vers 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e (voire vers n'importe quelle autre adresse GUA, ce que je pense qu'elle ne fera pas du fait de la perte de route).
Le ping vers ton IPv6 continue (sans réponse).
J'ai supprimé de la capture les trés nombreuses lignes "ICMP6, echo request, id 2, seq 603, length 64" vers ton IPv6.
Voici le trafic qui reste :
16:35:54.784240 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:35:54.786184 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:35:59.867553 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:35:59.867612 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:36:26.099323 IP6 fe80::aafb:40ff:fed2:3c4f > ff02::1: ICMP6, router advertisement, length 96
16:36:48.032312 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:36:48.034168 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:36:53.103415 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:36:53.103474 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:37:12.760348 IP6 fe80::22df:b9ff:febf:c2cc > ff02::1:ff27:b8c9: ICMP6, neighbor solicitation, who has fe80::7c5f:44ff:fe27:b8c9, length 32
16:37:28.992229 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:37:28.996773 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:37:34.056882 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:37:34.056937 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:38:09.952404 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:38:09.954628 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:38:15.012460 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:38:15.012517 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:38:50.912388 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:38:50.914451 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:38:55.968585 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:38:55.968641 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:39:20.952241 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:39:21.055125 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:39:21.259512 IP6 :: > ff02::1:ff9d:7b09: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09, length 24
16:39:21.259897 IP6 :: > ff02::1:ff42:bc2: ICMP6, neighbor solicitation, who has fe80::aa8d:3346:f942:bc2, length 24
16:39:21.259956 IP6 :: > ff02::1:ff56:77f0: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0, length 24
16:39:21.260372 IP6 :: > ff02::1:ff00:ca2: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08::ca2, length 24
16:39:22.283554 IP6 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0, length 32
16:39:22.283697 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::aa8d:3346:f942:bc2, length 32
16:39:22.284286 IP6 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09, length 32
16:39:22.284349 IP6 2a01:cb01:1055:bc08::ca2 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08::ca2, length 32
16:39:31.872418 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:39:31.877383 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:39:36.925555 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:39:36.925608 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:39:56.074241 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:39:56.074547 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:39:56.176810 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:40:11.435138 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:40:11.436538 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:40:11.844901 IP6 :: > ff02::1:ff42:bc2: ICMP6, neighbor solicitation, who has fe80::aa8d:3346:f942:bc2, length 24
16:40:11.844901 IP6 :: > ff02::1:ff9d:7b09: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09, length 24
16:40:11.845123 IP6 :: > ff02::1:ff56:77f0: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0, length 24
16:40:11.845370 IP6 :: > ff02::1:ff00:ca2: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08::ca2, length 24
16:40:11.845757 IP6 fe80::aa8d:3346:f942:bc2 > ff02::2: ICMP6, router solicitation, length 8
16:40:12.766243 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::aa8d:3346:f942:bc2, length 32
16:40:12.766414 IP6 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09, length 32
16:40:12.766795 IP6 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0, length 32
16:40:12.832244 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:40:12.868586 IP6 2a01:cb01:1055:bc08::ca2 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08::ca2, length 32
16:40:12.868884 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:40:17.886631 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:40:17.886693 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:40:48.299576 IP6 fe80::aafb:40ff:fed2:3c4f > ff02::1: ICMP6, router advertisement, length 96
16:40:53.792383 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:40:53.794318 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:40:58.233031 IP6 fe80::22df:b9ff:febf:c2cc > ff02::1:ff27:b8c9: ICMP6, neighbor solicitation, who has fe80::7c5f:44ff:fe27:b8c9, length 32
16:40:58.847185 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:40:58.847253 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:41:36.903398 IP6 :: > ff02::1:ff27:b8c9: ICMP6, neighbor solicitation, who has fe80::7c5f:44ff:fe27:b8c9, length 32
16:41:37.909287 IP6 fe80::7c5f:44ff:fe27:b8c9 > ff02::2: ICMP6, router solicitation, length 16
16:41:37.916103 IP6 :: > ff02::1:ff27:b8c9: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:7c5f:44ff:fe27:b8c9, length 32
16:41:37.916294 IP6 :: > ff02::1:ff9c:955e: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:d14c:17c2:9f9c:955e, length 32
16:41:37.928771 IP6 fe80::7c5f:44ff:fe27:b8c9 > ff02::2: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:7c5f:44ff:fe27:b8c9, length 32
16:41:37.931649 IP6 fe80::7c5f:44ff:fe27:b8c9 > ff02::2: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:d14c:17c2:9f9c:955e, length 32
16:41:37.931866 IP6 2a01:cb01:1055:bc08:7c5f:44ff:fe27:b8c9 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:41:37.935176 IP6 2a01:cb01:1055:bc08:d14c:17c2:9f9c:955e > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:41:39.872414 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:41:39.900710 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:41:42.312452 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:41:44.996679 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:41:44.996747 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:42:28.000325 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:42:28.002654 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:43:17.152444 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:43:17.157687 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:43:22.204343 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:43:22.204398 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:43:50.156504 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1:ffd2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:43:51.284777 IP6 fe80::aa8d:3346:f942:bc2 > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::aa8d:3346:f942:bc2, length 32
16:43:51.284864 IP6 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:9d32:6d3b:b656:77f0, length 32
16:43:51.285231 IP6 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08:aa15:75f9:e59d:7b09, length 32
16:43:51.285461 IP6 2a01:cb01:1055:bc08::ca2 > ff02::1: ICMP6, neighbor advertisement, tgt is 2a01:cb01:1055:bc08::ca2, length 32
16:44:06.304455 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:44:06.306032 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:44:48.011916 IP6 :: > ff02::1:ffb7:b6b7: ICMP6, neighbor solicitation, who has fe80::cc0a:25df:2db7:b6b7, length 32
16:44:49.138317 IP6 fe80::cc0a:25df:2db7:b6b7 > ff02::2: ICMP6, router solicitation, length 8
16:44:49.650258 IP6 :: > ff02::1:ff00:b6c: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08::b6c, length 32
16:44:49.650636 IP6 :: > ff02::1:ff6a:715c: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:7823:8e24:bf6a:715c, length 32
16:44:49.957403 IP6 :: > ff02::1:ff41:acf4: ICMP6, neighbor solicitation, who has 2a01:cb01:1055:bc08:3e69:bdb0:7441:acf4, length 32
16:44:55.456410 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:44:55.461606 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:45:00.504311 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor solicitation, who has fe80::53f7:fcb1:63e2:f834, length 32
16:45:00.504368 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::53f7:fcb1:63e2:f834, length 24
16:45:44.608432 IP6 fe80::53f7:fcb1:63e2:f834 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
16:45:44.610466 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::53f7:fcb1:63e2:f834: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
16:46:03.374869 IP6 fe80::aafb:40ff:fed2:3c4f > ff02::1: ICMP6, router advertisement, length 96
Pour info, j'ai réactivé DHCPv6 sur la box (c'est la configuration par défault)
-
Vivien ping depuis le LAN de la flybox vers une de mes machines. Voici ce que je vois de mon côté, sur la machine en question :
16:27:57.706485 IP6 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e > 2a01:cb08:xxxx:xxxx:8820:12a:74d0:79b: ICMP6, echo request, id 2, seq 112, length 64
16:27:57.706535 IP6 2a01:cb08:xxxx:xxxx:8820:12a:74d0:79b > 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e: ICMP6, echo reply, id 2, seq 112, length 64
16:27:57.736727 IP6 2a01:cb01:1055:bc08:0:47:315f:bb01 > 2a01:cb08:xxxx:xxxx:8820:12a:74d0:79b: ICMP6, destination unreachable, unreachable route 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e, length 112
- ta FlyBox pense ne pas avoir de *route* vers le préfixe qui lui est délégué (2a01:cb01:1055:bc08::/64).
Comme le téléphone sous Android 16 a fonctionné, ça suggère peut-être qu'au lieu d'une route en /64, il y aurait des routes en /128 ajoutées pour chaque client (ce qui ne fonctionnerait pas bien).
Mais sur la capture du premier message, on voit bien les Neighbor Advertisement du PC avec ses GUA, y compris deux réponses sur solicitation de la Flybox pour l'IP dynamique.
-
En effet, la flybox semble ne jamais tenter de résoudre les adresses GUA des stations (dans 2a01:cb01:1055:bc08::/64), que ce soit depuis fe80::aafb:40ff:fed2:3c4f ou 2a01:cb01:1055:bc08:0:47:315f:bb01.
Est-ce que tu peux pinger 2a01:cb01:1055:bc08:0:47:315f:bb01, d'ailleurs ?
Tu peux stopper le ping vers chez moi.
De mon point de vue, c'est un bug firmware FlyBox : elle perd la route vers le /64 qui lui est délégué, route qui doit normalement pointer vers son LAN (si je devais parier, je dirai que cette interface est un bridge software puisqu'elle fait wifi + ethernet et que les deux sont bridgés).
Est-ce que tu peux voir les entrées de sa table de routage dans l'interface web ? J'en doute, mais on ne sait jamais. Tu n'as pas d'accès shell ?
-
Comme le téléphone sous Android 16 a fonctionné, ça suggère peut-être qu'au lieu d'une route en /64, il y aurait des routes en /128 ajoutées pour chaque client (ce qui ne fonctionnerait pas bien).
Franchement, si c'est comme cela que c'est implémenté (demon userspace qui ajoute une route /128 pour chaque nouveau client qu'il voit), je ne suis pas méga étonné que ca ne marche pas bien :-)
-
En effet, la flybox semble ne jamais tenter de résoudre les adresses GUA des stations (dans 2a01:cb01:1055:bc08::/64), que ce soit depuis fe80::aafb:40ff:fed2:3c4f ou 2a01:cb01:1055:bc08:0:47:315f:bb01.
Dans la capture du premier message, c'était pourtant le cas.
-
Est-ce que tu peux pinger 2a01:cb01:1055:bc08:0:47:315f:bb01, d'ailleurs ?
$ ping 2a01:cb01:1055:bc08:0:47:315f:bb01
PING 2a01:cb01:1055:bc08:0:47:315f:bb01 (2a01:cb01:1055:bc08:0:47:315f:bb01) 56 data bytes
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=2 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=3 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=4 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=5 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=6 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=7 Destination unreachable: Address unreachable
ping: sendmsg: Aucun chemin d'accès pour atteindre l'hôte cible
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=8 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=9 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=11 Destination unreachable: Address unreachable
ping: sendmsg: Aucun chemin d'accès pour atteindre l'hôte cible
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=12 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=13 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=15 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=16 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=17 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=18 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=19 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=20 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=21 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=22 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=23 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=24 Destination unreachable: Address unreachable
ping: sendmsg: Aucun chemin d'accès pour atteindre l'hôte cible
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=25 Destination unreachable: Address unreachable
From 2a01:cb01:1055:bc08:90d0:9184:e9dd:b69e icmp_seq=26 Destination unreachable: Address unreachable
^C
--- 2a01:cb01:1055:bc08:0:47:315f:bb01 ping statistics ---
29 packets transmitted, 0 received, +24 errors, 100% packet loss, time 28658ms
-
OK. Et 2a01:cb01:1055:bc08::1 ? C'est ce que je vois sur la première capture.
Dans la capture du premier message, c'était pourtant le cas.
En effet... table qui overflow ou démon qui crash, probablement.
-
As-tu moyen de mettre à jour le firmware de la flybox ? Si tu es déjà au dernier, il va falloir faire remonter le problème à Orange probablement. Et là, je me demande bien comment trouver un interlocuteur...
-
OK. Et 2a01:cb01:1055:bc08::1 ? C'est ce que je vois sur la première capture.
$ ping 2a01:cb01:1055:bc08::1
PING 2a01:cb01:1055:bc08::1 (2a01:cb01:1055:bc08::1) 56 data bytes
^C
--- 2a01:cb01:1055:bc08::1 ping statistics ---
120 packets transmitted, 0 received, 100% packet loss, time 121842ms
Pour le firmware, il est mis à jour automatiquement. Voici ce que j'ai :
(https://lafibre.info/images/ipv6/202507_flyxbox_version_firmware.webp)
Il y a un an, voici le firmware : Le bug de perte d'IPv6 n'était présent à l'époque.
(https://lafibre.info/images/5g/202407_orange_flybox2-5g_5g19-01w-a_interface.webp)
-
$ ping 2a01:cb01:1055:bc08::1
PING 2a01:cb01:1055:bc08::1 (2a01:cb01:1055:bc08::1) 56 data bytes
^C
--- 2a01:cb01:1055:bc08::1 ping statistics ---
120 packets transmitted, 0 received, 100% packet loss, time 121842ms
OK, donc oui, ca confirme le bug : pas d'erreur, la resolution NDP doit bien se faire pour 2a01:cb01:1055:bc08::1 mais les réponses ne sont pas routées vers ta machine.
Pour le firmware, il est mis à jour automatiquement.
OK, donc sans avoir un bon contact chez Orange qui bosse la dessus, j'imagine que la solution est un reboot régulier (automatique?) de la box...
-
Si tu as envie de faire plus de tests... as-tu moyen d'ajouter une route vers l'interface LAN pour 2a01:cb01:1055:bc08::/64 dans Routes Statiques ?
-
Si tu as envie de faire plus de tests... as-tu moyen d'ajouter une route vers l'interface LAN pour 2a01:cb01:1055:bc08::/64 dans Routes Statiques ?
Pour IPv6, l'interface ne propose qu'activer / désactiver DHCPv6.
Le reste de l'interface se limite à de l'IPv4. L'IPv6 est absent (ou défaillant pour Réseau / Appareils Connectés)
(https://lafibre.info/images/ipv6/202507_flyxbox_routes_statiques.webp)
-
Petite précision, le problème de perte d'IPv6 ne semble survenir qu'après un redémarrage. Je suis monté à des uptime de plus d'un mois sans rencontrer de perte d'IPv6.
À chaque fois que je vois que je n'ai plus d'IPv6, j'ai redémarré la box quelques heures avant (par exemple pour aller tester ma box chez un voisin avant de souscrire à l'offre)
La box permet de déconnecter le WAN et de le reconnecter, mais cela ne résout pas le problème.
Voici ce que cela donne avec de l'IPv6, aprés un reboot :
IPv6 utilisé par mon PC : 2a01:cb09:b065:6fa7:1b44:f248:5e60:48d4
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb09:b065:6fa7::fd4/128 scope global dynamic noprefixroute
valid_lft 70310sec preferred_lft 27110sec
inet6 2a01:cb09:b065:6fa7:1b44:f248:5e60:48d4/64 scope global temporary dynamic
valid_lft 86027sec preferred_lft 42827sec
inet6 2a01:cb09:b065:6fa7:fd0c:6605:aa9b:4d59/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86027sec preferred_lft 42827sec
inet6 fe80::53f7:fcb1:63e2:f834/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Les routes :
$ ip -6 route show
2a01:cb09:b065:6fa7::fd4 dev wlp2s0 proto kernel metric 600 pref medium
2a01:cb09:b065:6fa7::/64 dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 1024 pref medium
default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 600 pref medium
Ping vers mon préfixe::0 et mon préfixe::1
$ ping 2a01:cb09:b065:6fa7::0
PING 2a01:cb09:b065:6fa7::0 (2a01:cb09:b065:6fa7:: ) 56 data bytes
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=1 ttl=64 time=852 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=2 ttl=64 time=1.64 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=3 ttl=64 time=1.52 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=4 ttl=64 time=1.80 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=5 ttl=64 time=1.35 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=6 ttl=64 time=1.78 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=7 ttl=64 time=5.34 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=8 ttl=64 time=1.42 ms
^C
--- 2a01:cb09:b065:6fa7::0 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7010ms
rtt min/avg/max/mdev = 1.348/108.337/851.863/281.028 ms
$ ping 2a01:cb09:b065:6fa7::1
PING 2a01:cb09:b065:6fa7::1 (2a01:cb09:b065:6fa7::1) 56 data bytes
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=1 ttl=64 time=4.78 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=2 ttl=64 time=1.98 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=3 ttl=64 time=1.94 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=4 ttl=64 time=1.38 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=5 ttl=64 time=4.96 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=6 ttl=64 time=1.56 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=7 ttl=64 time=1.44 ms
64 bytes from 2a01:cb09:b065:6fa7::1: icmp_seq=8 ttl=64 time=1.79 ms
^C
--- 2a01:cb09:b065:6fa7::1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7008ms
rtt min/avg/max/mdev = 1.380/2.479/4.958/1.396 ms
-
OK, donc plutôt qu'un bug qui se manifeste au cours du temps (overflow ou quelque chose comme cela), c'est plutôt un bug lors de l'initialisation (probablement race condition).
Moins embêtant à l'usage je suppose, mais quand même pas terrible.
-
Update intéressant : Lors d'une nouvelle perte d'IPv6, je me suis aperçus que l'IPv6 fonctionnait parfaitement sur mon Pixel 6 (Android 16) connecté en Wi-Fi à ma Flybox 5G.
La plage IPv6 de mon pixel 6 est bien du même /64 (2a01:cb09:b02c:69cf:: ) qui ne fonctionne pas depuis mon PC également connecté en Wi-Fi (testé sous Ubuntu 25.04 et Windows 11).
J'ai pensé à un pb de MTU, mais même un petit ping ICMP ne passe pas.
Depuis Ubuntu 25.04 :
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb09:b02c:69cf::b6c/128 scope global dynamic noprefixroute
valid_lft 86139sec preferred_lft 42939sec
inet6 2a01:cb09:b02c:69cf:7a00:9732:4557:6508/64 scope global temporary dynamic
valid_lft 86399sec preferred_lft 43199sec
inet6 2a01:cb09:b02c:69cf:e4e4:a7e0:290c:8a14/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86399sec preferred_lft 43199sec
inet6 fe80::e8ea:f4a7:1d85:502/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$ ip -6 route show
2a01:cb09:b02c:69cf::b6c dev wlp2s0 proto kernel metric 600 pref medium
2a01:cb09:b02c:69cf::/64 dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 1024 pref medium
default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 20600 pref medium
$ ping lafibre.info
PING lafibre.info (2a0b:cbc0:10:1af1:b2e::1f0) 56 data bytes
^C
--- lafibre.info ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12273ms
$ ping ip.lafibre.info
PING ip.lafibre.info (2001:bc8:1600:4:63f:72ff:feaf:a2de) 56 data bytes
^C
--- ip.lafibre.info ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12269ms
$ ping 2a01:cb09:b02c:69cf::0
PING 2a01:cb09:b02c:69cf::0 (2a01:cb09:b02c:69cf::) 56 data bytes
^C
--- 2a01:cb09:b02c:69cf::0 ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18435ms
$ ping 2a01:cb09:b02c:69cf::1
PING 2a01:cb09:b02c:69cf::1 (2a01:cb09:b02c:69cf::1) 56 data bytes
^C
--- 2a01:cb09:b02c:69cf::1 ping statistics ---
23 packets transmitted, 0 received, 100% packet loss, time 22540ms
Depuis Windows 11 :
C:\Users\vivie>ping 2a01:cb09:b02c:69cf::0
Envoi d’une requête 'Ping' 2a01:cb09:b02c:69cf:: avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 2a01:cb09:b02c:69cf:::
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\vivie>ping 2a01:cb09:b02c:69cf::1
Envoi d’une requête 'Ping' 2a01:cb09:b02c:69cf::1 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 2a01:cb09:b02c:69cf::1:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
Depuis Android 16 :
(https://lafibre.info/images/ipv6/202508_android16_box5g_ipv6_hs_1.webp)
J'ai tenté un passage en mode avion : je récupère une nouvelle IPv6 sur le bon /64
(https://lafibre.info/images/ipv6/202508_android16_box5g_ipv6_hs_2.webp)
L'IPv6 est fonctionnel :
(https://lafibre.info/images/ipv6/202508_android16_box5g_ipv6_hs_3.webp)
-
Android permet de faire un partage de connexion 5G, mais aussi Wi-Fi (pratique quand il faut payer le Wi-Fi équipement par équipement).
Partage du Wi-Fi de ma Flybox 5G : Pas d'IPv6 (alors que sur le mobile j'ai de l'IPv6)
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::11d9:d524:5635:e98/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$ ip -4 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
altname wlx58cdc949fddb
inet 10.120.20.15/24 brd 10.120.20.255 scope global dynamic noprefixroute wlp2s0
valid_lft 3559sec preferred_lft 3559sec
Partage du réseau Free 5G : l'IPv6 est partagée
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a0d:e487:218f:250a:b39c:d50:120a:43f4/64 scope global temporary dynamic
valid_lft 7165sec preferred_lft 7165sec
inet6 2a0d:e487:218f:250a:1c85:820:e4c0:b1de/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7165sec preferred_lft 7165sec
inet6 fe80::11d9:d524:5635:e98/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$ ip -4 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
altname wlx58cdc949fddb
inet 10.120.20.15/24 brd 10.120.20.255 scope global dynamic noprefixroute wlp2s0
valid_lft 3464sec preferred_lft 3464sec
-
Bonjour,
ce qui m'interroge :
normalement pour "fournir de l'ipv6" sur un réseau, un appareil doit obtenir, en plus d'une adresse ipv6, un "scope", càd une forme de sous réseau qui lui est attribué (de ce que j'en ai compris)
Il faut notamment que l'appareil qui retransmette l'ipv6 sur le réseau, puisse avoir un "champ" dans lequel fournir l'adresse ipv6 du prochain appareil qui réattribuera pour un plus petit réseau, etc etc
ce pourquoi, certains vpn qui proposent ipv4/6, se contentent de fournir une ipv6 "en bout de ligne", pour l'appareil de l'utilisateur, sans proposer dans l'interface client, un applet pour y paramétrer la "prochaine adresse" qui fournira pour un nouveau sous réseau : particulièrement utile quand le client VPN est un..... routeur, notamment openwrt.
Y'a eu des remontées sur reddit chez certains fournisseurs vpn, qui empechaient donc, certains clients, de déployer l'ipv6 fourni par leur vpn, sur l'ensemble des appareils connectés à l'openwrt client chez le prestataire vpn.
Ce qui m'interroge : android saurait gérer ça de lui meme? si je comprends bien, l'abonné mobile recoit une @ipv6, sur son appareil, et en complément, une adresse pour gérer l'ipv6 comme routeur 5G pour un sous réseau, en partage de co' derrière?
-
Les opérateurs mobiles (je ne sais pour les VPN) n'attribuent pas UNE IPv6, mais une plage IPv6 /64. Ce qui permet de mettre tous les équipements que l'on souhaite derrière.
Dans mon cas, Windows comme Linux récupèrent bien une IPv6, mais elle ne fonctionne pas dans le sens descendant.
Exemple : Sous Windows 11, Windows update tente en permanence la mise à jour en IPv6 et il ne bascule pas en IPv4 (comme c'est le cas dans un navigateur web)
(https://lafibre.info/images/ipv6/202508_windows11_mise_a_jour_impossible_si_ipv6_hs.webp)
Sous Ubuntu, l'IPv6 est bien visible sur l'interface :
(https://lafibre.info/images/ipv6/202508_ubuntu_box5g_ipv6_hs_1.webp)
Dans un navigateur, https://test-ipv6.com/ affiche 0/10 :
(https://lafibre.info/images/ipv6/202508_ubuntu_box5g_ipv6_hs_2.webp)
Quand je capture le trafic sur un serveur, je vois bien les ping envoyés :
(https://lafibre.info/images/ipv6/202508_ubuntu_box5g_ipv6_hs_3.webp)
-
J'ai vraiment du mal à comprendre pourquoi quand l'IPv6 ne fonctionne pas avec ma box 5G, il fonctionne avec mon Android 16 (Pixel 6) et pas sur mes nombreux PC testés.
J'ai testé des PC récents en Ethernet, en Wi-Fi, des PC anciens en Ethernet, en Wi-Fi, pas d'IPv6 fonctionnels.
J'ai testé 4 OS : Windows 10, Windows 11, Ubuntu 24.04, Ubuntu 25.04, même comportement.
Test d'un vieux serveur Dell PowerEdge 2950, le truc qui a presque 20 ans : pas d'IPv6 fonctionnel :
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_1.webp)
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_2.webp)
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_3.webp)
-
Android 16, connectivité 5G désactivé : IPv6 e Wi-Fi fonctionnel :
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_7.webp)
Test d'un PC portable récent, connecté en Wi-Fi 6 : pas d'IPv6 fonctionnel : pas d'IPv6 fonctionnel :
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_4.webp)
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_5.webp)
(https://lafibre.info/images/ipv6/202509_ubuntu_box5g_ipv6_hs_6.webp)
-
Le problème IPv6 est toujours présent avec la Flybox 5G.
Je remarque qu'il n’apparaît pas au démarrage de la box, mais plus tard. Quand j'allume la box IPv6 est ok, le lendemain, je n'ai plus que IPv4.
Cette fois-ci, même sur Android je n'ai plus d'IPv6.
Sur mon PC :
$ ip -6 -c addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb09:804b:abb8::fd4/128 scope global dynamic noprefixroute
valid_lft 83861sec preferred_lft 40661sec
inet6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352/64 scope global temporary dynamic
valid_lft 85976sec preferred_lft 42776sec
inet6 2a01:cb09:804b:abb8:7546:7ebf:fdba:50f3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 85976sec preferred_lft 42776sec
inet6 fe80::9c99:ca8b:b01c:b524/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$ ip -6 route show
2a01:cb09:804b:abb8::fd4 dev wlp2s0 proto kernel metric 600 pref medium
2a01:cb09:804b:abb8::/64 dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 1024 pref medium
default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 20600 pref medium
$ ping lafibre.info
PING lafibre.info (2a0b:cbc0:10:1af1:b2e::1f0) 56 data bytes
^C
--- lafibre.info ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18430ms
$ sudo tcpdump -pns0 -i wlp2s0 icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:05:22.085811 IP6 fe80::aafb:40ff:fed2:3c4f > ff02::1: ICMP6, router advertisement, length 96
10:05:43.257654 IP6 fe80::9c99:ca8b:b01c:b524 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor solicitation, who has fe80::aafb:40ff:fed2:3c4f, length 32
10:05:43.264379 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::9c99:ca8b:b01c:b524: ICMP6, neighbor advertisement, tgt is fe80::aafb:40ff:fed2:3c4f, length 24
10:05:48.300648 IP6 fe80::aafb:40ff:fed2:3c4f > fe80::9c99:ca8b:b01c:b524: ICMP6, neighbor solicitation, who has fe80::9c99:ca8b:b01c:b524, length 32
10:05:48.300706 IP6 fe80::9c99:ca8b:b01c:b524 > fe80::aafb:40ff:fed2:3c4f: ICMP6, neighbor advertisement, tgt is fe80::9c99:ca8b:b01c:b524, length 24
10:05:49.211855 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 1, length 64
10:05:50.233795 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 2, length 64
10:05:51.257783 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 3, length 64
10:05:52.281770 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 4, length 64
10:05:53.305780 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 5, length 64
10:05:54.330690 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 6, length 64
10:05:55.353799 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 7, length 64
10:05:56.377766 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 8, length 64
10:05:57.401771 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 9, length 64
10:05:58.425827 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 10, length 64
10:05:59.450754 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 11, length 64
10:06:00.473705 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 12, length 64
10:06:01.497787 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 13, length 64
10:06:02.521796 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 14, length 64
10:06:03.545752 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 15, length 64
10:06:04.569764 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 16, length 64
10:06:05.593960 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 17, length 64
10:06:06.617792 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 18, length 64
10:06:07.641779 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, id 3, seq 19, length 64
^C
24 packets captured
69 packets received by filter
0 packets dropped by kernel
Capture fait simultanément coté serveur : On voit bien les paquets arriver et repartir.
$ sudo tcpdump -pns0 -i bond0 icmp6 | grep 2a01:cb09:804b:abb8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:05:49.217876 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 1, length 64
10:05:49.217901 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 1, length 64
10:05:50.237876 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 2, length 64
10:05:50.237902 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 2, length 64
10:05:51.257790 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 3, length 64
10:05:51.257831 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 3, length 64
10:05:52.277670 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 4, length 64
10:05:52.277696 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 4, length 64
10:05:53.318308 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 5, length 64
10:05:53.318352 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 5, length 64
10:05:54.337921 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 6, length 64
10:05:54.337953 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 6, length 64
10:05:55.358222 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 7, length 64
10:05:55.358262 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 7, length 64
10:05:56.377619 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 8, length 64
10:05:56.377649 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 8, length 64
10:05:57.397787 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 9, length 64
10:05:57.397812 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 9, length 64
10:05:58.438661 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 10, length 64
10:05:58.438693 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 10, length 64
10:05:59.457794 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 11, length 64
10:05:59.457815 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 11, length 64
10:06:00.483329 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 12, length 64
10:06:00.483350 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 12, length 64
10:06:01.497803 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 13, length 64
10:06:01.497833 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 13, length 64
10:06:02.519319 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 14, length 64
10:06:02.519355 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 14, length 64
10:06:03.558186 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 15, length 64
10:06:03.558228 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 15, length 64
10:06:04.578015 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 16, length 64
10:06:04.578040 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 16, length 64
10:06:05.597830 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 17, length 64
10:06:05.597866 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 17, length 64
10:06:06.618004 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 18, length 64
10:06:06.618045 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 18, length 64
10:06:07.657685 IP6 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352 > 2a0b:cbc0:10:1af1:b2e::1f0: ICMP6, echo request, seq 19, length 64
10:06:07.657730 IP6 2a0b:cbc0:10:1af1:b2e::1f0 > 2a01:cb09:804b:abb8:f09d:660e:d9ff:9352: ICMP6, echo reply, seq 19, length 64
^C
1801 packets captured
1818 packets received by filter
0 packets dropped by kernel
-
As tu essayé de ne connecter qu'un seul appareil jusqu'au moment du bug (même si c'est compliqué) ?
Si tu peux bidouiller un truc avec ton dell poweredge, mets un openwrt au cul de la box via une VM et connecte tes périphériques derrière. Pour l'ipv6 y'a l'option extendprefix qui s'occupe de tout.
-
En désactivant la partie routeur de la box ?
Cela ne me semble pas possible à désactiver.
Par contre, j'ai bien avancé sur ce bug : On perd l'IPv6 quand on connecte certains équipements sur le port Ethernet de la box.
C'est reproductible : quand je branche mon PC en Ethernet (il y a un seul port Ethernet), les équipements Wi-Fi perdent l'IPv6.
Si je débranche mon PC, mes équipements en Wi-Fi ne récupèrent pas l'IPv6.
Le bug n’entraîne pas que la perte d'IPv6 : la fonction "Redémarrer l'appareil" dans l'interface ne fonctionne plus. J'ai beau cliquer sur le bouton, c'est sans effet. Il faut que je me déplace éteindre la box pour retrouver IPv6.
Il faut que je teste avec plusieurs PC pour chercher quels sont les PC qui font perdre IPv6.
-
Si je débranche mon PC, mes équipements en Wi-Fi ne récupèrent pas l'IPv6.
OK ton PC peut annoncer une préfixe voire se prendre pour un routeur et coupe les devices parce que ça route plus en vrai.
Capture fait simultanément coté serveur : On voit bien les paquets arriver et repartir.
alors ça c'est une route qui existe dans un sens, mais pas dans l'autre. QQpart la route retour n'est pas totale. Ou un firewall avant qui bouffe les réponses (parce qu'il filtre de ouf ou qu'il a pas le contexte pour accepter la réponse)
-
En fait le PC utilisé (Dell PowerEdge R320) et connecté en Ethernet à la Flybox est équipé d'Ubuntu server 25.10 en configuration par défaut. Je n'ai installé que ffmpeg suite à l'installation du système (il sert à faire des tests de compression vidéos AV1).
À noter que si je perds IPv6 sur tous les équipements Wi-Fi (y compris mon Andorid 16 contrairement à une fois), le PC en Ethernet a bien de l'IPv6 fonctionnel vers internet.
Il est aussi possible à un PC Wi-Fi de pinger en IPv6 le PC connecté en Ethernet. Seuls les ping venant de l'internet et à destination du Wi-Fi sont bloqués.
Je continue à investiguer pour trouver ce qui pose un problème.
-
En désactivant la partie routeur de la box ?
Cela ne me semble pas possible à désactiver.
Sans désactiver évidemment.
Et si c'est bien une histoire d’Ethernet qui fait buger le wifi, un simple switch + un AP et c'est réglé ?
-
Seuls les ping venant de l'internet et à destination du Wi-Fi sont bloqués.
une firewall qui bloque les ICMPv6 Echo Reply entrant sur la flybox ou le pc ?
-
Ça me fait penser à un problème similaire chez Bouygues : selon le préfixe que je récupère, l'ICMP est bloqué. Je n'ai pas vérifié si les pings arrivaient de l'autre côté par contre, j’essaierais d'y penser la prochaine fois.
Faut que je revérifie si c'est que l'IPv4 ou IPv6 aussi par contre, mais je crois bien que c'est les deux. Je suis obligé de me rabattre en http pour vérifier la connexion notamment pour le 464XLAT.
La piste d'un firewall bugé (sur la box) pourrait coller.
-
après si c'est que du ping entre c'est pas grave.
Le truc qui m'inquiète plus c'est qu'il branche son PC les autres devices n'ont plus d'IPv6
-
Perte de la connectivité IPv6 : C'est un bug SLAAC (Stateless Address Autoconfiguration) de la box Nokia qui envoie les paquets IPv6 au mauvais terminal
J'ai avancé sur ce problème de perte d'IPv6 : le trafic IPv6 de toute la box va être envoyé à un même équipement (généralement un mobile Android).
Exemple : Une flybox connectée à 5 terminaux. Le terminal qui aspire tout le trafic est le terminal 2.
Les paquets émis par le terminal 1 vont aller sur internet. La réponse provenant d'internet ne va pas revenir au terminal 1, mais au terminal 2 qui va mettre à la poubelle ces paquets qu'il n'a pas demandés.
Conséquence : les terminaux 1, 3, 4 et 5 vont récupérer une IPv6 qui ne fonctionne pas.
Comme Orange a mis un DNS64, un nom de domaine IPv4 sera annoncé en IPv6 : même le trafic IPv4 souhaite partir via une IPv6 qui ne fonctionne pas. Cela ne bloque pas tout l'accès à internet, car les navigateurs web et certaines applications qui intègrent un "fall back" vers IPv4. Quand le fall back est présent sur l'application, le trafic va partir en IPv4 (la box va l'encapsuler dans une IPv6, mais l'essentiel, c'est cela fonctionne). Quand l'application n'intègre pas de fallback, l'application ne fonctionne pas.
Jusqu'à présent, j'avais du mal à reproduire le problème : je redémarrais ma flybox et je récupérais IPv6. Mon smartphone, un Pixel 6 sous Android 16, ne déclenchant pas systématiquement le bug.
J'ai trouvé un système d'exploitation qui permet de reproduire systématiquement le bug : Ubuntu server 25.10.
- Ubuntu avec interface graphique ⇒ Le moteur par défaut est NetworkManager : Il ne déclenche jamais le bug de la flybox Nokia.
- Ubuntu sans interface graphique ⇒ Le moteur par défaut est systemd-networkd : La perte est systématique dès qu'on a "accept-ra: true" dans la configuration Netplan (RA pour Router Advertisements, c'est l'auto-configuration SLAAC).
J'ai essayé plusieurs PC, 100% de réussite avec systemd-networkd et SLAAC ! Cela fonctionne aussi bien en Ethernet qu'en Wi-Fi (oui, on peut connecter Ubuntu server au Wi-Fi, tutoriel : Configuration du Wi-Fi avec Netplan (PC sans interface graphique) (https://lafibre.info/ubuntu/configuraiton-du-wi-fi-avec-netplan/).
Tout le contenu du tutoriel est réalisé avec le PC qui m'a servi pour réaliser les captures ci-dessous.
Les captures ci-dessous commencent par une capture du trafic avec accept-ra: false
Exemple de configuration utilisée pour une connexion Wi-Fi : (IPv6 est désactivé)
network:
version: 2
renderer: networkd
ethernets: {}
wifis:
wlp16s0:
dhcp4: true
dhcp6: false
accept-ra: false
access-points:
"Flybox-3C4F":
password: "Y7tEEFsQUkkE"
La commande sudo tcpdump -i ens1 -n -s 0 -w /tmp/capture/ethernet.pcap ou sudo tcpdump -i wlp16s0 -n -s 0 -w /tmp/capture/wifi.pcap est lancée depuis une connexion SSH, ce qui fait que les premiers paquets de la capture Wireshark correspondent à cette connexion SSH.
Je laisse tourner deux minutes la capture (sans rien faire) sans connectivité IPv6, puis (localement sur le PC pour ne pas générer de trafic SSH), je modifie la configuration avec accept-ra: false changé pour accept-ra: true
Je fait un sudo netplan apply pour appliquer la nouvelle configuration qui active IPv6 SLAAC (Stateless Address Autoconfiguration).
Cela entraîne une nouvelle requête DHCP en IPv4, puis l'activation de l'IPv6 SLAAC qui va poser un problème et immédiatement les autres PC perdent IPv6. On le voit dans les captures, j'ai immédiatement du trafic qui est destiné au PC HP et à mon Pixel 6.
Je laisse tourner encore quelques minutes la capture.
On observe alors que de nombreux paquets IPv6 qui ne nous sont pas destinées arrivent sur notre PC avec l'adresse mac du PC, mais des adresses IP qui correspondent à d'autres PC connectés à la box. Ces derniers ne reçoivent plus les paquets IPv6, malgré de nombreuses relances.
Voici les informations sur le PC sous Ubuntu server, qui va aspirer les paquets IPv6 des autres terminaux. C'est un PC classique (j'ai testé également avec des serveurs Dell et IBM, mais ils n'avaient pas de Wi-Fi).
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_pc_de_test.webp)
-
Capture N°1 : PC Ubuntu server connecté en Ethernet à la flybox 5G
La capture wireshark (0,4 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_ethernet1.pcap
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet1.pcap)
Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet1_1.webp) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet1_1.webp)
Détail des IP, pour bien comprendre la capture Wireshark :
Flybox 2-5G (Model: 5G19-01W-A) Wi-Fi 6
Mac : a8:fb:40:d2:3c:4f
IPv4 : 192.168.1.1
IPv6 : 2a01:cb09:801a:2aee::/64
IPv6 : 2a01:cb09:801a:2aee:0:37:8af4:4501
PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connexion Ethernet à la flybox
Mac : 00:1f:29:94:ec:c8
IPv4 : inet 192.168.1.14/24 metric 100 brd 192.168.1.255 scope global dynamic ens1
IPv6 : inet6 2a01:cb09:801a:2aee::793/128 scope global dynamic noprefixroute
IPv6 : inet6 2a01:cb09:801a:2aee:21f:29ff:fe94:ecc8/64 scope global dynamic mngtmpaddr noprefixroute
Route : 2a01:cb09:801a:2aee::/64 dev ens1 proto ra metric 100 expires 85982sec pref medium
PC HP Pavillon (Core i7-12700) : Ubuntu desktop 22.10 connexion en Wi-Fi 5 à la flybox
Mac : 20:2b:20:a9:03:1f
IPv4 : inet 192.168.1.18/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0
IPv6 : inet6 2a01:cb09:801a:2aee:4b84:430a:1b2a:7dd7/64 scope global temporary dynamic
IPv6 : inet6 2a01:cb09:801a:2aee:d9b5:3d2a:34d:d8fb/64 scope global dynamic mngtmpaddr noprefixroute
Route : 2a01:cb09:801a:2aee::fd4 dev wlp2s0 proto kernel metric 600 pref medium
Route : 2a01:cb09:801a:2aee::/64 dev wlp2s0 proto ra metric 600 pref medium
Google Pixel 6 : Android 16 connexion en Wi-Fi 6 à la flybox
Mac : 16:00:9b:c6:be:52
IPv4 : 192.168.1.99
IPv6 : 2a01:cb09:801a:2aee:7f1:923e:6f1a:b543
Destinations testées :
free.fr 2a01:e0c:1::1 (ping utilisé depuis PC HP Pavillon)
ip.lafibre.info 2001:bc8:610:f:7ec2:55ff:fea9:6d88
Chronologie des échanges :
T= 0,00 => 1,66 : Echanges SSH en IPv4 pour lancer la capture réseau
T= 1,66 => 144,33 : Absence de trafic
T= 144,96 => 145,00 : execution de "sudo netplan apply" pour activer "accept-ra: true"
T= 146,35 => 147,34 : Procédure RA pour récupérer une connectivité IPv6
T= A partir de 148,6 : On voit des paquets IPv6 TCP et QUIC à desination du PC Ubuntu desktop ( 2a01:cb09:801a:2aee:4b84:430a:1b2a:7dd7 ) qui lui a perdu la connectivité IPv6. SI l'adresse IP de la destination est celle du PC Ubuntu desktop, l'adresse MAC de destination est celle du PC Ubuntu server.
T= A partir de 215,3 : On voit des paquets IPv6 TCP et QUIC à desination du Pixel 6 ( 2a01:cb09:801a:2aee:7f1:923e:6f1a:b543 ) qui lui a perdu la connectivité IPv6. La mac de destination ne coorrespond pas au Pixel 6.
T = 223,36 => 223,45 : Requete vers du PC Ubuntu server vers ipv4.lafibre.info en http (permet de voir l'IPv4 publique). Cela part en IPv6, cr il y a un DNS64
T = 234,02 => 234,11 : Requete vers du PC Ubuntu server vers ipv6.lafibre.info en http
T = 354,61 => 357,65 : Ping ICMPv6 vers ip.lafibre.info
T = 493,18 => 496,25 : Ping ICMPv6 du PC Ubuntu desktop vers le PC Ubuntu server
Détail de la configuration IP du PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connecté en Ethernet à la flybox :
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet1_2.webp)
-
Capture N°2 : PC Ubuntu server connecté en Ethernet à la flybox 5G
La capture wireshark (0,1 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_ethernet2.pcap
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet2.pcap)
Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet2_1.webp) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet2_1.webp)
Détail des IP, pour bien comprendre la capture Wireshark :
Flybox 2-5G (Model: 5G19-01W-A) Wi-Fi 6
Mac : a8:fb:40:d2:3c:4f
IPv4 : 192.168.1.1
IPv6 : 2a01:cb06:805a:4e19::/64
IPv6 : 2a01:cb06:805a:4e19:0:5c:a7e9:2c01
PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connexion par Ethernet à la flybox
Mac : 00:1f:29:94:ec:c8
IPv6 : 2a01:cb06:805a:4e19::793
PC HP Pavillon (Core i7-12700) : Ubuntu desktop 25.10 connexion en Wi-Fi 5 à la flybox
Mac : 20:2b:20:a9:03:1f
IPv4 : inet 192.168.1.18/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0
IPv6 : inet6 2a01:cb06:805a:4e19:35b6:58fc:aee3:c941/64 scope global temporary dynamic
IPv6 : inet6 2a01:cb06:805a:4e19:5357:106a:e70c:65ba/64 scope global dynamic mngtmpaddr noprefixroute
Route : 2a01:cb06:805a:4e19::fd4 dev wlp2s0 proto kernel metric 600 pref medium
Route : 2a01:cb06:805a:4e19::/64 dev wlp2s0 proto ra metric 600 pref medium
Destinations testées :
free.fr 2a01:e0c:1::1 (ping utilisé depuis PC HP Pavillon)
ip.lafibre.info 2001:bc8:610:f:7ec2:55ff:fea9:6d88
-
Capture N°3 : PC Ubuntu server connecté en Ethernet à la flybox 5G
La capture wireshark (0,1 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_ethernet3.pcap
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet3.pcap)
Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet3_1.webp) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_ethernet3_1.webp)
-
Capture N°4 : PC Ubuntu server connecté en Wi-Fi à la flybox 5G
La capture wireshark (2 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_wifi1.pcap
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi1.pcap)
Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi1_1.webp) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi1_1.webp)
Détail des IP, pour bien comprendre la capture Wireshark :
Flybox 2-5G (Model: 5G19-01W-A) Wi-Fi 6
Mac : a8:fb:40:d2:3c:4f
IPv4 : 192.168.1.1
IPv6 : 2a01:cb06:a055:d9b3::/64
IPv6 : 2a01:cb06:a055:d9b3:0:64:69f3:e501
PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connexion par Ethernet à la flybox
Mac : 00:1f:3c:63:a6:d6
IPv4 : inet 192.168.1.159/24 metric 600 brd 192.168.1.255 scope global dynamic wlp16s0
IPv6 : inet6 2a01:cb06:a055:d9b3::793/128 scope global dynamic noprefixroute
IPv6 : inet6 2a01:cb06:a055:d9b3:21f:3cff:fe63:a6d6/64 scope global dynamic mngtmpaddr noprefixroute
Route : 2a01:cb06:a055:d9b3::/64 dev wlp16s0 proto ra metric 600 expires 86333sec pref medium
Route : default nhid 1218230533 via fe80::aafb:40ff:fed2:3c4f dev wlp16s0 proto ra metric 600 expires 1733sec pref medium
PC HP Pavillon (Core i7-12700) : Ubuntu desktop 25.10 connexion en Wi-Fi 5 à la flybox
Mac : 20:2b:20:a9:03:1f
IPv4 : inet 192.168.1.18/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0
IPv6 : inet6 2a01:cb06:a055:d9b3:f10:aef9:1a47:b00a/64 scope global temporary dynamic
IPv6 : inet6 2a01:cb06:a055:d9b3:5e80:4484:e52:fa1d/64 scope global dynamic mngtmpaddr noprefixroute
Route : 2a01:cb06:a055:d9b3::fd4 dev wlp2s0 proto kernel metric 600 pref medium
Route : 2a01:cb06:a055:d9b3::/64 dev wlp2s0 proto ra metric 600 pref medium
Route : default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 20600 pref medium
Google Pixel 6 : Android 16 connexion en Wi-Fi 6 à la flybox
Mac : 16:00:9b:c6:be:52
IPv4 : 192.168.1.99
IPv6 : 2a01:cb06:a055:d9b3:4175:3d95:6e2:43c3
Destinations testées :
free.fr 2a01:e0c:1::1 (ping utilisé depuis PC HP)
ip.lafibre.info 2001:bc8:610:f:7ec2:55ff:fea9:6d88
-
Pour rire, voici les IP remontées par des appareils connectés remonté par la Flybox pour cette capture 4 :
Nokia ne voit des IPv6 que sur le Pixel6 : (cette liste des appareils connectés à la box 5G est bien loin de l'ergonomie de celle des box FTTH)
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi1_3.webp)
Liste des IPv6 quand on passe la souris dessus : Ce sont des IPv6 qui ne correspondent à rien de connu !
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi1_4.webp)
Détail de la configuration IP du PC Compaq6510b (Core2 Duo T8100) : Ubuntu server 25.10 connecté en Wi-Fi à la flybox :
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi1_2.webp)
-
Capture N°5 : PC Ubuntu server connecté en Wi-Fi à la flybox 5G
La capture wireshark (0,1 Mo) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202502_bug_ipv6_flybox_wifi2.pcap
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi2.pcap)
Extrait avec en vert les paquets qui entrainent le bug de la box Nokia :
(cliquer sur l'image pour zoomer)
(https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi2_1.webp) (https://lafibre.info/images/wireshark/202502_bug_ipv6_flybox_wifi2_1.webp)
-
- Ubuntu avec interface graphique ⇒ Le moteur par défaut est NetworkManager : Il ne déclenche jamais le bug de la flybox Nokia.
Mais avec l'IPv6 activée aussi ?
Avec combien d'IP, et obtenues comment ?
Je vois dans une autre capture qu'avec netplan il semble y avoir une IP DHCPv6 + une IP RA.
Peut-être qu'il ne faudrait garder que les RA (avec une IP, ou deux si les privacy extensions sont activées).
Liste des IPv6 quand on passe la souris dessus : Ce sont des IPv6 qui ne correspondent à rien de connu !
L'IP link-local est la bonne, et pour savoir si les deux autres ont un sens il faudrait une capture sur le Pixel 6 (à défaut de pouvoir la faire côté Nokia).
-
Je crois que j'ai trouvé la source du problème : la flybox attribue le préfixe en DHCPv6-PD au serveur en plus d'une IP /128 !
Donc c'est logique que le trafic soit routé sur le serveur ensuite non ?
Il suffirait donc de désactiver la demande de délégation et ça devrait être bon. Ou alors tirer parti de cet avantage et mettre un second routeur comme je l'avais proposé et recréer un LAN qui soit entièrement personnalisable (DNS, adressage ULA...) en tout cas c'est ce que je fais chez moi mais avec le NDP proxy/extendprefix d'openwrt vu que mon huawei ne propose pas de "fausse" délégation.
-
Bien vu renaud07 !
Pourtant, le DHCPv6-PD n'est pas dans les fonctionnalités proposées par la box.
Je vais voir si désactiver DHCPv6 (la seule option qui concerne IPv6 dans cette box) permet d'empêcher le bug.
-
En soi, le DHCPv6-PD n'est pas interdit (ça fonctionne avec la Livebox).
Mais si la Flybox attribue son /64 principal (ou le seul ?), c'est un problème.
-
En soi, le DHCPv6-PD n'est pas interdit (ça fonctionne avec la Livebox).
Mais si la Flybox attribue son /64 principal (ou le seul ?), c'est un problème.
Bah y a Unifi aussi qui sait "bridger" un /64 entre la wan et le lan. Le routeur répond au neighbour solicitation à la place des devices (un proxy arp like). Justement j'avais l'impression que la flybox se comportait "en bridge"
En tout cas joli debug @vivien. Faut que je matte les captures
-
Sur mobile, tout se comporte en proxy NDP : même la flybox, vu qu'elle reçoit son préfixe en SLAAC et l'étend du côté LAN. Les android aussi en partage de co.
Il y a une RFC spécifique (https://datatracker.ietf.org/doc/html/rfc7278), même si elle n'est pas officielle, c'est peut-être ce mécanisme qui est utilisé (désactivation du SLAAC côté WAN 4G après obtention du préfixe) mais ça peut aussi être une implémentation NDP plus classique.