La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: nicox11 le 01 février 2021 à 00:32:25
-
Bonjour,
Je rencontre depuis quelques jours un problème d'IPv6 en WIFI. Le Wifi est sur le même vlan que mes équipements en filaire (qui eux n'ont pas de problème), mais mes appareils Wifi n'obtiennent pas d'IPV6.
En fait, quand je reboot mon ap j'obtiens une adresse IPv6 et cela fonctionne pendant un certain temps (moins d'une heure voir même quelques minutes uniquement), puis plus rien.
J'ai essayé de chercher un peu en faisant une capture réseau.
Lorsque je fais une capture sur ma borne WIFI, je vois bien les IPv6 RA de mon routeur et les IPv6 RS de mon appareil wifi, mais c'est à peu près le seul trafic IPv6 que je vois.
Je ne vois pas de Neighbor Solicitation (qui devrait être fait juste après pour vérifier l'unicité de l'adresse ? Pour être plus précis, je le vois uniquement pour l'adresse de type Link-Local mais pour l'adresse global unicast).
Bref je ne connais surement pas suffisamment IPv6 et je ne sais pas trop comment orienter mon troubleshoot. Si quelqu'un de plus expérimenté pourrait m'orienter, ce serait super :)
Merci
-
Mise à jour des AP peut-être ? Ils ont l'air de bloquer les annonces du routeur au bout d'un moment.
On est bien d'accord que les AP ne sont pas configurés eux-mêmes en routeur ? Je préfère demander car tellement courant !
-
C'est quoi le modele de ton AP wifi ?
J'ai deja vu des modeles qui bloquent soit de facon aleatoire soit de facon systematique certains types de paquets (genre multicast) necessaires pour le bon donctionnement de l'IPv6. 2 qui me passent par la tete sont Linksys(depuis la reprise de Belkin) - blocage aleatoire au bout de quelque temps et OpenMesh/datto - jamais reussi à faire passer les RA.
-
Mise à jour des AP peut-être ? Ils ont l'air de bloquer les annonces du routeur au bout d'un moment.
On est bien d'accord que les AP ne sont pas configurés eux-mêmes en routeur ? Je préfère demander car tellement courant !
Salut, effectivement le problème pourrait remonter à une mise à jour de l'AP.
Pour info, la solution wifi avec IPv6 était en fonctionnement depuis un moment (a déjà marché donc).
C'est une ap ubiquiti uap ac lite, qui à ma connaissance ne peut pas faire le rôle de routeur ? Je vais vérifier ce mode tout de même.
De plus, je fais une capture sur le ssid, et j'observe bien les ra et rs donc ça ne semble pas bloqué.
-
J'ai creusé un peu plus, mais j'ai des résultats très étranges.
Tout d'abord, en utilisant un PC en WIFI, cela fonctionne normalement comme mes PC en filaire.
Le problème survient donc avec des équipements android (2 de même marques malheureusement).
Dans le cas fonctionnel j'ai bien :
Router Solicit
Router Advertisement
Neighbor Solicitation (pour le DAD)
Par contre, dans le cas de mes appareils android j'ai uniquement :
Router Solicit
Router Advertisement
Aucun Neighbor Solicitation. De plus, en 4G, j'ai bien une IPv6 ! Bref à ne plus y comprendre. Pourquoi en passant sur mon Wifi l'appareil n'appliquerait plus un "Neighbor Solicitation" ?
Le paquet Router Advertisement contient bien le préfix global unicast.
-
J'ai un UAP AC LITE aussi (version du contrôleur: 6.0.45, firmware: 4.3.24.11355), pas de problème particulier avec IPv6.
Par contre, oui, vérifier que dans le contrôleur le multicast n'est pas filtré (quand j'active le filtrage du multicast je perds l'IPv6, mais sur tous mes devices, ce qui est normal en fait...). Normalement ce n'est pas activé par défaut, et de toute façon ça n'explique pas que ça fonctionne sur certains appareils...
-
J'ai un UAP AC LITE aussi (version du contrôleur: 6.0.45, firmware: 4.3.24.11355), pas de problème particulier avec IPv6.
Par contre, oui, vérifier que dans le contrôleur le multicast n'est pas filtré (quand j'active le filtrage du multicast je perds l'IPv6, ce qui est normal en fait...).
J'ai aussi le controleur en version 6.0.45 et le firmware de la borne est en 4.3.24.11355. Tout comme toi donc.
Sur le controleur quand je vais dans la configuration du SSID, j'ai bien l'option Filtrage Multicast et Broadcast qui n'est pas cochée.
C'est qui est étrange, c'est que tous les appareils en wifi ne semble pas avoir le même problème (le pc semble bien marcher en IPv6 mais pas les android).
-
Oui, j'ai modifié mon message entre temps, parce que rien n'explique le comportement différent entre les appareils.... Je n'ai rien qui tourne sous android chez moi donc pas possible de tester.
-
Les appareils Android ne supportent pas DHCPv6. Si les RA obligent le client à utiliser DHCPv6 (flag M à 1), les clients Android ne cherchent pas à obtenir une IPv6.
Si tu peux partager une capture des RA, ça se verra vite
-
Les appareils Android ne supportent pas DHCPv6. Si les RA obligent le client à utiliser DHCPv6 (flag M à 1), les clients Android ne cherchent pas à obtenir une IPv6.
Si tu peux partager une capture des RA, ça se verra vite
Salut,
Voici une capture d'un RA (on voit Ubiquiti dans le RA, ce n'est pas la borne mais un routeur Edgerouter 4).
Par contre, finalement le problème n'est pas uniquement sur les android. En fait, j'ai pu retester avec le pc et cette fois ci pas d'ipv6 !
A un autre moment, j'ai réussi à avoir l'ipv6 sur un android.
Bref tout ça semble aléatoire. Mais à chaque fois, le RA semble bien envoyé sur les "ondes".
-
La capture du RA confirme que le problème ne vient pas des flags, qui demandent d'utiliser SLAAC
Je ne vois pas trop d'où ça pourrait venir ce problème intermittent.
Ça ne pourrait pas être un problème de délais entre chaque envoi de RA ? Quel est la fréquence d'émission de RA ?
-
La capture du RA confirme que le problème ne vient pas des flags, qui demandent d'utiliser SLAAC
Je ne vois pas trop d'où ça pourrait venir ce problème intermittent.
Ça ne pourrait pas être un problème de délais entre chaque envoi de RA ? Quel est la fréquence d'émission de RA ?
Disons que je désactive le Wifi puis que je le réactive (sur le smartphone). Lorsque je fais une capture à ce moment, je vois bien le RS puis immédiatement le RA. Donc je comprends pas trop non plus, car les échanges ont l'air bon mais aucune IPv6 ou aléatoirement ils en récupèrent.
Jusqu"à maintenant, au redémarrage de la borne wifi ça fonctionne.
-
Il faudrait faire une capture Wireshark quand ça fonctionne, et quand ça ne fonctionne pas. Ça pourra peut-être nous aider :-\
-
J’ai aussi un ER4...
Question: tu as des switchs intermédiaires entre ta borne et ton ER4 ? Des Edgeswitch ?
Il y a un bug documenté chez Ubiquiti: si tu actives IGMP snooping alors le fonctionnement du multicast v6 devient erratique, et du coup ça casse SLAAC. Pour régler le problème il faut aussi activer mld sur le(s) switch. Chez moi j’ai un es8-150 et un es-24-lite entre l’ER4 et l’uap, et j’ai mis du temps à comprendre le problème avec IGMP snooping...
-
Il faudrait faire une capture Wireshark quand ça fonctionne, et quand ça ne fonctionne pas. Ça pourra peut-être nous aider :-\
Je l'avais fait. Je peux essayer de le refaire.
Mais en gros, ce que j'ai remarqué, c'est que dans le cas où ça marche le client fait bien un Neighbor Sollicit (pour le DAD je suppose) alors que sinon aucun Neighbor Sollicit n'est généré (ce qui indiquerait un problème sur le client mais c'est pas logique).
J’ai aussi un ER4...
Question: tu as des switchs intermédiaires entre ta borne et ton ER4 ? Des Edgeswitch ?
Il y a un bug documenté chez Ubiquiti: si tu actives IGMP snooping alors le fonctionnement du multicast v6 devient erratique, et du coup ça casse SLAAC. Pour régler le problème il faut aussi activer mld sur le(s) switch. Chez moi j’ai un es8-150 et un es-24-lite entre l’ER4 et l’uap, et j’ai mis du temps à comprendre le problème avec IGMP snooping...
J'ai un switch entre le ER4 et la borne mais c'est un switch Netgear basique. Pas d'IGMP snooping d'activé (je n'en ai pas l'utilisation en fait, même pas sur que ça y soit).
-
J'ai aussi le controleur en version 6.0.45 et le firmware de la borne est en 4.3.24.11355. Tout comme toi donc.
Sur le controleur quand je vais dans la configuration du SSID, j'ai bien l'option Filtrage Multicast et Broadcast qui n'est pas cochée.
Vérifier également que l'option
Enable multicast enhancement (IGMPv3)
n'est pas cochée.
C'est une fonction qui transforme le Multicast en Unicast sur le réseau sans-fil,
mais qui va également bloquer tout l'ICMPv6 dès lors que l'appareil client est auto-détecté comme émetteur de multicast.
Ce qui peut arriver avec les services Bonjour / mDNS, présents sur certains appareils (mais pas tous).
-
Il y a un bug documenté chez Ubiquiti: si tu actives IGMP snooping alors le fonctionnement du multicast v6 devient erratique, et du coup ça casse SLAAC.
Et il y en a peut-être d'autres.
Il y a un tas de sujets sur UI / Reddit pas réellement clôturés à propos de l'IGMP snooping sur les EdgeSwitches.
De mon côté j'ai l'impression que l'IGMP snooping des ES ne fonctionne correctement qu'en face de l'igmp-proxy EdgeRouter.
En face d'un routeur Mikrotik rien ne va plus... une fois sur deux la souscription d'un client VLC/MPV/décodeur Orange n'aboutit pas, et si elle passe quand même, le flux s'interrompt toujours au bout de quelques minutes car les "membership reports" des clients multicast ne remontent jamais (ou rarement) jusqu'au routeur.
- j'ai tout essayé sur l'EdgeSwitch (déclarer le port du routeur multicast, activer l'IGMP sur les ports et/ou le VLAN, activer l'IGMP querier, ...), ca reste aléatoire
- si on désactive l'IGMP snooping, tout fonctionne bien (mais le flux bave sur tous les ports)
- si on remplace l'ES par un Cisco SG350 ou un Netgear manageable, tout fonctionne parfaitement
Quand tout marche bien on a ceci à chaque query-interval
14:38:19 igmp-proxy,debug sending IGMP query to 224.0.0.1 on bridge
14:38:20 igmp-proxy,debug RECV IGMPv2 membership report from 10.39.10.109 to 232.0.3.4 on bridgeet le flux est maintenu.
Avec l'edgeswitch
10:49:31 igmp-proxy,debug sending IGMP query to 224.0.0.1 on bridge
10:49:41 igmp-proxy,debug removing multicast forwarding entry
10:49:41 igmp-proxy,debug group: 232.0.3.4
10:49:41 igmp-proxy,debug source: 81.253.237.117
10:49:41 igmp-proxy,debug leaving multicast group 232.0.3.4 on orange-840 et le flux s'arrête.
-
Je l'avais fait. Je peux essayer de le refaire.
Mais en gros, ce que j'ai remarqué, c'est que dans le cas où ça marche le client fait bien un Neighbor Sollicit (pour le DAD je suppose) alors que sinon aucun Neighbor Sollicit n'est généré (ce qui indiquerait un problème sur le client mais c'est pas logique).
Le but est de comparer les RA entre une situation qui fonctionne et une situation qui ne fonctionne pas.
Comment tu fais tes captures sur des appareils Android ? Directement sur le téléphone ?
J'ai un switch entre le ER4 et la borne mais c'est un switch Netgear basique. Pas d'IGMP snooping d'activé (je n'en ai pas l'utilisation en fait, même pas sur que ça y soit).
Et si tu le vires le temps des essais, le problème apparait toujours ?
-
Le but est de comparer les RA entre une situation qui fonctionne et une situation qui ne fonctionne pas.
Comment tu fais tes captures sur des appareils Android ? Directement sur le téléphone ?
Et si tu le vires le temps des essais, le problème apparait toujours ?
Je pourrais le faire quand j'aurai un cas de fonctionnel :P Actuellement pas d'IPv6 sur les appareils. Concernant les captures, je fais tout sur la borne (donc jamais directement sur le téléphone par exemple) et parfois sur le routeur afin de vérifier qu'il reçoit bien tout.
Enlever le switch est compliqué.
En refaisant une capture, par contre j'ai pu observer un packet multicast généré par le client juste après les RS et les RA initiaux (que signifie ce changed to exclude ?).
Concernant le switch, donc igmp snooping est desactivé mais j'ai un menu pour du "MLD" mentionné plus haut, mais je dois avouer être incapable pour le moment de configurer.
-
Concernant les captures, je fais tout sur la borne (donc jamais directement sur le téléphone par exemple).
Ce n'est pas terrible, car si le problème vient de la borne (qui filtrerait par exemple les RA envoyés par le routeur, on les verrait sur la capture mais le client ne les recevrait pas)
Pour les tests avec le PC, je te conseille de faire la capture sur le PC directement.
Pour les smartphones, c'est beaucoup plus compliqué (mais c'est possible, surtout avec un smartphone rooté)
-
Ce n'est pas terrible, car si le problème vient de la borne (qui filtrerait par exemple les RA envoyés par le routeur, on les verrait sur la capture mais le client ne les recevrait pas)
Pour les tests avec le PC, je te conseille de faire la capture sur le PC directement.
Pour les smartphones, c'est beaucoup plus compliqué (mais c'est possible, surtout avec un smartphone rooté)
Effectivement, après avoir fait quelques tests, il semblerait que bien que les "RA" soient visible sur le tcpdump de la borne, l'appareil n'en reçoit que quelques uns.
Là où le PC flood énormement de "RS" et fini par recevoir un "RA", mes téléphones android envoient beaucoup moins de "RS".
Il semblerait que la borne wifi filtre de manière aléatoire les RA envoyé par le routeur. Cela semble à un problème suite à une mise à jour, vu que la date d'apparition concorde.
Voici quelques posts qui semblent avoir le même problème que moi :
https://community.ui.com/questions/UniFi-AP-AC-Pro-drops-ICMPv6-IPv6-related-Ethernet-multicast/29ed7d2b-b106-4b48-9a36-dd5e8b8ccd7f
https://community.ui.com/questions/Problem-with-ICMPv6-again/d58df6ef-cd33-472a-898c-cfe606a38f21
Je vais peut-être essayer de downgrade la borne si c'est possible pour vérifier.
-
Il semblerait que la borne wifi filtre de manière aléatoire les RA envoyé par le routeur. Cela semble à un problème suite à une mise à jour, vu que la date d'apparition concorde.
Désolé d'insister :) mais...
tu es sûr de ne pas avoir activé l'option : Enable multicast enhancement (IGMPv3)
dans la configuration de ton réseau Wifi ?
Car de mon côté ça provoquait exactement ces mêmes symptomes.
-
Désolé d'insister :) mais...
tu es sûr de ne pas avoir activé l'option : Enable multicast enhancement (IGMPv3)
dans la configuration de ton réseau Wifi ?
Car de mon côté ça provoquait exactement ces mêmes symptomes.
Non pas coché.
-
Non pas coché.
Ah dommage, je l'aurais presque parié... Désolé pour la fausse piste.
-
Histoire d'essayer, je suis repassé sur une ancienne version. Pour le moment ça fonctionne (comme d'hab après un reboot).
Je vais donc observer si ça tient sur la durée. Si c'est le cas, je suspecte fortement la dernière version.
-
24 h plus tard j'ai toujours l'ipv6 d'actif sur mes appareils. On dirait bien que c'est la version 4.3.24.11355 de la borne qui me posait des soucis et depuis le downgrade tout semble bon.
Je garde un oeil.
Mais merci pour l'aide lors de l'investigation, ça pourra me resservir.
-
Bonjour,
Je déterre ce sujet car j'ai l'impression que c'est à nouveau d'actualité, perte de l'ipv6 au bout d'un moment...
(UDM (3.2.12 / 8.1.113) + AC Lite + LR6 + FBX Ultra en Bridge)
Aucun problème en Ethernet