Alors le paquet magique (envoyé toutes les 3 minutes) semble bien fonctionner…
À part quelques brèves émissions APIPA irrégulières pendant l'incident DHCPv6, je ne vois plus de fuites de type APIPA venant de K-Box.
Maintenant, pourquoi le fait d'envoyer un ARP Request en broadcast depuis 00:26:86:00:00:00 résout ce problème ? C'est un mystère…
Je soupçonne que cela provoque une réponse locale au sein de la K-Box qui croit recevoir une demande de son SoC Quantenna (réponse qui elle ne fuit pas mais remet des choses en place). C'est comme si le SoC Quantenna de ces K-Box envoyait les ARP Request au mauvais endroit ou de mauvaises requêtes, et que celui que j'envoie arrive lui au bon endroit.
Probablement donc une histoire de routage interne dans la K-Box… (le problème avec ebtables)
Cela règle-t'il la fuite en soi ou simplement l'émission de paquets APIPA… je ne sais pas.
Ce paquet ne fait rien par rapport aux fuites mDNS que je vois : je vois toujours les fuites mDNS de clients avec K-Box (des fuites venant de leur LAN, les mêmes que celles reportées il y a quelques mois…)
Ici, K-Box qui fuie ou LAN mal conçu ? Pareil, je ne sais pas…
Le paquet magique « stop » pour APIPA qui semble donc arrêter toutes les fuites APIPA venant de K-Box dans la collecte :
ff ff ff ff ff ff
00 26 86 00 00 00
08 06
00 01 08 00 06 04
00 01
00 26 86 00 00 00
A9 FE 01 03
00 00 00 00 00 00
A9 FE 01 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Après cela, hors K-Box, il y a quand même :
– 5 appareils Synology qui fuient en mDNS sur le WAN
(à priori des routeurs…)
– Un appareil
Niko NV qui n'est à priori pas un routeur, donc ça vient soit d'un LAN mal conçu ou qui fuit (K-Box fuyant ?)
– Un appareil Asus
– Un appareil Belkin avec une importante fuite permanente mDNS (1,7 paquets par seconde)
– et ce mystérieux appareil 00:11:33:55:77:cc (et :bb)
K-Net