Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • État Nouveau
  • Pourcentage achevé
    0%
  • 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
  • Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
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

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 ;) ):

  • Test A) clientWifi → Livebox → serveurFilaire =⇒ ✅ requête ARP de 60 bytes (à l'arrivée sur le serveur, normal)
  • Test B) clientWifi → FreeboxPop → serveurFilaire =⇒ ❌ requête ARP de 64 bytes (+4 bytes vs normal)
  • Test C) clientFilaire → FreeboxPop → serveurFilaire =⇒ ✅ requête ARP de 60 bytes (normal)

Notes:

  • pendant les 3 tests A, B, C, je n’ai rien changé d’autres que la box ou le type de connexion (et le client & serveur restent les mêmes)
  • j'ai testé 2 clients dont le hardware+software sont totalement différents (macbook & pc linux) et 2 "serveurs" aussi différents (nas freebsd & pc windows)
  • ces machines marchent tout à fait correctement par ailleurs (cf le test avec la livebox par exemple)
  • j'ai testé sur les 3 ports ethernet de la Freebox, et même résultat
  • le problème se reproduit à chaque fois (ce n'est pas une bête instabilité wifi, le client wifi a un accès internet qui fonctionne parfaitement par exemple)

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/

nbanba a commenté le 03.03.2025 11:34

Bonjour

Je ne reproduis pas sur les Delta

192.168.100.62 est une VM Freebox :

$ ip address show enp0s3 scope 0
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d6:11:ad:5f:a9:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.62/24 brd 192.168.100.255 scope global noprefixroute enp0s3
       valid_lft forever preferred_lft forever
    inet6 fd00:100::10/128 scope global dynamic noprefixroute 
       valid_lft 538641sec preferred_lft 538641sec

et 192.168.100.55 est un client wifi :

$ nmcli device show wlp59s0 | grep -E 'IP4.ADDRESS\[1\]:.*|GENERAL.DEVICE:.*|GENERAL.TYPE:.*|GENERAL.HWADDR:.*'
GENERAL.DEVICE:                         wlp59s0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         60:F2:62:B6:93:1F
IP4.ADDRESS[1]:                         192.168.100.55/24

tcpdump:

$ sudo tcpdump -i enp0s3 -nn -vvve arp
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:13:59.953176 60:f2:62:b6:93:1f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.100.62 tell 192.168.100.55, length 28
12:13:59.953205 d6:11:ad:5f:a9:8e > 60:f2:62:b6:93:1f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.100.62 is-at d6:11:ad:5f:a9:8e, length 28

Un payload de 28, ça me semble correct en ethertype 0x0806

Cordialement
nbanba

nbanba a commenté le 03.03.2025 11:37

Bonjour

Est ce que ça ne serait pas "driver related" ?

Cordialement
nbanba

Est ce que ça ne serait pas "driver related" ?

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 ;)

nbanba a commenté le 03.03.2025 19:09

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

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche