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

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/

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

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

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