Auteur Sujet: Perte de la connectivité IPv6 sur la Flybox 5G (Lu 13673 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:** 18 août 2025 à 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:** 18 août 2025 à 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 :

vivien · « **Réponse #42 le:** 15 septembre 2025 à 21:28:03 »

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 :

vivien · « **Réponse #43 le:** 15 septembre 2025 à 22:00:14 »

Android 16, connectivité 5G désactivé : IPv6 e Wi-Fi fonctionnel :

Test d'un PC portable récent, connecté en Wi-Fi 6 : pas d'IPv6 fonctionnel : pas d'IPv6 fonctionnel :

vivien · « **Réponse #44 le:** **Aujourd'hui** à 10:19:48 »

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

renaud07 · « **Réponse #45 le:** **Aujourd'hui** à 16:05:20 »

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.