Tu ne peux pas filtrer que sur une adresse MAC ?

Merci au fait sur ta vidéo de plombier. J'ai passé bien 30min à faire de la plomberie virtuelle sur Youtube après   

Voilà, j'ai maintenant un cache de 24h de tous les paquets de type fuite APIPA et mDNS (128 premiers octets).
Cela ne prendra pas plus de 30 Mo, et me donnera la possibilité d'analyser les paquets intéressants après-coup 

Très bien, mais rien ne prouve que ce soit ce type de paquets qui provoque le déclenchement ou l'arrêt des "fuites". La seule certitude à mon avis, c'est qu'il s'agit de broadcast ou de multicast.

Alors si, ou en tous cas, le signal envoyé par 00:26:86:00:00:00 était définitivement de type APIPA.

Je ne mesure et reporte dans la chronologie que les signaux APIPA, mDNS et les spams DHCPv6.

Je ne cherchais pas particulièrement de signaux « stop » et ne pensais même pas qu'il y en avait (on pensait qu'il fallait nécessairement faire un reset ou avoir un accès SSH pour arrêter), mais le signal APIPA envoyé par 00:26:86:00:00:00 semble être ce qui a arrêté simultanément la fuite de deux K-Box (pas la troisième cependant), ce qui laisse supposer qu'il est possible de stopper les fuites avec un signal APIPA spécifique.

Maintenant que je garde une trace des paquets, on verra bien… Il faut attendre que ça se reproduise et espérer aussi que le paquet ne dépasse pas 128 octets (à priori non).

Bizarre quand même, je pensais que ce qui pouvait déclencher les bugs K-Box était plutôt lié aux vulnérabilités des SoC Realtek. Ca paraît surprenant qu'un paquet type APIPA puisse remettre en place une situation anormale.
Bon, à voir si tu parviens à capturer des paquets "utiles", puis à les balancer sur le réseau ensuite.

Je soupçonne un problème double…

1) L'Icotera a un problème de fuite (SoC Realtek),
2) La partie Wifi 5G de l'Icotera (SoC Quantenna) serait à l'origine des paquets APIPA (qui devraient être interne à l'Icotera qui a deux OS).

Dans cette hypothèse, les paquets APIPA ne sont visibles que si 1 et 2 sont vrais (sans compter l'étanchéité Covage qui est un troisième condition).
Donc il y a probablement plus d'Icotera qui fuient, mais on ne les voit pas, car le Wifi 5G est activé (ou désactivé, je ne sais pas dans quelle mesure les paquets APIPA sont émis), et parce qu'il n'y a pas de paquets mDNS qui circulent…
Présenté autrement, on ne peut détecter les Icotera qui fuient que lorsque des paquets mDNS ou APIPA circulent dans le LAN (ou dans l'Icotera elle-même entre les deux OS).

Bref, un tuyau peut être percé, mais sans eau qui circule dedans, on ne détecte pas la fuite…
C'est pour cela je pense qu'il y a des clients qui n'ont pas de fuite visible depuis l'extérieur, mais sont affectés (car fuite dans les deux sens) ; ceux là ont la fuite mais n'émettent pas d'APIPA ou de mDNS.

Donc le paquet APIPA « stop » ne stopperait pas le problème de fuite Realtek, mais stopperait les requêtes ARP APIPA. Je soupçonne même ce fameux paquet « stop » d'être de type ARP Reply, et donc de satisfaire la demande ARP Request des box qui fuient ces paquets APIPA (les fuites APIPA sont des ARP Request). Bref on ne colmate pas la fuite, mais on arrête l'émission des paquets APIPA au niveau de la partie Quantenna de l'Icotera.

Je soupçonne la fuite des K-Box d'être totale (broadcast, multicast, unicast)… Ce qu'on voit sur la collecte est simplement ce que Covage ne bloque pas entre les clients.

D'ailleurs, il est fort probable que toutes les autres fuites non K-Box viennent des LANs derrière des K-Box qui fuient (mais n'émettent pas en APIPA…)

Bon, ben j'ai pu fabriquer et envoyer un ARP Reply… Résultat, ça a re-déclenché les 2 fuites APIPA qui étaient arrêtées… Et 00:26:86:00:00:00 répond à chaque fois avec un ARP Request…

La bonne nouvelle, est que j'arrive à envoyer des paquets que les K-Box reçoivent et que j'obtiens des réactions (pas encore celles voulues).
Reste à trouver le bon paquet à envoyer pour stopper les fuites APIPA.

EDIT :

Au passage, 00:26:86:00:00:00 c'est une MAC Quantenna !

Heuu tu envoies un ARP reply en broadcast? Sinon, vers quelle MAC ? avec quelles IP ?
bon courage.Ca peut être quoi ce device ? Je ne pense pas que ce soit une K-Box, voir mon post précédent.

En analysant des paquets, certains ne sont pas vraiment broadcast !
Oui, j'envoie un ARP Reply avec dans la couche Ethernet l'adresse ff:ff:ff:ff:ff:ff mais l'adresse d'une Icotera dans la couche ARP… Pour les IP, j'utilise 169.254.1.1 et 169.254.1.3. Et ça provoque des choses, donc ça passe.

Mais en observant les paquets je réalise qu'il y a pas mal de choses qui passent aussi en unicast ! Par exemple l'appareil Quantenna (Source = 00:26:86:00:00:00) n'envoie pas toujours en multicast ou broadcast, comme on pensait, mais il envoie en unicast vers 00:1e:80:93:48:18 ! Donc vers une adresse Icotera. Donc probablement une communication interne d'une K-Box.
Je ne vois pas de 00:1e:80:93:48:18 dans mes fuites, mais je vois une 00:1e:80:93:48:00 qui est probablement la même Box (avec les derniers octets en 18 pour interface 5 GHz, 14 pour 2.4, 10 pour WAN…)
Donc ton 00:1E:80:74:XX:18 est ton interface Wifi 5 GHz vu par l'OS principal de l'Icotera, mais probablement que 00:1E:80:74:XX:18 communique en interne avec une interface cachée en 00:26:86…

Tiens, je viens de voir 00:26:86:00:00:00 envoyer un paquet à 00:11:33:55:77:bb ! Et ça semble être le paquet qui a stoppé deux fuites… Quel boxon !!

Je me demande… je pense que 00:26:86:00:00:00 n'est pas un appareil, mais plutôt que la puce Quantenna des K-Box (et d'un appareil Siemens qui semble posséder aussi cette puce Quantenna) ont toutes la même MAC ! MAC qui n'est pas destinée à être visible, donc ça serait logique… Mais quand ça fuit ça sème la zizanie !
Ça semble aussi expliquer pourquoi une seule box peut lancer le bal de plusieurs autres… Quand elles reçoivent un paquet de 00:26:86:00:00:00; elles pensent que ça vient de leur puce interne.