Auteur Sujet: Perte de la connectivité IPv6 sur la Flybox 5G (Lu 7067 fois)

vivien · « **Réponse #36 le:** 15 juillet 2025 à 13:21:36 »

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

simon · « **Réponse #37 le:** 15 juillet 2025 à 18:49:38 »

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.

vivien · « **Réponse #38 le:** 17 août 2025 à 13:20:22 »

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 :

J'ai tenté un passage en mode avion : je récupère une nouvelle IPv6 sur le bon /64

L'IPv6 est fonctionnel :

vivien · « **Réponse #39 le:** 17 août 2025 à 15:05:41 »

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

dino · « **Réponse #40 le:** **Hier** à 18:21:34 »

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?

vivien · « **Réponse #41 le:** **Hier** à 20:39:58 »

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)

Sous Ubuntu, l'IPv6 est bien visible sur l'interface :

Dans un navigateur, https://test-ipv6.com/ affiche 0/10 :

Quand je capture le trafic sur un serveur, je vois bien les ping envoyés :