Auteur Sujet: [Résolu] - Problème avec Google Nest WiFi et l'IPV6 (Lu 3317 fois)

quentind · « **Réponse #12 le:** 13 juin 2023 à 01:39:14 »

Citation de: kgersen le 12 juin 2023 à 23:26:29

Perso je ne vois pas ou est le souci, ca permet un fonctionnement plug & play simple quelque soit la configuration réseau existante. C'est concu pour un usage grand public.

Y'a plein de Google Nest (Wifi, thermostats, etc) déployés dans le monde donc on peut supposer que cela ne pose pas de problème a la grande majorité sinon ils auraient changé ce comportement ?

y'a une norme (rfc 4862 , section 5.5.3) qui dit de "silently ignore the Prefix Information option" si les lifetime ne sont pas conformes a certaines valeurs.

Je dirais donc qu'a priori c'est plutot le poste Ubuntu de l'OP qui a un souci, il ne respecte pas cette norme s'il ignore pas ces annonces RA ?

T'as utilisé quel port du Nest pour le relier au LAN ?

Je connaissais pas cette RFC, après ce qui m'embête c'est pas qu'ils utilisent l'IPV6 pour communiquer, juste qu'un bridge WiFi se comporte comme un routeur alors que je le configure pour ne pas faire ça. Je vois pas de raison pour qu'il se comporte ainsi. Comme je le disais, les éléments Google fonctionnent très bien en étant connecté à un routeur quelconque, pas nécessaire un Google Wifi.

Et ceci dit ça me surprendrait énormément que Ubuntu ne respecte pas une RFC officielle...

Et sinon j'utilise le port WAN pour me connecter à mon routeur. Effectivement je devrais peut être essayer le port LAN à la place ? Je me disais qu'en mode bridge il se comporterait de la même manière

renaud07 · « **Réponse #13 le:** 13 juin 2023 à 03:02:17 »

On pourrait avoir une capture de ces RA ?

Pour ce qui est de la RFC 4862, il est dit que si preferred lifetime est plus grand que valid lifetime, il faut ignorer le préfixe. Hors ce n'est pas ce qui à l'air de se passer. Le pref est à 0 mais le valid est plus grand... donc tout le monde récupère quand même le préfixe. Ils auraient dû faire pref > valid ou jouer sur le flag A !

J’essaierais de faire une conf similaire avec radvd, voir si j'ai le même bug.

simon · « **Réponse #14 le:** 13 juin 2023 à 09:11:54 »

Pref = 0 et Valid > 0 : le prefixe est valide, doit être configuré sur les machines si on a bien le flag A, mais il est deprecated donc il faut éviter de l'utiliser pour des nouvelles connexions.
Ils émettent bien router lifetime = 0 ?

Miser sur le respect des gardes fous spécifiés dans une RFC me semble quand même très téméraire pour ne pas dire autre chose. Si on veut faire de la comm locale et automatique entre devices IoT, il y a plusieurs méthodes qui ont prouvé leur efficacité à grande échelle et moins intrusives que de mettre le bazar dans un réseau existant:
a) utiliser les adresses link-local, avec détection et potentiellement comm en multicast,
b) annoncer un préfixe ULA seulement si aucun autre préfixe n'est présent sur le réseau,
c) si on veut un réseau sur lequel on peut tout faire, créer un réseau mesh wifi dédié pour la comm IoT.

Il y a probablement d'autres facons de faire. Apple fait une combinaison de a) et b) pour AirPrint, AirPlay et autres (utilise un prefixe GUA/ULA si présent, sinon utilise les adresses link-local), mais n'annonce pas de préfixe de lui-même.
J'ai vu d'autres devices faire c) pour ne pas dépendre de la présence ou impacter un réseau existant.

kgersen · « **Réponse #15 le:** 13 juin 2023 à 10:26:26 »

Oui on peut discuter la pertinence de leur choix, j'imagine qu'ils ont du réfléchir longuement a la question.

Aussi ce qui est curieux c'est que cela perturbe Firefox sur Ubuntu. Je serais curieux de voir ce que cela donne sur d'autres OS/Navigateur.

Sinon contacter le support Nest pour voir si y'a un pas une manip cachée possible.

simon · « **Réponse #16 le:** 13 juin 2023 à 11:39:49 »

Citation de: kgersen le 13 juin 2023 à 10:26:26

Oui on peut discuter la pertinence de leur choix, j'imagine qu'ils ont du réfléchir longuement a la question.

Oh, tu sais, dans l'embarqué/IoT, plus ca va plus on se demande... Et j'entends de moins en moins de bien de Nest depuis leur rachat par Google.
Un temps, j'ai failli bosser chez eux sur ces sujets là justement

Citation de: kgersen le 13 juin 2023 à 10:26:26

Aussi ce qui est curieux c'est que cela perturbe Firefox sur Ubuntu. Je serais curieux de voir ce que cela donne sur d'autres OS/Navigateur.

En effet, Firefox devrait respecter le source address selection algorithm et utiliser le préfixe GUA en priorité. Peut-être une modif faite dans /etc/gai.conf ?

quentind · « **Réponse #17 le:** 13 juin 2023 à 11:50:08 »

