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)