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

vivien · « **Réponse #12 le:** **Hier** à 13:46:46 »

Citation de: jeremyp3 le Hier à 10:58:43

Citation de: vivien le Hier à 09:26:09
Mais pas la route par défault pour sortir sur internet :
$ ip -6 route show default via fe80::aafb:40ff:fed2:3c4f dev wlp2s0 proto ra metric 20600 pref medium
pour moi la route par défault est bien là

Oui, il y a une route par défaut qui est dans la plage fe80::/10, soit IPv6 Link-Local.

Une adresse Link-Local est une adresse qui ne porte que sur le lien et qui n’est jamais transféré par les routeurs. Elle sert à joindre les voisins sur un même lien.

Je m'attends à voir une autre route avec le /64 pubilc.

Exemple sur un PC connecté en Ethernet derrière une Livebox 3 FTTH :

Adresse IPv6 publique sur la plage 2a01:cb08:756:9100::/64
$ 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: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb08:756:9100:fa9d:2316:5e77:e19/64 scope global temporary dynamic
valid_lft 1763sec preferred_lft 563sec
inet6 2a01:cb08:756:9100:4ef0:1315:4ca3:19af/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 1763sec preferred_lft 563sec
inet6 fe80::6f24:fbf3:e035:ca46/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Je retrouve ma route Link-local, mais il y a une route avec le /64 public :
ip -6 route show
2a01:cb08:756:9100::/64 dev eno1 proto ra metric 100 pref medium
fe80::/64 dev eno1 proto kernel metric 1024 pref medium
default via fe80::f282:61ff:fee3:f31e dev eno1 proto ra metric 100 pref high

hwti · « **Réponse #13 le:** **Hier** à 13:57:23 »

La route /64 est là, elle est juste sur la 2ème ligne :

Code: [Sélectionner]

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 ....".

hwti · « **Réponse #14 le:** **Hier** à 14:53:03 »

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 :

Citer

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).

simon · « **Réponse #15 le:** **Hier** à 16:09:04 »

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 :

Code: [Sélectionner]

$ 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

vivien · « **Réponse #16 le:** **Hier** à 16:10:57 »

La seule option de la Flybox concernant IPv6, c'est la désactivation de DHCP v6.

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

vivien · « **Réponse #17 le:** **Hier** à 16:14:44 »

$ 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

vivien · « **Réponse #18 le:** **Hier** à 16:19:55 »

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.

simon · « **Réponse #19 le:** **Hier** à 16:22:02 »

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.

simon · « **Réponse #20 le:** **Hier** à 16:23:35 »

Citation de: vivien le Hier à 16:19:55

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".

hwti · « **Réponse #21 le:** **Hier** à 16:26:51 »

Citation de: simon le Hier à 16:09:04

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.

hwti · « **Réponse #22 le:** **Hier** à 16:32:46 »

Citation de: simon le Hier à 16:22:02

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.

simon · « **Réponse #23 le:** **Hier** à 16:34:32 »

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 :

Code: [Sélectionner]

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).