- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie LAN
- Assignée à Personne
- Système d'exploitation Freebox Server V8 (Pop)
- Sévérité Moyenne
- Priorité Très Basse
- Basée sur la version 4.8.17.1
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
1
- florentriv (20/12/2024)
- Privée
Ouverte par florentriv - 20/12/2024
Dernière modification par florentriv - 20/12/2024
FS#39919 - Trames ARP "rallongés" (+4 bytes) par le bridge wifi->ethernet de Freebox Pop (wifi7)
Bonjour,
J’ai repéré un comportement très étrange sur le bridge réalisé par Freebox entre un client wifi et une cible filaire.
(donc sur un traffic uniquement à l’intérieur du LAN de la Freebox)
Voici la situation simple pour reproduire:
1) Un client qqconque en wifi connecté sur la Freebox Pop (F-GW08D)
2) Une machine “serveur” qqconque branchée en ethernet (directement sur la freebox)
Il suffit de ping le “serveur” depuis le client wifi.
Alors, les requêtes ARP arrivent bien sur le serveur, mais avec une longueur anormalement grande, cf:
clientwifi$ ping 192.168.8.14 PING 192.168.8.14 (192.168.8.14): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down Request timeout for icmp_seq 0 serveur# tcpdump -i igb0 -nn -vvve arp 21:01:59.377399 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 50
⇒ 64 bytes ici (vs 60 bytes normalement)
Une analyse avec wireshark (toujours du coté du serveur) montre un FCS ou un padding (suivant l’heuristique d’analyse choisi) anormal de 4 bytes: 0×00000000 qui semble ajouté sur la couche ethernet de toutes les requêtes ARP qui sont passés par la Freebox en wifi.
Ma conclusion:
⇒ le bridge de la freebox “modifie” (+4 bytes) les trames ARP lorsqu’elles transitent depuis le coté wifi vers les ports ethernet, ce qui les rends non standard
⇒ bug de la freebox ?
Important: le mot “bridge” que j’utilise ici n’a rien à voir avec le fameux “mode bridge”, car je parle du “switch” (layer 2) fait par la freebox entre les différentes partie du LAN (wifi & ports ether).
NB: ma Freebox est en mode “routeur” comme par défaut, et il n’y aucun routeur ou autre équipement “avancé” supplémentaire.
Merci d’avance
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
Voici quelques détails supplémentaires:
Une comparaison rapide (désolé pour le 1er cas, mais je viens d'Orange et je n'avais pas le problème chez eux ;) ):
Notes:
Impact pour moi:
Certains équipements (notamment le bridge de Freebsd) ne tolèrent pas bien cette trame ARP trop longue, et la réponse ARP est mal formée, ce qui empêchent mes clients wifi de se connecter à ces équipements :(
Et donc m'empêche d'utiliser le wifi de la box (pourtant de bonne qualité).
NB: la plupart des clients semble l'accepter sans soucis, donc invisible la majorité du temps.
Si vous êtes vraiment curieux de (beaucoup) plus de détails/contexte, j'ai commencé le debug de mon soucis (mais c'était plus complexe au début) sur ce forum:
https://lafibre.info/installation-free/probleme-partiel-de-switching-sur-le-lan-freebox-pop-containers-freebsd/