- É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/
Bonjour
Je ne reproduis pas sur les Delta
192.168.100.62 est une VM Freebox :
et 192.168.100.55 est un client wifi :
tcpdump:
Un payload de 28, ça me semble correct en ethertype 0x0806
Cordialement
nbanba
Bonjour
Est ce que ça ne serait pas "driver related" ?
Cordialement
nbanba
Partiellement oui, car certains équipements (notamment le bridge de Freebsd) ne tolèrent pas bien cette trame ARP trop longue.
Mais attention, ce n'est pas le driver (coté client/serveur) qui crée le soucis, mais bien la Freebox, car:
Avec la freebox, j'ai testé 2 clients dont le hardware+software sont totalement différents (macbook & pc linux) et 2 "serveurs" différents aussi (nas freebsd & pc windows) ⇒ même problème dans tous les cas
De plus, j'ai fait un autre test: comparer quand c'est la freebox vs quand c'est la livebox (avec le même nas freebsd dans les 2 cas) ⇒ je ne vois le soucis qu'avec la FB.
Donc il y a vraiment un comportement buggé introduit par la freebox ;)
Bonjour
Il faudrait trouver la datasheet de l'asic de la box pour voir comment sont offload les trames 0x0806 (un header est peut être ajouté)
Idem côté software offloading au niveau du bridge nic lan/wifi… (Après le mieux serait d'avoir le code mais je ne pense pas que Free nous le transmette)
Cordialement
nbanba