J'ai l'impression que comme la conf ipv6 change régulièrement avec ces RA en nombre, ça impacte la stabilité de la connexion. Même c'est de l'ordre de la micro-coupure, dès que la liste est complète il utilise toujours la GUA en priorité.

Je vous met ici un exemple des RA

J'ai déjà sollicité le support de Google, mais je m'attends pas à grand chose...c'est plutôt grand public ^^

renaud07 · « **Réponse #18 le:** 13 juin 2023 à 13:46:59 »

WTF ?!

Tu as bien une seule nest ? Pourquoi diable y'a 2 link locales avec des lifetime différents qui annoncent la même route ?

Le premier c'est l'openwrt (b8c9) ? Mais dans ce cas il a pas l'air bien configuré (on devrait avoir la GUA aussi ou t'as un autre routeur pour les ULA ?)... Et on dirait que la nest (1230), copie la route et l'annonce à son tour, j'ai jamais vu ça.

Et après on s'étonne que ça déconne...

quentind · « **Réponse #19 le:** 13 juin 2023 à 14:59:20 »

Alors en fait de ce que je vois les deux MAC 1230 et b8c9 sont originaires du Google Wifi. J'en ai qu'un seul oui...

Et oui j'ai deux préfixes qui sont diffusés par la Google Wifi, en ULA...

renaud07 · « **Réponse #20 le:** 13 juin 2023 à 17:38:20 »

De mieux en mieux... C'est bien la peine de faire un préfixe spécial mais d'en diffuser un autre bien valide à côté depuis une autre link local !

Mais surtout que vient faire cette route au milieu qui ne correspond à rien du tout ?

Vraiment y'a rien qui va avec ce truc. Je ne comprend absolument pas ce qu'ils ont voulu faire avec une conf pareille

EDIT : J'ai testé de mon côté un préfixe avec preferred lifetime à 0 et je n'ai pas eu d'erreur sur Firefox. C'est toujours la même IP qui revient ? Dans ce cas, le fait de jouer sur les privacy extensions n'a pas d'effet on dirait.

Code: [Sélectionner]

Jun 13 17:52:53 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*.
Jun 13 17:52:54 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.
Jun 13 17:53:28 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*.
Jun 13 17:53:29 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.

Peux-tu vérifier que l'erreur se produit bien lorsque le timer de l'adresse se réinitialise ? avec un watch -n 1 ip a Par contre attention ça n'attend pas d'être à 0s y'a une marge.

kgersen · « **Réponse #21 le:** 13 juin 2023 à 18:11:19 »

étrange indeed

y'a comme qui dirait un 3eme lan dont la route est annoncée par ce routeur wifi
y'a un RA prefix avec litefime a 0 donc celui la est a ignoré
l'autre par contre non...

Il est branché comment ton Google Wifi ? c'est un modele avec 2 ports Ethernet, un lan , un wan ? t'as bien mis le port lan vers ton routeur ?

t'as un wifi invité ? un meshing ?

renaud07 · « **Réponse #22 le:** 13 juin 2023 à 18:40:53 »

Et si la route inconnue était le préfixe ULA de l'openWRT ? Donc ça veut dire que ça serait annoncé en triple ?! Vu que je suppose que l'OWRT envoie aussi ses RA avec GUA + ULA...

Si on résume on aurait donc un nest en "bridge" qui laisse passer le trafic mais récupère au passage les infos des RA qu'il voit passer, pour annoncer lui-même une route vers un préfixe ULA qui n'est pas censé gérer.

C'est seulement prévue dans une quelconque RFC ce genre de fonctionnement surréaliste ?

EDIT : @quentind : Tu reçois bien les RA de l'OWRT sur tes appareils en wifi au moins ?

quentind · « **Réponse #23 le:** 22 juin 2023 à 01:06:11 »

Citation de: renaud07 le 13 juin 2023 à 17:38:20

De mieux en mieux... C'est bien la peine de faire un préfixe spécial mais d'en diffuser un autre bien valide à côté depuis une autre link local !

Mais surtout que vient faire cette route au milieu qui ne correspond à rien du tout ?

Vraiment y'a rien qui va avec ce truc. Je ne comprend absolument pas ce qu'ils ont voulu faire avec une conf pareille

EDIT : J'ai testé de mon côté un préfixe avec preferred lifetime à 0 et je n'ai pas eu d'erreur sur Firefox. C'est toujours la même IP qui revient ? Dans ce cas, le fait de jouer sur les privacy extensions n'a pas d'effet on dirait.

Code: [Sélectionner]
Jun 13 17:52:53 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*. Jun 13 17:52:54 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3. Jun 13 17:53:28 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*. Jun 13 17:53:29 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.
Peux-tu vérifier que l'erreur se produit bien lorsque le timer de l'adresse se réinitialise ? avec un watch -n 1 ip a Par contre attention ça n'attend pas d'être à 0s y'a une marge.

en fait c'est bizarre le timer est toujours à 0sec quand je fais un ip a...
L'erreur se produit de façon très très rare, c'est difficile à reproduire mais je suppose que c'est quand le chargement d'une page se produit pile au moment de la prise en compte d'une route ipv6 ?