- Status Closed
- Percent Complete
- Task Type Anomalie
- Category Répéteur Wifi 5
- Assigned To No-one
- Operating System Tous
- Severity High
- Priority Very Low
- Reported Version 1.0
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by boorce.com - 07/12/2020
Last edited by nico-e - 08/02/2021
FS#33372 - Perte du répéteur Wifi poste version 1.2.8 si IPv6 server pas explicitement dans les DNSv6
Bonjour,
Pour résumer et après de nombreux tests j’ai découvert une anomalie dans le fonctionnement du répéteur Wifi.
Cette dernière s’est déclarée suite à la mise à jour 1.2.8 (4.2.7 pour le serveur)
Le serveur est une freebox Delta (donc en version 4.2.7).
Situation :
Sur le réseau (VM sur freebox en Debian10) un serveur pi.hole fonctionne. Il assure :
- Service DHCP IPv4.
- Service DNS IPv4 + DNS IPv6.
- Service PXE
- Blocage de publicité (par filtrage de résolutions DNS spécifiques.)
Le DHCP (IPv4) est donc désactivé sur la freebox. Par contre, dans le paramétrage de cette dernière, dans la configuration IPv6 (onglet DNS IPv6) l’IPv6 du serveur pi.hole est indiqué (et donc “Forcer l’utilisation des serveurs DNS IPv6” est coché).
Cela fonctionne parfaitement avant la version 1.2.8.
Depuis la 1.2.8, le répéteur ne trouve plus sa connexion (clignotement orange).
- La situation se rétablie en désactivant le forçage de l’utilisation des serveur DNS IPv6.
- La situation se rétablie en mettant en premier serveur DNS IPv6 l’IPv6 local du routeur (fd0f:ee:b0::1) et en gardant le forçage DNS IPv6.
Par contre cela ne fonctionne pas en indiquant l’IPv6 dans la liste des DNS du serveur pi.hole.
Ces deux dernières options font perdre les fonctionnalités de blocage de publicité, car les requêtes partent directement vers le DNS de la freebox et non sur le pi.hole.
En indiquant la délégation DNS pour les domaines free.fr et freebox.fr vers fd0f:ee:b0::1 au serveur pi.hole le problème reste le même (clignotement orange, pas de répéteur).
Quel est la solution ? Que demande le répéteur wifi qui semble bloquer son démarrage ?
08.02.2021 08:40
Reason for closing: Résolu
Additional comments about closing:
corrigé dans la 1.5.8
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Bonjour @boorce.com,
Pourriez vous, s'il vous plait, me confirmer que chez vous:
$ dig -6 mafreebox.freebox.fr A
Ne retourne pas d'IP. Alors que
$ dig @2001:4860:4860::8888 -6 mafreebox.freebox.fr A
En retourne une ?
Si c'est le cas, peut être que déléguer le domaine freebox.fr à 2001:4860:4860::8888 (ou 2606:4700:4700::64 ou 2620:119:35::35) pourrait être un contournement temporaire ?
Merci d'avoir pris le temps de nous remonter ce problème.
Bonjour,
J'ai ajouté la délégation du domaine à 2001:4860:4860::8888, mais sans résultats.
En positionnant de la même façon fd0f:ee:b0::1 cela n'a pas d'impact non plus sur le résultat final.
un "dig" sur 2001:4860:4860::8888 donne :
mafreebox.freebox.fr. 19263 IN CNAME freeplayer.freebox.fr.
freeplayer.freebox.fr. 19710 IN A 212.27.38.253
un dig sur fd0f:ee:b0::1 donne :
mafreebox.freebox.fr. 0 IN A 212.27.38.253
et
mafreebox.freebox.fr. 0 IN AAAA fd0f:ee:b0::1
il ne semble pas d'avoir d'enregistrement AAAA sur 2001:4860:4860::8888.
Le problème semble survenir quand le répéteur wifi n'obtiens pas directement fd0f:ee:b0::1 en serveur DNS par le serveur (si c'est pihole/dnsmasq qui l'envoie, ça ne fonctionne pas, il faut que cela soit le freebox server, soit en décochant Forcer l'utilisation de serveurs DNS ipv6, soit en indiquant clairement fd0f:ee:b0::1 en serveur dans cette liste...)
Il y a peut être d'autres services portés par le serveur dont dépends le répéteur, et qui ne sont pas transmis si ce dernier n'est pas en DNS directement.
Je vais regarder si wireshark voie quelque chose...
Bonjour,
Merci pour votre retour.
Est ce qu'un "dig mafreebox.freebox.fr" (sans -6) donne aussi une entree "A" ?
Pourriez vous me donner le contenu d'un /etc/resolv.conf d'un appareil sur le réseau ?
Si jamais vous faites des traces wireshark je peux aussi les regarder voir si je vois quelque chose si vous voulez.
Merci.
pi@darkmicrostar:~ $ cat /etc/resolv.conf
# Generated by resolvconf
domain ad.boorce.com
nameserver 192.168.0.253
nameserver 2a01:e0a:508:d990:90f4:d633:70b6:bc46
nameserver fe80::9ad3:4d64:5aac:6ddd%wlan0
pi@darkmicrostar:~ $ dig mafreebox.freebox.fr
; «» DiG 9.11.5-P4-5.1+deb10u2-Raspbian «» mafreebox.freebox.fr
;; global options: +cmd
;; Got answer:
;; →>HEADER«- opcode: QUERY, status: NOERROR, id: 35721
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mafreebox.freebox.fr. IN A
;; ANSWER SECTION:
mafreebox.freebox.fr. 33919 IN CNAME freeplayer.freebox.fr.
freeplayer.freebox.fr. 33988 IN A 212.27.38.253
;; Query time: 6 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Dec 09 16:49:31 CET 2020
;; MSG SIZE rcvd: 100
Je vais retenter une capture wireshark sur le wifi, dans la situation "non fonctionnelle".
Merci, juste pour être sûr tous les dig ont été fait dans la situation "non fonctionnelle" ?
Merci.
Voilà deux captures wireshark sur le WLAN (en mode monitor).
http://dl.free.fr/rs7m5z5Mu La première (capture.txt) est avec le problème. Le répéteur est redémarré (électriquement) à un moment.
http://dl.free.fr/ha8z0eldu La seconde (capture2.txt) est avec le répéteur qui fonctionne, en fait il est non fonctionnel, puis je désactive le forçage du DNSv6, ce qui le rend opérationnel.
Le 1er fichier est un peu (... un peu ...) plus gros, n'ayant pas réussis à couper correctement la capture rapidement.
La MAC du répéteur est 70:fc:8f:9c:d2:7c
Merci pour ces captures, malheureusement (ou heureusement) je ne peux pas m'en servir car comme vous le savez les communications Wi-Fi sont chiffrées.
J'ai deux idées en tête, si cela ne vous dérange pas, pour comprendre d'où vient le problème:
- Soit configurer le Serveur dans la situation où cela ne marche pas puis allumer le répéteur. Puis configurer la GW dans la situation qui marche et attendre que le répéteur se connecte (sans le redémarrer c'est important). Et me notifier quand c'est bon. Avec un peu de chance je pourrai voir ce qui a bloqué.
- Soit mettre en place un bridge ethernet entre le repeteur et le serveur et faire des traces comme cela (la configuration n'est pas facile mais comme vous avez l'air de connaitre un peu le domaine je me permets de proposer).
Merci.
Ok, je viens de choisir la première option... Tellement plus simple à mettre en oeuvre. (Et c'est fait)
Avez vous attendu quelques minutes en situation qui ne fonctionne pas (le temps que la led devienne rouge ou orange clignotante) avant de changer la configuration du Serveur ?
Oui, le voyant était bien orange.
Bonsoir,
Est ce que par hasard votre DNS bloquerait fbx-firmware.proxad.net ?
Merci
Bonour,
Non, fbx-firmware.proxad.net n'est absolument pas bloqué.
dig renvoie bien la même information dans les différents cas de tests.
Bonjour @boorce.com,
Alors j'essaie de refaire votre configuration, mais il se trouve que je ne reproduis pas le problème. J'ai configuré une VM debian 10 installé un pihole par curl | bash. Lors de l'installation pihole j'ai choisi :
- goole DNS en fallback
- Ipv4 block ads
- Ipv6 block ads
Avez vous la même configuration ?
Pour la configuration freeboxos j'ai mis l'ipv4 de la VM en DNS dans la boite de dialogue DHCP et j'ai bien coché "Forcer l’utilisation des serveurs DNS IPv6” pour rajouter l'ipv6 du server pihole dans la boite de dialogue "Configuration IPv6". Je vois bien mes requêtes DNS passer sur le pihole.
Avez vous installé des blocklists supplémentaires ou changé la configuration par défaut du pihole ?
Merci.
D'ailleurs il semble que l'interface web du pihole nous laisse voir les requêtes DNS faites (http://<pihole>/admin/queries.php), peut etre que vous pourriez voir ce qui est bloqué ici chez vous.
Bonjour,
Le fait que cela fonctionne de votre côté m'a mis la puce à l'oreille !
J'ai modifié l'adresse ipv6 envoyé par la freebox pour le DNS "forcé". J'utilisais l'IP "lien local", en fe80::, hors depuis la 1.2.8 (a priori) le répéteur ne semble plus le voir !
En utilisant l'IPv6 liens global de mon "pihole" ( 2a01:e0a:...) cela s'est mis à fonctionner.
Donc je conclue que le répéteur ne voie plus certaines adresses en "fe80:"
Pour moi le sujet et réglé, comme cela fonctionne.
Je viens de tester avec la link local et ça marche aussi, elle aurait pas changé depuis le reboot de la box chez vous ?
Bonjour,
Normalement j'ai trouvé un problème dans la gestion des adresses ipv6 linklocal (fe80::/10)
Par contre on ne devrai pas tomber dedans si il y a bien de l'ipv4 sur le réseau.
Donc normalement corrigé dans la prochaine version.