- État Nouveau
- Pourcentage achevé
- Type Autre
- Catégorie LAN
- Assignée à Personne
- Système d'exploitation Freebox Server V6 (Révolution)
- Sévérité Moyenne
- Priorité Très Basse
- Basée sur la version 4.9.13
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par fabienO - 24/11/2025
Dernière modification par fabienO - 26/11/2025
FS#40680 - Requêtes ARP incessantes du Freebox Server - Who has 192.168.27.1? - Who has 192.168.27.98?
Je viens de migrer ma V5 vers la V6 Révolution (j’étais peut-être le dernier en V5 :) et depuis mon réseau est saturé de requêtes ARP à raison d’environ deux par seconde. Exemple d’une capture Wireshark :
No. Time Source Destination Protocol Length Info 1 0.000000000 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.1? Tell 192.168.27.14 2 1.035509266 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.98? Tell 192.168.27.99 3 1.039834113 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.1? Tell 192.168.27.14 4 2.079834644 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.1? Tell 192.168.27.14 5 2.079835099 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.98? Tell 192.168.27.99 6 3.119842341 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.98? Tell 192.168.27.99 7 3.120214935 FreeboxSas_4f:36:d3 Broadcast ARP 60 Who has 192.168.27.1? Tell 192.168.27.14
Cela perturbe très fortement mon monitoring réseau en le rendant pratiquement illisible. Par ailleurs, je déteste les services parasites sur mon réseau.
D’après mes recherches, ces requêtes seraient liées à la fonctionnalité de serveur VPN du Freebox Server.
Dans Freebox OS, tout est désactivé dans Serveur VPN et Client VPN ; dans Gestion des ports → Connexions entrantes, tout (Autorisé et Actif) est paramétré à Non, en particulier tout ce qui concerne Serveur VPN. Plus généralement, j’ai éliminé tous les services qu’il est possible de désactiver (je peux donner plus de détails si nécessaire).
En l’état actuel du système, est-il possible de faire cesser ces requêtes inutiles, indésirables et injustifiées ?
Sinon, serait-il possible de le faire évoluer pour que le serveur VPN soit totalement désactivé quand c’est le souhait de l’utilisateur ? Cela paraîtrait logique.
Tâche ouverte possiblement liée : FS#40505 - gros ralentissements de mon reseau / envoie d’ ARP sur des adresses fantomes
Merci.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
bonjour,
ce n'est pas lié au VPN
non
si aucun service vpn n'est activé, alors le service VPN ne fait rien mis à part attendre un changement de configuratioN
Bonjour mmakassikis, merci pour votre réponse.
ce n'est pas lié au VPN
Pourriez-vous s'il vous plaît donner quelques éléments sur l'origine et la justification de ces requêtes ARP sur mon réseau ?
il s'agit de tentatives de connexions de la box vers d'autres équipements free (player, backup 4g)
Tout d'abord merci d'avoir corrigé mon hypothèse d'un lien avec le serveur VPN, j'ai modifié mon titre initial en conséquence.
« il s'agit de tentatives de connexions de la box vers d'autres équipements free (player, backup 4g) »
OK, merci pour l'information. J'imagine qu'il serait vain d'espérer une modification du design.
En ce qui concerne le Player, j'ai en effet remarqué que les requêtes pour 192.168.27.1 cessent quand il est démarré.
Le "backup 4g" (probablement 192.168.27.98) pourrait cependant peut-être faire l'objet d'une option au choix de l'utilisateur.
La seule solution semble de passer en mode bridge, avec des conséquences qu'il me reste à examiner, et mettre en place une passerelle.
le backup 4g est censé être plug-and-play pour l'abonné: la box passe automatiquement sur le backup si celui-ci est allumé et connecté au réseau local et le lien fibre/DSL est down.
rajouter une option est un coup à ce que quelqu'un la décoche, l'oublie, et le jour où il y a un besoin d'utiliser un backup cela ne marche pas du tout. bien évidemment tout le monde (abonné, hotline, …) aura oublié que cela existe.
n'y a-t-il pas moyen de lui indiquer d'ignorer les requêtes ARP en question ?
« le backup 4g est censé être plug-and-play pour l'abonné: la box passe automatiquement sur le backup si celui-ci est allumé et connecté au réseau local et le lien fibre/DSL est down. »
D'accord, je comprends. Mais puisque la fonctionnalité n'est utilisée que si la synchro est perdue, pourquoi ne pas lancer les requêtes uniquement dans ce cas ? Si c'est pour des raisons de diagnostic du boîtier backup, le technicien devrait pouvoir lancer les requêtes au besoin. Si c'est pour permettre à l'usager de tester la détection du boîtier, un élément de menu dans l'interface pourrait déclencher cette action. Pardonnez ma question, je suis bien sûr plus que loin d'avoir conscience de l'ensemble des impératifs.
« n'y a-t-il pas moyen de lui indiquer d'ignorer les requêtes ARP en question ? »
Oui,avec Wireshark c'est facile : clic droit sur la partie info du paquet (Who has 192…) → Appliquer comme un filtre → Non sélectionné. Le filtre automatiquement créé est
!(_ws.col.info == "Who has 192.168.27.98? Tell 192.168.27.99")
Mais en fait, j'ai surtout l'habitude de regarder ce qu'il se passe quand j'ai du trafic alors qu'il devrait être à zéro, et maintenant j'ai un trafic permanent. Je choisis les services et limite au strict nécessaire, ce qui me permettait de détecter une activité inhabituelle d'un coup d'œil ou de savoir si un programme communique. Bref, je viens de subir une petite disruption dans mes habitudes :) Vos explications ont cependant le mérite de rationaliser l'origine du problème et d'apporter des justifications recevables pour un service grand public destiné à des usages larges et variés.
le backup peut être connecté alors que le lien principal (fibre/dsl) est encore opérationel, auquel cas la box s'assure qu'il est en mode avion puisque non utilisé. Pour faire ceci, il faut bien s'y connecter.
un backup peut être envoyé suite à l'identification d'un problème sur la ligne d'un abonné, sans intervention de technicien.
dans wireshark, vous pouvez utiliser le filtre "not vlan 400" avant de lancer la capture.
Bonjour/Bonsoir mmakassikis. Je travaille sur une solution générale basée sur l'ID du VLAN suite à votre précieux indice. Je cherche à créer une règle nftables, mais ce n'est pas encore gagné :)
Je ferai, j'espère bientôt, une réponse complète à votre précédent message.
Échec :(
table arp filter { chain INPUT { type filter hook input priority 0; policy accept; meta protocol arp arp saddr ether $FbxServerMAC arp ptype vlan counter drop counter accept } }ne matche rien, le compteur drop reste à zéro, même si je supprime la condition saddr. Le compteur accept incrémente doucement (c'est à dire normalement).
table netdev filter { chain INGRESS { type filter hook ingress device enp3s0 priority 0; policy accept; vlan id { 100, 400 } vlan type arp counter drop counter accept } }matche très bien, le compteur drop incrémente au rythme des requêtes du vlan. Mais pour une raison qui me dépasse, les paquets ne sont pas réellement droppés, ils apparaissent toujours dans Wireshark ou tcpdump, et mon indicateur de charge réseau n'est toujours pas à zéro. C'est très mystérieux pour moi.
« le backup peut être connecté alors que le lien principal (fibre/dsl) est encore opérationel, auquel cas la box s'assure qu'il est en mode avion puisque non utilisé. Pour faire ceci, il faut bien s'y connecter. »
« un backup peut être envoyé suite à l'identification d'un problème sur la ligne d'un abonné, sans intervention de technicien. »
Je me doutais qu'il y avait de bonnes raisons. Merci pour les explications.
« dans wireshark, vous pouvez utiliser le filtre "not vlan 400" avant de lancer la capture. »
Votre indice m'a incité à chercher une solution nftables utilisant l'ID du VLAN. Même si j'ai échoué, c'est une recherche intéressante. Merci beaucoup.
Le filtre d'affichage de Wireshark qui fonctionne bien est
!(arp && vlan.id in {100,400})Dommage que ça ne soit pas aussi simple avec nftables :)
C'est un plaisir et un privilège d'être guidé avec des informations de première main, un grand merci mmakassikis. Je ne manquerai pas de publier un message si je trouve une solution.
J'ai réfléchi (si, si). Pas de mystère. D'après nft(8) :
Table 3. Netdev address family hooks
[…]
ingress
All packets entering the system are processed by this hook. It is invoked after the network taps (ie. tcpdump), right after tc ingress and before layer 3 protocol handlers, it can be used for early filtering and policing.
C'est donc normal que, par exemple, tcpdump voit passer les paquets. Le trafic réel sur l'interface physique ne peut pas être ignoré.
La solution ne peut être qu'un switch manageable. Ou une passerelle intermédiaire (là la règle de drop serait efficiente pour le reste du réseau).
Bonjour
un peu violent mais:
et
Puis monitor si vous voyez toujours les vlan:
Cordialement
nbanba
Bonjour
Si vous ne voulez pas faire la solution violente proposée avec ethtool -K vous pouvez aussi faire des règles pour chaque vlan
quelque chose comme
Monter une interface vlan pour chaque vlan qui "atrape le trafic"
Puis créer un ingress hook sur chaque vlan interfaces:
et confirmer les drop avec
Dans l'idées ça peut marcher
Sinon autre idée, eh oui j'en ai plein (problème intéressant aux limite du L2 dans la stack net du kernel), traffic control:
Ou violemment désactiver les vlan sur le hardware (très violent !):
Sinon on peut également travailler directement à la couche OSI-L2 (Ethernet) avec ethernet bridge:
Dites moi si une des solution fonctionne svp
Cordialement
nbanba
Bonjour nbanba, merci beaucoup pour vos propositions de tests. Dans l'ordre:
proposition 1
proposition 2
Je pense qu'on est peu ou prou dans le même cas que ce à quoi j'étais arrivé, c'est à dire que les paquets sont droppés trop tard.
proposition 3
J'ai tenté de compléter la ligne de commande après quelques recherches dans le manuel de tc et ses manuels affiliés.
Je me suis arrêté là car tc n'est pas une commande qu'on maîtrise en cinq minutes.
Une idée ?
proposition 4
« Ou violemment désactiver les vlan sur le hardware (très violent !): »
proposition 5
Peut-être tc s'il est possible de corriger la commande ?
Merci beaucoup nbanba.
note: si un admin en a la possibilité, serait-il possible de corriger mon subjonctif dans mon message précédent ? que […] tcpdump voi
tpasser les paquets → que […] tcpdump voie passer les paquets.Bonjour
J'ai joué les commandes tc sur une VM avec une NIC VirtIO ⇒ no hardware offload.
Donc dans mes tests, seul les options "softwares" fonctionnent et l'interface est enp0s5 (à modifier par enp3s0):
On voit clairement le "skip hardware offload" (skip_hw) du à la typologie de NIC que j'utilise pour ce test (redhat virtIO virtual nic)
Chez moi les options sont limités
Mais chez vous sur votre NIC physique 'hw' devrait fonctionner
Vous pouvez également essayer de bloquer l'ARP
Toujours en essayant les options du tableau ci dessus.
PS: sinon je vois que vous maniez plutôt bien bash donc j'en profite pour faire un peu de pub: Je maintien une library BASH pour gérer les freebox depuis l'API FreeboxOS permettant d'utiliser les fonctionnalités de l'API comme de simples commandes shell dans votre terminal, exemple pour lister les fichiers sur le disque de la freebox (chez moi /FBX24T mais souvent /disque\040dur avec le nopm par défaut) :
Le projet est ici:
https://github.com/nbanb/fbx-delta-nba_bash_api.sh
Il y a la doc en ligne sur la page du projet github et aussi un wiki résumant les actions / configurations :
https://github.com/nbanb/fbx-delta-nba_bash_api.sh/wiki
Et ce wiki contient également 1 page 'quick start' en français ici:
https://github.com/nbanb/fbx-delta-nba_bash_api.sh/wiki#access-quick-start-documentation-in-french
(désolé des users peu à l'aise avec l'anglais me l'ont demandé)
Ça peut vous intéresser !
Cordialement
nbanba
Bonjour
Désolé pour ce second post mais à la relecture de votre réponse, je pensais à:
sudo bash -c 'echo "options r8169 rx_vlan=0 tx_vlan=0" >>/etc/modprobe.d/r8169.conf' sudo modprobe -r r8169 sudo modprobe r8169ethtool -k ne devrait pas pouvoir réactiver le support de vlan en faisant ça
Vous devriez voir toutes les options flag avec
Cordialement
nbanba
Bonjour nbanba, merci d'avoir creusé le sujet. Pas d'action sur le problème, ça ne semble pas possible, en tout cas avec mon interface Realtek.
« j'en profite pour faire un peu de pub: Je maintien une library BASH pour gérer les freebox depuis l'API FreeboxOS »
Vous faites bien de faire un peu de pub, on ne travaille pas pour rien :) Merci pour le lien. Vous trouverez certains de mes scripts ici https://forums.debian.net/viewtopic.php?t=151887 (apt-fly, schow-pkg, why-pkg). Actuellement il faut créer un compte pour y accéder en raison du comportement déraisonnable des bots AI qui saturent le site. Si vous n'utilisez pas Debian vous pourriez néanmoins trouver des choses qui pourraient vous intéresser dans les scripts. Si vous avez des questions ou des remarques, il y a un e-mail de contact en début des scripts.
Encore merci et bonne journée nbanba !
Bonjour
Merci pour votre retour !
La difficultée est d'attraper les trames arp en tout premier.
Si traffic control "queuing disciplines" n'y arrive pas malgré sa place d'action dans la stack netfilter:
https://fr.wikipedia.org/wiki/Netfilter#/media/Fichier%3ANetfilter-packet-flow.svg
Il ne reste plus qu'à écrire un petit hoock en C pour eBPF, et tester !
Sinon merci pour les scripts, en fait Debian et moi c'est une longue histoire, j'utilise Debian à titre personnel depuis potaeto et j'ai mon ordi pro sous Debian depuis2que je travaille…
Merci encore
PS: la lib bash contient plus de 115 fonctions dont plusieurs dizaines dites "frontend" utilisables comme de simples commandes dans un terminal. Dans certains cas comme l'upload de fichiers par websocket API (utilisant des pipes bidirectionnels), on arrive aux limites de bash. J'assure le support, n'hésitez pas à me solliciter si besoin.
Cordialement
nbanba