oui il manque le détail de ces 4 octets. Wireshark devrait nous dire a quoi ils correspondent.

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 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é.

Je ne suis pas assez désespéré pour vraiment envisager ça 
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.

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 ...