La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Installation fibre Free => Discussion démarrée par: florentriv le 27 novembre 2024 à 00:52:57
-
Bonjour,
J’ai un problème de connectivité interne dans mon LAN depuis que j’ai remplacé une livebox par une Freebox Pop.
Et j’aimerai de l’aide pour debugger svp, car je suis un peu perdu là…
Basiquement, on dirait que la Freebox ne fait pas correctement son rôle de switch/bridge (L2 donc) entre le wifi et les ports ethernet dans certains cas (cf ci-dessous).
Et cela semble notamment bloquer les (réponses) ARP, et donc tout le trafic IP.
Globalement, j’ai une Freebox et 3 machines qui entrent en jeu:
0) Freebox Pop (wifi 7) toute neuve
A) NAS (avec des containers, A2) branché par cable ethernet
B) Client “fixe” branché aussi => OK pour joindre le nas+container ✅
C) Client “mobile” en wifi => problème partiel pour joindre le container ❌
Comme visible sur le schéma global des flux (cf tests ICMP décrit plus tard)
- la plupart des flux marchent bien ✅, mais il y a un flux qui ne marche pas: depuis un client wifi (C) vers les container du NAS (A2) ❌
- Aucun composant n’est clairement défectueux, car ils ont tous au moins un flux qui fonctionne, le souci est donc une combinaison de facteurs (plus difficile à trouver)
- NB: mon réseau n’est pas plus compliqué que dessiné: pas de switch matériel en plus, juste le NAS + le container + clients branchés directement sur la freebox, un seul subnet, pas de VLAN, le seul aspect un peu “exotique” est l’usage des containers sur le NAS
NB: je vais ajouter plus d’infos dans les posts suivants
Est-ce que vous avez des idées à me suggérer pour résoudre ce soucis ?
Merci d’avance
-
Voici qq tests pratiques:
Liste des IPs/mac:- LAN: 192.168.8.0/24
- Freebox: 192.168.8.1
- [A] NAS: 192.168.8.11 (ip statique), 3c:ec:xx:xx:xx:4c
- [A1] NAS ipmi: 192.168.8.10 (ip statique): 3c:ec:xx:xx:xx:53
- [A2] Container : 192.168.8.14 (ip statique), 3e:ec:yy:yy:yy:b6
- [B ] Client fixe: 192.168.8.235 (dhcp), 38:c9:zz:zz:zz:3b
- [C ] Client wifi: 192.168.8.227 (dhcp), 14:10:zz:zz:zz:cb
Quelques tests d’ICMP:
Depuis le client wifi: KO ❌ (ex: macbook M1 en wifi 5ghz ax):
client-wifi$ ping -c 3 google.fr
PING google.fr (172.217.20.163): 56 data bytes
64 bytes from 172.217.20.163: icmp_seq=0 ttl=116 time=3.196 ms
64 bytes from 172.217.20.163: icmp_seq=1 ttl=116 time=6.190 ms
64 bytes from 172.217.20.163: icmp_seq=2 ttl=116 time=6.283 ms
--- google.fr ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.196/5.223/6.283/1.434 ms
client-wifi$ ping -c 3 192.168.8.11
PING 192.168.8.11 (192.168.8.11): 56 data bytes
64 bytes from 192.168.8.11: icmp_seq=0 ttl=64 time=6.771 ms
64 bytes from 192.168.8.11: icmp_seq=1 ttl=64 time=4.278 ms
64 bytes from 192.168.8.11: icmp_seq=2 ttl=64 time=4.055 ms
--- 192.168.8.11 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.055/5.035/6.771/1.231 ms
client-wifi$ ping -c 3 192.168.8.14
PING 192.168.8.14 (192.168.8.14): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
--- 192.168.8.14 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Depuis le client fixe: OK ✅ (ex: macbook + adaptateur ethernet)
client-fixe$ ping -c 3 192.168.8.11
PING 192.168.8.11 (192.168.8.11): 56 data bytes
64 bytes from 192.168.8.11: icmp_seq=0 ttl=64 time=0.975 ms
64 bytes from 192.168.8.11: icmp_seq=1 ttl=64 time=0.935 ms
64 bytes from 192.168.8.11: icmp_seq=2 ttl=64 time=0.927 ms
--- 192.168.8.11 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.927/0.946/0.975/0.021 ms
client-fixe$ ping -c 3 192.168.8.14
PING 192.168.8.14 (192.168.8.14): 56 data bytes
64 bytes from 192.168.8.14: icmp_seq=0 ttl=64 time=0.885 ms
64 bytes from 192.168.8.14: icmp_seq=1 ttl=64 time=0.908 ms
64 bytes from 192.168.8.14: icmp_seq=2 ttl=64 time=0.964 ms
--- 192.168.8.14 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.885/0.919/0.964/0.033 ms
Etat ARP (après le ping)
client-wifi$ arp -an
[...]
? (192.168.8.11) at 3c:ec:xx:xx:xx:4c on en0 ifscope [ethernet]
? (192.168.8.14) at (incomplete) on en0 ifscope [ethernet]
nas-container-www$ arp -an
[...]
? (192.168.8.11) at 3c:ec:xx:xx:xx:4c on epair0b expires in 1177 seconds [ethernet]
? (192.168.8.227) at 14:10:zz:zz:zz:cb on epair0b expires in 1190 seconds [ethernet]
nas-container-www$ ifconfig epair0b
epair0b: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 3e:ec:yy:yy:yy:b6
inet 192.168.8.14 netmask 0xffffff00 broadcast 192.168.8.255
# Le cas qui marche:
client-fixe$ arp -an
[...]
? (192.168.8.11) at 3c:ec:xx:xx:xx:4c on en3 ifscope [ethernet]
? (192.168.8.14) at 3e:ec:yy:yy:yy:b6 on en3 ifscope [ethernet]
Traffic ARP (pendant le ping KO depuis client-mobile vers container, vu depuis 2 endroits différents en même temps):
client-wifi$ sudo tcpdump -n arp
00:18:07.142069 ARP, Request who-has 192.168.8.14 tell 192.168.8.227, length 28
00:18:08.142509 ARP, Request who-has 192.168.8.14 tell 192.168.8.227, length 28
00:18:09.145340 ARP, Request who-has 192.168.8.14 tell 192.168.8.227, length 28
nas# tcpdump -n arp
00:18:07.126065 ARP, Request who-has 192.168.8.14 tell 192.168.8.227, length 50
00:18:07.126112 ARP, Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
00:18:08.203927 ARP, Request who-has 192.168.8.14 tell 192.168.8.227, length 50
00:18:08.204054 ARP, Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
00:18:09.146063 ARP, Request who-has 192.168.8.14 tell 192.168.8.227, length 50
00:18:09.146126 ARP, Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
-
Mon analyse et infos importantes:
- Il ne s’agit pas d’une “simple” instabilité du wifi (cf test du ping google très stable, et test refait sur plusieurs machines), ca semble plus profond
- Au début (et plus maintenant, sans que je sache pourquoi), le soucis disparaissait *temporairement* quand je redémarrais le container sur le NAS => un cache ARP ou de bridge qui se remplit/vide pas correctement ?
- Lors du test KO (cf détails ARP), le client wifi (C) ne découvre pas l’adresse mac du container (A2), cf le “incomplete”, mais le container a bien obtenu la mac du client wifi (cf: mac avec “zz”) => traffic coupé de façon asymétrique ?
- Le même setup fonctionnait normalement quand j’avais une livebox au lieu de la freebox, avec les mêmes config de réseau partout (client, nas, container). Donc j’ai tendance à penser que le souci vient de la Freebox, mais c’est aussi potentiellement plus compliqué (combinaison d’un truc pas standard du côté de mon NAS+container + un comportement différent de la FB vs la livebox)
Différentes choses que j'ai déjà testées:
- différents hardware & OS clients pour le client en wifi (2 macbooks, 2 androids, 1 mini-pc linux) => tous KO pareil
- avec le wifi 2ghz vs 5ghz (cf 2 ssids différents configurés sur la FB) => KO pareil
- simplifier un peu en éteignant les autres containers et en garder qu’un seul => KO pareil
- redémarrer la freebox, le nas et les client wifi => KO pareil
- changer le NAS de port sur la freebox, j’ai testé les 3 => KO pareil
- le blocage semble être au niveau ARP, qui sont des trames de petite taille, donc j’élimine les soucis de MTU
=> le critère différenciant est vraiment: client en wifi => ❌, alors que en ethernet => ✅
Infos supplémentaires sur le NAS:
- Hardware: un serveur “fait maison”: une carte mère supermicro avec IPMI (sur le port partagé qui fait tout)
- Software: TrueNAS Core (FreeBSD), et les containers sont des jails FreeBSD
- Réseau: une interface “vnet” (une interface virtuelle avec une mac dédiée) par container et un bridge virtuel global (bridge0 avec dedans: igb0 vers freebox et vnet0.x pour le container)
- Firewall: je n’ai mis aucune règle sur le NAS
La freebox:
- Firmware: 4.8.16
- Matériel : Freebox v8 (r1)
- FTTH Pon, ip v4 “full stack”
- Mode: routeur classique
-
- [A] NAS: 192.168.8.11 (ip statique), 3c:ec:xx:xx:xx:4c
- [A2] Container : 192.168.8.14 (ip statique), 3e:ec:yy:yy:yy:b6
C'est comme ton système de container (docker ?) ?, pourquoi tu as une ip différente (.14) de l'hote (.11) et surtout 2 MAC différentes ?!
En général un container hérite des ip de l'hote et c'est juste des ports qu'on lui assigne (sauf configuration plus complexe ou autre systeme de container (lxc?))).
La doit y a voir un systeme de proxy arp pour faire porter ta 2eme IP sur la même interface physique que la 1ere (ou alors c'est du macvlan?) , ca peut être l'origine du souci avec les clients wifi si la freebox filtre (par sécurité) des réponses arp qui ne viennent pas de la bonne mac: (c'est une hypothese).
-
C'est comme ton système de container (docker ?) ?, pourquoi tu as une ip différente (.14) de l'hote (.11) et surtout 2 MAC différentes ?!
Ce sont des jails Freebsd, avec chacune une interface réseau dédiée (vnet) + un bridge.
cf mes notes "Infos supplémentaires sur le NAS" dans mon post précédent.
J'ai fait ce choix de vnet, car une des jails contient un VPN wireguard qui nécessite une interface dédiée pour le routage+nat du trafic des clients vpn.
Mais cette jail est éteinte lors des tests (pour simplifier) et le soucis est toujours présent sur la jail "www" qui est bcp plus basique, et aussi: tout fonctionnait bien avant le remplacement Livebox->Freebox.
La doit y a voir un systeme de proxy arp pour faire porter ta 2eme IP sur la même interface physique que la 1ere (ou alors c'est du macvlan?) , ca peut être l'origine du souci avec les clients wifi si la freebox filtre (par sécurité) des réponses arp qui ne viennent pas de la bonne mac: (c'est une hypothese).
Il ne devrait pas y avoir de proxy arp en théorie (sauf s'il a été mis par TrueNas sans que je le sache).
En pratique, la mac du container (telle que vue par le client fixe qui marche) est bien celle portée par l'interface dédiée du container, donc il ne semble pas y avoir de proxy-arp, mais vraiment juste un bridge L2 simple.
D'ailleurs, la freebox voit plusieurs "équipements" sur le port ether du NAS: chacun avec une mac dédiée, cf screenshot à la fin.
Donc, vu de la freebox, le NAS devrait se comporter comme un switch simple qui agrège plusieurs devices.
-
ah j'avais zappé la section "Infos supplémentaires sur le NAS" ;)
hum c'est donc comme si tu avais un switch (S) en cascade sur le freebox avec derriere le nas et ses containers.
Au début (et plus maintenant, sans que je sache pourquoi), le soucis disparaissait *temporairement* quand je redémarrais le container sur le NAS => un cache ARP ou de bridge qui se remplit/vide pas correctement ?
il faut regarder si possible la table des @ mac apprise par ton bridge S:
ifconfig nomdubridge addr
et il faudrait détailler plus ta capture des reply arp sur le nas :
00:18:07.126112 ARP, Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
si ca se trouve ce reply ne sort pas de S ?
et la comparer avec la capture d'un reply dans le cas du client fixe pour voir s'il y a une différence susceptible d'etre filtré par la freebox.
-
Merci pour ton aide :)
hum c'est donc comme si tu avais un switch (S) en cascade sur le freebox avec derriere le nas et ses containers.
C'est exactement ça !
il faut regarder si possible la table des @ mac apprise par ton bridge S:
Bonne idée, voici le résultat:
### Juste après le client wifi ❌
nashome# ifconfig bridge0 addr
14:10:zz:zz:zz:cb Vlan1 igb0 1200 flags=0<> # client wifi
38:c9:zz:zz:zz:3b Vlan1 igb0 1151 flags=0<> # client fixe
3c:ec:xx:xx:xx:53 Vlan1 igb0 1193 flags=0<> # nashome-ipmi
3e:ec:yy:yy:yy:b6 Vlan1 vnet0.7 1178 flags=0<> # container
[...]
### Juste après le client filaire ✅ :
nashome# ifconfig bridge0 addr
14:10:zz:zz:zz:cb Vlan1 igb0 21 flags=0<> # client wifi
38:c9:zz:zz:zz:3b Vlan1 igb0 1200 flags=0<> # client fixe
3c:ec:xx:xx:xx:53 Vlan1 igb0 1177 flags=0<> # nashome-ipmi
3e:ec:yy:yy:yy:b6 Vlan1 vnet0.7 1184 flags=0<> # container
[...]
=> tout semble ok dans les 2 cas: les macs des clients & du container sont connus et sur le bon port
et il faudrait détailler plus ta capture des reply arp sur le nas :
si ca se trouve ce reply ne sort pas de S ?
D'après les tcpdump ci-dessous, la réponse arp sort bien du bridge S, car on la voit sur un `tcpdump -i igb0` (igb0 étant l'interface physique du NAS, donc "après" le bridge dans le sens "container->wifi")
et la comparer avec la capture d'un reply dans le cas du client fixe pour voir s'il y a une différence susceptible d'etre filtré par la freebox.
Effectivement, c'est une idée intéressante ! Voici ce que j'ai pu observer:
NB: le même client pour les 2 tests ici (un macbook), histoire de minimiser les différentes autres que "wifi vs filaire"
### Client wifi ❌:
nashome# tcpdump -i igb0 -nn -vvve arp
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:12:02.882851 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
21:12:02.882961 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 46: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
### Client filaire ✅ :
nashome# tcpdump -i igb0 -nn -vvve arp
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:12:58.783977 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.235, length 46
21:12:58.784013 3e:ec:yy:yy:yy:b6 > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28
=> les tailles (à la fois des requêtes et des réponses) sont un peu différentes entre wifi & filaire :o,
Je ne sais pas encore pourquoi, ni si c'est important pour mon problème.
Je vois juste que c'est différent.
-
effectivement usuellement c'est taille 28 la réponse. on dirait que tu as +4 (en request aussi, 50 au lieu de 46), ce qui correspond peut-être a un vlan en plus (ou pas ...) ?
eventuellement sauvegarde tes captures et regarde dans Wireshark en détail complet.
mais c'est curieux
-
ps: as-tu essayé avec un autre client wifi qu'un produit Apple ?
-
effectivement usuellement c'est taille 28 la réponse. on dirait que tu as +4 (en request aussi, 50 au lieu de 46), ce qui correspond peut-être a un vlan en plus (ou pas ...) ?
eventuellement sauvegarde tes captures et regarde dans Wireshark en détail complet.
Je n'ai pas de vlan (cf la freebox qui ne permets d'en configurer) et le NAS ne devrait normalement pas ajouter (sur le bridge).
Mais je vais garder l'idée en tête et voir ce que je peux creuser avec wireshark, car la différence de 4 octets est effectivement étrange.
ps: as-tu essayé avec un autre client wifi qu'un produit Apple ?
Voici les tcpdump (toujours vus depuis le NAS) lorsque c'est une autre machine qui ping:
(ici un mini-PC zotac avec libreelec->linux, donc hard+soft très différent d'un macbook)
### Client wifi ❌:
nashome# tcpdump -i igb0 -nn -vvve arp
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:58:57.342820 74:13:zz:zz:zz:c9 > 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.158, length 50
20:58:57.342924 3e:ec:yy:yy:yy:b6 > 74:13:zz:zz:zz:c9, ethertype ARP (0x0806), length 46: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
### Client filaire ✅ :
nashome# tcpdump -i igb0 -nn -vvve arp
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:50:41.922798 00:01:zz:zz:zz:44 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.181, length 46
20:50:41.922912 3e:ec:yy:yy:yy:b6 > 00:01:zz:zz:zz:44, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28
=> même résultat qu'avec le macbook: une différence de taille de 4 octets ???
-
Nouveau test qui montre plus précisément le soucis (sans avoir besoin de relire avant)
Je vais comparer 3 cas:
- Client wifi sur Livebox => ping vers container OK ✅
- Client wifi sur Freebox => ping vers container KO ❌
- Client filaire sur Freebox => ping vers container OK ✅
NB: pour le 1er test, j'ai juste remis la Livebox à la place de la freebox (donc branché le NAS dessus, et changé de réseau wifi sur le client) et rien changé d'autre (les 2 box ont le même subnet pour le LAN: 192.168.8.1/24, et c'est bien le même client de test partout: mon macbook wifi ou avec adapteur ethernet, et je fais un: `sudo arp -d 192.168.8.14; ping -c 1 192.168.8.14`)
Et cette fois-ci, je regarde les tcpdump des 2 cotés: à la fois client & NAS (pour voir la requête ARP avant et après la box).
# Client wifi sur Livebox (✅) :
macbook$ sudo tcpdump -i en0 -nn -vvve arp
20:59:28.910864 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.103, length 28
20:59:28.914382 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 46
nashome# tcpdump -i igb0 -nn -vvve arp
20:59:28.950654 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.103, length 46
20:59:28.950743 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28
### Client wifi sur Freebox (❌):
macbook$ sudo tcpdump -i en0 -nn -vvve arp
21:01:59.338379 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 28
[pas de réponse]
nashome# 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
21:01:59.377490 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 46: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32
### Client filaire sur Freebox (✅) :
macbook$ sudo tcpdump -i en3 -nn -vvve arp
21:05:06.928044 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.235, length 28
21:05:06.928605 3e:ec:yy:yy:yy:b6 > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 46
nashome# tcpdump -i igb0 -nn -vvve arp
21:05:06.960290 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.235, length 46
21:05:06.960415 3e:ec:yy:yy:yy:b6 > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28
=> la requête ARP fait bien la même taille au départ (observée sur le macbook) dans les trois cas, donc ok jusque là (le client me fait rien de mal) ✅
=> mais elle arrive "plus grosse" (+4 octets) sur le NAS uniquement dans le cas wifi+Freebox ❌, alors que ok dans les 2 autres cas
=> bug sur la freebox en fonction de la mac de destination quand c'est en wifi ?
-
Bonsoir,
l'analyse des trames trop longues vues sur le NAS pourrait éclairer : tcpdump -i en3 -e -w fichier de_trace.pcap, à passer ensuite dans Wireshark pour afficher les détails.
-
oui il manque le détail de ces 4 octets. Wireshark devrait nous dire a quoi ils correspondent.
-
Bonsoir,
l'analyse des trames trop longues vues sur le NAS pourrait éclairer : tcpdump -i en3 -e -w fichier de_trace.pcap, à passer ensuite dans Wireshark pour afficher les détails.
Heu oui, j'avais mis de coté ce test là, désolé.
Je viens de le faire, avec tcpdump sur le nas (donc "après" la freebox pour les requêtes ARP):
nashome# tcpdump -i igb0 -e -w freebox-filaire.pcap arp
nashome# tcpdump -i igb0 -e -w freebox-wifi.pcap arp
Voici une comparison des requêtes ARP dans wireshark:
=> les 4 octets supplémentaires viennent du FCS :o
EDIT: et je rajoute la comparaison des réponses
-
Heuu, si je lis bien, tu nous donnes les screenshots de la trame ARP Request, qui génère bien une réponse ARP reply de la part de ton container en .14. donc c'est normal a priori.
En fait, si le FCS de la réponse est invalide, le paquet pourait être droppé par le client s'il tient compte du champ FCS puisqu'il semble y en avoir un dans la réponse ARP également.
Dans ce cas : paquet ARP de réponse ARP droppé => pas de résolution ARP => ça ne fonctionne pas.
-
Plusieurs pistes:
Ca peut-être un souci de driver.
il y a un flag de config dans les drivers pour remonter ou pas le FCS.
https://man.freebsd.org/cgi/man.cgi?query=igb&sektion=4&manpath=freebsd-release-ports#end
Sur freebsd avec ton driver, dixit la doc c'est:
hw.em.disable_crc_stripping
regarde sa valeur et essaie de l'inverser pour voir.
par ailleurs ce n'est pas "naturel" de porter l'ip sur l'interface lan quand celle-ci est aussi dans un bridge. En général on met l'ip sur le bridge lui-meme. C'est ce qu'on fait dans le monde Linux et c'est ce qui est aussi indiqué dans la doc de freebsd:
https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bridging
If the bridge host needs an IP address, set it on the bridge interface, not on the member interfaces.
Hors je vois que ton inferface lan (igb0) porte l'IP (donc le mécanisme arp dessus) et le bridge (bridge0 ) n'en a pas (ou alors j'ai mal lu dans ce cas oublions).
Sinon ce n'est pas cela, il faudrait voir si sans bridge, juste l'interface lan ca fait la même chose (on sait que ca fonctionne mais il y a t'il +4 octet aussi en réception et en émission)
Ainsi que sur une autre machine non freebsd sur le lan (est-ce qu'une capture sur un autre pc non freebsb voit aussi +4 octet venant des clients wifi et si oui est que la réponse a +4 aussi). L'idée est de voir si c'est Freebsd qui pose probleme ou un bridge sur Freebsd.
-
Je n'ai pas eu bcp de temps pour ce soucis récemment, mais voici enfin des réponses:
Heuu, si je lis bien, tu nous donnes les screenshots de la trame ARP Request, qui génère bien une réponse ARP reply de la part de ton container en .14. donc c'est normal a priori.
En fait, si le FCS de la réponse est invalide, le paquet pourait être droppé par le client s'il tient compte du champ FCS puisqu'il semble y en avoir un dans la réponse ARP également.
Dans ce cas : paquet ARP de réponse ARP droppé => pas de résolution ARP => ça ne fonctionne pas.
Je viens d'éditer mon message précédent, et j'ai rajouté une comparaison de la réponse ARP (fait sur le même dump qu'avant, cf les dates).
On n'y voit du tout le FCS (dans aucun des cas), mais un trailer de 4 octets dans la réponse au client wifi.
Donc je ne sais pas trop quoi conclure.
il y a un flag de config dans les drivers pour remonter ou pas le FCS.
https://man.freebsd.org/cgi/man.cgi?query=igb&sektion=4&manpath=freebsd-release-ports#end
Sur freebsd avec ton driver, dixit la doc c'est: hw.em.disable_crc_stripping
Par défaut, ce paramètre est à 0 chez moi. Je l'ai mis à 1 (via une config + reboot + confirmé qu'il était vraiment à 1).
Et le soucis est toujours présent :(
par ailleurs ce n'est pas "naturel" de porter l'ip sur l'interface lan quand celle-ci est aussi dans un bridge. En général on met l'ip sur le bridge lui-meme. C'est ce qu'on fait dans le monde Linux et c'est ce qui est aussi indiqué dans la doc de freebsd:
Je confirme: l'ip du NAS est montée sur l'interface physique (igb0), et pas sur le bridge comme cela devrait l'être.
Malheureusement, c'est TrueNas qui gère ça, et je n'ai pas (encore?) trouvé comme lui dire de monter l'IP au bon endroit.
Je garde l'idée en tête.
Sinon ce n'est pas cela, il faudrait voir si sans bridge, juste l'interface lan ca fait la même chose (on sait que ca fonctionne mais il y a t'il +4 octet aussi en réception et en émission)
Ainsi que sur une autre machine non freebsd sur le lan (est-ce qu'une capture sur un autre pc non freebsb voit aussi +4 octet venant des clients wifi et si oui est que la réponse a +4 aussi). L'idée est de voir si c'est Freebsd qui pose probleme ou un bridge sur Freebsd.
Le NAS sans le bridge: je ne pense pas sur de pouvoir le faire facilement, car le bridge est géré par TrueNAS.
Par contre, je peux observer la communication avec le NAS lui-même (ce qui marche tout le temps, même en wifi), donc:
- client wifi & filaire: le même macbook que d'habitude
- serveur: le même NAS, mais je ping l'ip du host du nas directement (ip en .11 qui est sur igb0), pas le container
### Client wifi (✅):
nashome# tcpdump -i igb0 -nn -vvve arp
21:41:30.416103 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.11 tell 192.168.8.227, length 50
21:41:30.416141 3c:ec:xx:xx:xx:4c > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.11 is-at 3c:ec:xx:xx:xx:4c, length 28
### Client filaire (✅) :
nashome# tcpdump -i igb0 -nn -vvve arp
21:46:23.433610 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.11 tell 192.168.8.235, length 46
21:46:23.433650 3c:ec:xx:xx:xx:4c > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.11 is-at 3c:ec:xx:xx:xx:4c, length 28
=> les requêtes ARP (depuis wifi) arrivent "grosses" sur le NAS aussi, mais les réponses sont normales
Et l'autre test que tu propose:
- client wifi & filaire: le macbook habituel
- "serveur": un pc sous windows 10 (chipset Realtek 2.5Gb, donc hard+soft différent du nas) branché directement sur la freebox (comme le NAS)
Un wireshark sur le pc (coté "serveur" donc) montre exactement les mêmes tailles que juste au dessus, notamment client en wifi: requête 64 bytes, réponse: 42 bytes.
Et on retrouve le FCS de 4 bytes (00000000) "unverified" sur la requête, comme quand on ping le container (et que c'est KO).
Par contre, la réponse est "normale".
J'ai essayé de résumé les tailles + infos diverses dans ce comparatif:
-
En contournement, mettre une entrée ARP statique sur le(s) client(s) vers le container ?
Si, bien sûr, ses adresses MAC et IP ne bougent pas et que ce ne soit pas une charge importante d'administration des clients. Mais tu l'as peut-être déjà envisagé.
-
En contournement, mettre une entrée ARP statique sur le(s) client(s) vers le container ?
Si, bien sûr, ses adresses MAC et IP ne bougent pas et que ce ne soit pas une charge importante d'administration des clients. Mais tu l'as peut-être déjà envisagé.
Je ne suis pas assez désespéré pour vraiment envisager ça ;D
Mais pour comprendre, j'ai testé vite fait, et ca semble marcher: j'arrive à pinger mon container.
Donc j'imagine que le soucis est assez spécifique aux trames ARP.
-
Ces derniers jours, j'ai creusé ces questions là:
Plusieurs pistes:
Ca peut-être un souci de driver.
[...]
L'idée est de voir si c'est Freebsd qui pose problème ou un bridge sur Freebsd.
Et pour ça, j'ai d'abord cherché & trouvé comment monter l'ip sur le bridge (et plus sur l'interface physique) dans TrueNAS.
Puis, j'ai réalisé pas mal de tests pour comparer, notamment:
- j'ai mis l'ip sur le bridge ou sur l'interface physique
- j'ai testé de pinger le NAS et le container (pour voir si tous les ports du bridge sont symétriques)
- j'ai testé de changer le hardware (carte réseau), notamment en utilisant: un adapteur eth usb et une carte eth PCI-Express, histoire d'utiliser un driver différent
- et j'ai comparer à chaque fois depuis un client wifi et un client filaire (pour avoir une référence)
Voici mes résultats sur le tableau joint.
Et mes conclusions:
- => les 2 ports igb0&1 se comportement pareil, donc pas de bug lié à l’ipmi shared
- => le bug se produit lorsque le traffic passe par le bridge (cf: ip du NAS sur le bridge et container KO en même temps) et pas quand le traffic arrive que sur l’interface physique (ip du NAS sur igb0), donc bug autour du bridge ?
- => le bug se produit avec les interfaces physiques igb0&1, et pas avec ue0 ou em0 qui semblent tolérer bcp mieux les trames plus larges (+4 ou +8 bytes) sans soucis, donc bug spécifique au driver igb ?
Et la conclusion (dernière ligne):
=> avec la carte PCI-Express (em0), j'ai tout qui fonctionne comme je veux (sauf l'IPMI) :)
-
Intéressant. On s'oriente donc vers un bug du driver igb en présence d'un bridge.
il faudrait voir ici: https://bugs.freebsd.org/bugzilla/ si y'a quelque chose de documenter ou ouvrir une nouvelle "issue.
a moins qu'on considere que la faute est coté Apple ... ;D
-
Intéressant. On s'oriente donc vers un bug du driver igb en présence d'un bridge.
Yep, tout à fait. Avec une précision importante:
D'après mes nombreux tests, le soucis se produit lorsqu'on cumule 2 facteurs (ce qui explique que je sois potentiellement le seul ou des seuls à être impacté):
- Un bridge FreeBSD avec driver igb
- et un client wifi connecté sur une Freebox Pop
Et la 2ème condition est importante (cf: l'absence de soucis avec mon ancienne config: Livebox + la même config de bridge freebsd igb) !!!
D'ou le bug que j'ai créé chez Free: https://dev.freebox.fr/bugs/task/39919 (en isolant le soucis des +4bytes en wifi seulement, sans parler de freebsd). NB: pas encore de réponse.
il faudrait voir ici: https://bugs.freebsd.org/bugzilla/ si y'a quelque chose de documenter ou ouvrir une nouvelle "issue.
Je n'ai presque pas cherché là bas, car je voulais d'abord bien cerner le soucis qui était assez flou au début.
Et je ne sais pas encore si je vais créer une issue, car j'ai déjà passé bcp de temps sur ce soucis et j'ai peur de ne pas savoir montrer comment reproduire le soucis clairement (cf le bug qui est trigger par les +4bytes de la freebox que l'on ne comprends pas) :-\
a moins qu'on considere que la faute est coté Apple ... ;D
Non, rien de spécifique Apple dans mon soucis en fait, j'ai déjà testé et reproduit le soucis avec aucun matériel ni software Apple.
cf: https://lafibre.info/installation-free/probleme-partiel-de-switching-sur-le-lan-freebox-pop-containers-freebsd/msg1096824/#msg1096824
En tout cas, un grand merci pour ton aide (et celles des autres), cela m'a motivé et bien aidé à continuer le debug 8)