Messages récents11
5G Home Orange / Perte de la connectivité IPv6 sur la Flybox 5G
« Dernier message par vivien le Aujourd'hui à 21:49:01 »
Perte de la connectivité IPv6 : C'est un bug SLAAC (Stateless Address Autoconfiguration) de la box Nokia qui envoie les paquets IPv6 au mauvais terminal
J'ai avancé sur ce problème de perte d'IPv6 : le trafic IPv6 de toute la box va être envoyé à un même équipement (généralement un mobile Android).
Exemple : Une flybox connectée à 5 terminaux. Le terminal qui aspire tout le trafic est le terminal 2.
Les paquets émis par le terminal 1 vont aller sur internet. La réponse provenant d'internet ne va pas revenir au terminal 1, mais au terminal 2 qui va mettre à la poubelle ces paquets qu'il n'a pas demandés.
Conséquence : les terminaux 1, 3, 4 et 5 vont récupérer une IPv6 qui ne fonctionne pas.
Comme Orange a mis un DNS64, un nom de domaine IPv4 sera annoncé en IPv6 : même le trafic IPv4 souhaite partir via une IPv6 qui ne fonctionne pas. Cela ne bloque pas tout l'accès à internet, car les navigateurs web et certaines applications qui intègrent un "fall back" vers IPv4. Quand le fall back est présent sur l'application, le trafic va partir en IPv4 (la box va l'encapsuler dans une IPv6, mais l'essentiel, c'est cela fonctionne). Quand l'application n'intègre pas de fallback, l'application ne fonctionne pas.
Jusqu'à présent, j'avais du mal à reproduire le problème : je redémarrais ma flybox et je récupérais IPv6. Mon smartphone, un Pixel 6 sous Android 16, ne déclenchant pas systématiquement le bug.
J'ai trouvé un terminal qui permet de reproduire systématiquement le bug : Ubuntu server 25.10.
- Ubuntu avec interface graphique ⇒ Le moteur par défaut est NetworkManager : Il ne déclenche jamais le bug de la flybox Nokia.
- Ubuntu sans interface graphique ⇒ Le moteur par défaut est systemd-networkd : La perte est systématique dès qu'on a "accept-ra: true" dans la configuration Netplan (RA pour Router Advertisements, c'est l'auto-configuration SLAAC).
J'ai essayé plusieurs PC, 100% de réussite avec systemd-networkd et SLAAC ! Cela fonctionne aussi bien en Ethernet qu'en Wi-Fi (oui, on peut connecter Ubuntu server au Wi-Fi, tutoriel : Configuration du Wi-Fi avec Netplan (PC sans interface graphique).
Tout le contenu du tutoriel est réalisé avec le PC qui m'a servi pour réaliser les captures ci-dessous.
Les captures ci-dessous commencent par une capture du trafic avec accept-ra: false
Exemple de configuration utilisée pour une connexion Wi-Fi : (IPv6 est désactivé)
La commande sudo tcpdump -i ens1 -n -s 0 -w /tmp/capture/ethernet.pcap ou sudo tcpdump -i wlp16s0 -n -s 0 -w /tmp/capture/wifi.pcap est lancée depuis une connexion SSH, ce qui fait que les premiers paquets de la capture Wireshark correspondent à cette connexion SSH.
Je laisse tourner deux minutes la capture (sans rien faire) sans connectivité IPv6, puis (localement sur le PC pour ne pas générer de trafic SSH), je modifie la configuration avec accept-ra: false changé pour accept-ra: true
Je fait un sudo netplan apply pour appliquer la nouvelle configuration qui active IPv6 SLAAC (Stateless Address Autoconfiguration).
Cela entraîne une nouvelle requête DHCP en IPv4, puis l'activation de l'IPv6 SLAAC qui va poser un problème et immédiatement les autres PC perdent IPv6. On le voit dans les captures, j'ai immédiatement du trafic qui est destiné au PC HP et à mon Pixel 6.
Je laisse tourner encore quelques minutes la capture.
On observe alors que de nombreux paquets IPv6 qui ne nous sont pas destinées arrivent sur notre PC avec l'adresse mac du PC, mais des adresses IP qui correspondent à d'autres PC connectés à la box. Ces derniers ne reçoivent plus les paquets IPv6, malgré de nombreuses relances.
Voici les informations sur le PC sous Ubuntu server, qui va aspirer les paquets IPv6 des autres terminaux. C'est un PC classique (j'ai testé également avec des serveurs Dell et IBM, mais ils n'avaient pas de Wi-Fi).
J'ai avancé sur ce problème de perte d'IPv6 : le trafic IPv6 de toute la box va être envoyé à un même équipement (généralement un mobile Android).
Exemple : Une flybox connectée à 5 terminaux. Le terminal qui aspire tout le trafic est le terminal 2.
Les paquets émis par le terminal 1 vont aller sur internet. La réponse provenant d'internet ne va pas revenir au terminal 1, mais au terminal 2 qui va mettre à la poubelle ces paquets qu'il n'a pas demandés.
Conséquence : les terminaux 1, 3, 4 et 5 vont récupérer une IPv6 qui ne fonctionne pas.
Comme Orange a mis un DNS64, un nom de domaine IPv4 sera annoncé en IPv6 : même le trafic IPv4 souhaite partir via une IPv6 qui ne fonctionne pas. Cela ne bloque pas tout l'accès à internet, car les navigateurs web et certaines applications qui intègrent un "fall back" vers IPv4. Quand le fall back est présent sur l'application, le trafic va partir en IPv4 (la box va l'encapsuler dans une IPv6, mais l'essentiel, c'est cela fonctionne). Quand l'application n'intègre pas de fallback, l'application ne fonctionne pas.
Jusqu'à présent, j'avais du mal à reproduire le problème : je redémarrais ma flybox et je récupérais IPv6. Mon smartphone, un Pixel 6 sous Android 16, ne déclenchant pas systématiquement le bug.
J'ai trouvé un terminal qui permet de reproduire systématiquement le bug : Ubuntu server 25.10.
- Ubuntu avec interface graphique ⇒ Le moteur par défaut est NetworkManager : Il ne déclenche jamais le bug de la flybox Nokia.
- Ubuntu sans interface graphique ⇒ Le moteur par défaut est systemd-networkd : La perte est systématique dès qu'on a "accept-ra: true" dans la configuration Netplan (RA pour Router Advertisements, c'est l'auto-configuration SLAAC).
J'ai essayé plusieurs PC, 100% de réussite avec systemd-networkd et SLAAC ! Cela fonctionne aussi bien en Ethernet qu'en Wi-Fi (oui, on peut connecter Ubuntu server au Wi-Fi, tutoriel : Configuration du Wi-Fi avec Netplan (PC sans interface graphique).
Tout le contenu du tutoriel est réalisé avec le PC qui m'a servi pour réaliser les captures ci-dessous.
Les captures ci-dessous commencent par une capture du trafic avec accept-ra: false
Exemple de configuration utilisée pour une connexion Wi-Fi : (IPv6 est désactivé)
Code: [Sélectionner]
network:
version: 2
renderer: networkd
ethernets: {}
wifis:
wlp16s0:
dhcp4: true
dhcp6: false
accept-ra: false
access-points:
"Flybox-3C4F":
password: "Y7tEEFsQUkkE"La commande sudo tcpdump -i ens1 -n -s 0 -w /tmp/capture/ethernet.pcap ou sudo tcpdump -i wlp16s0 -n -s 0 -w /tmp/capture/wifi.pcap est lancée depuis une connexion SSH, ce qui fait que les premiers paquets de la capture Wireshark correspondent à cette connexion SSH.
Je laisse tourner deux minutes la capture (sans rien faire) sans connectivité IPv6, puis (localement sur le PC pour ne pas générer de trafic SSH), je modifie la configuration avec accept-ra: false changé pour accept-ra: true
Je fait un sudo netplan apply pour appliquer la nouvelle configuration qui active IPv6 SLAAC (Stateless Address Autoconfiguration).
Cela entraîne une nouvelle requête DHCP en IPv4, puis l'activation de l'IPv6 SLAAC qui va poser un problème et immédiatement les autres PC perdent IPv6. On le voit dans les captures, j'ai immédiatement du trafic qui est destiné au PC HP et à mon Pixel 6.
Je laisse tourner encore quelques minutes la capture.
On observe alors que de nombreux paquets IPv6 qui ne nous sont pas destinées arrivent sur notre PC avec l'adresse mac du PC, mais des adresses IP qui correspondent à d'autres PC connectés à la box. Ces derniers ne reçoivent plus les paquets IPv6, malgré de nombreuses relances.
Voici les informations sur le PC sous Ubuntu server, qui va aspirer les paquets IPv6 des autres terminaux. C'est un PC classique (j'ai testé également avec des serveurs Dell et IBM, mais ils n'avaient pas de Wi-Fi).
Actus SFR Altice
Technologie mobile 4G
Incidents Bouygues
Actus Free