Et sur la question des paquets qu'on ne devrait pas voir sur le LAN, elle transmet aussi ?

Théoriquement. On verra. Parfois ils me rappellent pour avoir plus de précision.

ça serait quand même intéressant que superpicsou débranche (temporairement) les autres équipements connectés aux ports LAN de la box, et branche son Mac sur ces différents ports LAN pour voir s'il y a le même phénomène (vu en tcpdump) partout.

Je viens de faire le test. C'est pareil, je me fais spammer en boucle à chaque fois. J'ai l'impression que c'est même pire aujourd'hui. (Effet vacances ? plus de gens sur le réseaux donc plus de flux donc plus de spam ?)

Un exemple d'à peine quelques secondes
sudo tcpdump -ne arp
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
14:33:43.116317 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:43.845951 00:1e:80:44:02:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 194.147.2.254 tell 194.147.2.87, length 46
14:33:44.129672 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:44.489152 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.25 tell 192.168.1.36, length 46
14:33:45.094811 00:26:86:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
14:33:45.169523 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:45.489064 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.40 tell 192.168.1.36, length 46
14:33:46.187592 00:1e:80:44:02:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 194.147.2.254 tell 194.147.2.87, length 46
14:33:47.169611 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:47.489100 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
14:33:48.209435 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:49.065783 90:9a:4a:e8:cd:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.100.9 tell 185.238.6.40, length 46
14:33:49.249473 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:49.489299 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.26 tell 192.168.1.36, length 46
14:33:49.862532 00:1e:80:44:02:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 194.147.2.254 tell 194.147.2.87, length 46
14:33:50.087430 00:26:86:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
14:33:50.849575 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:51.889478 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:52.354209 00:1e:80:44:02:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 194.147.2.254 tell 194.147.2.87, length 46
14:33:52.929455 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:54.489125 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.58 tell 192.168.1.36, length 46
14:33:54.529563 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:54.665127 00:1e:80:44:02:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 194.147.2.254 tell 194.147.2.87, length 46
14:33:55.569444 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:56.065580 90:9a:4a:e8:cd:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.100.9 tell 185.238.6.40, length 46
14:33:56.489209 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.25 tell 192.168.1.36, length 46
14:33:56.609455 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:57.489045 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.40 tell 192.168.1.36, length 46
14:33:58.133908 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:59.065530 90:9a:4a:e8:cd:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.100.9 tell 185.238.6.40, length 46
14:33:59.169315 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:33:59.488930 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
14:34:00.209383 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:34:00.604652 00:26:86:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
14:34:01.065589 90:9a:4a:e8:cd:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.100.9 tell 185.238.6.40, length 46
14:34:01.889554 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.124, length 46
14:34:02.017033 00:1e:80:44:02:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 194.147.2.254 tell 194.147.2.87, length 46
14:34:02.551205 00:1e:80:93:5f:82 > a0:ce:c8:e7:d4:23, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.15 tell 192.168.1.1, length 46
14:34:02.551215 a0:ce:c8:e7:d4:23 > 00:1e:80:93:5f:82, ethertype ARP (0x0806), length 42: Reply 192.168.1.15 is-at a0:ce:c8:e7:d4:23, length 28
^C
39 packets captured
4857 packets received by filter
0 packets dropped by kernel


S'il y a un "port mirroring" caché mis en place sur la box, ça serait quand même intéressant que superpicsou débranche (temporairement) les autres équipements connectés aux ports LAN de la box, et branche son Mac sur ces différents ports LAN pour voir s'il y a le même phénomène (vu en tcpdump) partout.

Il y a une option "port mirroring"  sur la box. De mémoire dans avancé.

Plus de résolution dns depuis samedi midi…
En attente de résolution

Alors il y a quand même deux problèmes ici :

1) la fuite WAN/LAN de Superpicsou, qui est à priori côté K-Net (je ne vois pas comment l’OI pourrait en être responsable…)

2) le spam DHCPv6 SOLLICIT, qui est soit un problème côté K-Net (problème avec un K-Box), soit un problème de relais côté Covage. Un SOLLICIT est envoyé par un client DHCP, donc je ne vois pas comment un routeur sur l’infra K-Net pourrait être responsable, d’autant que des multicast chez K-Net ne passeraient pas vers les OI, et à priori tous les clients K-Net seraient affectés, c’est forcément soit du côté du client qui a cette K-Box, soit juste après dans le GPON de Covage.

C’est la seconde fois qu’une telle boucle se produit, et ça a bien été résolu la première fois (après 2 semaines quand même). Personne ne sait chez K-Net ou Covage qui a fait quoi pour résoudre le problème la première fois ??

Bug rare mais connu des Icotera et un ticket était ouvert chez Icotera, il faut que K-Net redémarre l'Icotera qui floode. L'adresse MAC peut facilement être déduite grâce à l'IP link-local (par exemple avec http://cgi.linuxfocus.org/~guido/javascript/ip_address_calculator/ipv6-convert.html donc dans ce cas, fe80::21e:80ff:fe74:7b98 = 00:1e:80:74:7b:98). À partir de ça, K-Net peut facilement se connecter à distance sur l'Icotera et la redémarrer. À mon époque, il y avait un système qui surveillait les logs DHCP et envoyait un email au NOC dès que ça se produisait (environ 1 Icotera tous les 3 mois).

Un autre bug connu des Icotera. Trouver la source est plus compliqué, mais là encore il y avait des systèmes pour détecter (dès qu'il y a des requêtes ARP en 169.254.1.0/24) et corriger le problème. Un ticket était aussi ouvert.

Voilà qui est clair et très cohérent.

La MAC, je l’ai donnée à FB et Covage dès le début (les deux fois). Elle est effectivement trouvable depuis l’adresse link local, Mais Elle est aussi en clair dans le corps du message DHCP (OPTION_CLIENTID), et aussi tout simplement dans la trame ethernet.

C’est assez fou que K-Net semble avoir oublié ces problèmes qui ne sont donc ni nouveaux, ni inconnus… Leur nouvelle équipe redécouvre tout de zéro. Et la solution est assez simple.

Maintenant, ces bogues Icotera sont vraiment graves quand même ! 

Voilà qui est clair et très cohérent.

... et qui confirme ce qu'on a mis en évidence ici depuis plusieurs jours.

Maintenant, ces bogues Icotera sont vraiment graves quand même ! 

Exact, ça pose également plusieurs questions :
- comment ce fait-il que de tels "problèmes" au sens ITIL/ITSM n'aient pas donné lieu à un plan d'action vigoureux de la part de K-Net et de leur fournisseur (Icotera, qui ne "parle" pas aux particuliers, juste aux ISP) ?
- chez K-Net, ont-ils aussi perdu leur base des "known errors" ?
- ce bug avec DHCP v6 est-il aussi la raison non avouée pour laquelle IPv6 a été désactivé sur le réseau (mais sans forcer la désactivation sur les box) ?
- quelle est la part de firmware Icotera vraiment développée en interne K-Net (voir MP de FB à superpicsou) ? Je pensais que c'était juste au niveau de la gestion à distance de la box, mais certainement pas dans les couches "basses" du routeur qui sont concernées ici.