La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
K-Net => Opérateurs grand public alternatifs => Espace technique internet K-Net => Discussion démarrée par: Superpicsou le 07 avril 2022 à 14:01:46
-
[EDIT]
Résumé : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943724/#msg943724
Solution : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943589/#msg943589
---------------------------
Bonjour.
Alors, j'ai un bug un peu étrange (mais chiant).
Sur mon MacBook Pro j'ai tout le temps des coupure d'internet lié au fait que la résolution DNS ne se fasse plus.
Ce bug ne se produit que sur le Mac et que sur la box Knet (wifi ET ethernet)
- Pas de soucis en ethernet et/ou wifi sur Mac et PC sur la Bbox Adsl
- Pas de soucis en ethernet et/ou wifi sur PC sur la Box Knet
- Soucis en ethernet et/ou wifi sur Mac sur la Box Knet
Si je mets l'ip direct de google ou d'un autre site j'y accède bien, mais via les dns ça fonctionne pas. Et je me fais deco de partout (discord, slack etc).
Si je débranche/rebranche mon cable réseau ou que je desactive/active le wifi, ça revient instantanément.
Ca me rend fou, si quelqu'un à une idée, une solution, une piste.
-
Un traceroute vers le serveur DNS quand tout fonctionne et quand cela bloque serait intéressant.
-
C'est la KBOX le "serveur" DNS (configuration par défaut pour les postes en DHCP) ? Si c'est le cas, le traceroute indiqué par Vivien ne sert pas à grand chose.
Et sinon, en forçant la configuration sur le Mac pour que la résolution passe par des serveurs "publics" comme 8.8.8.8 ou 1.1.1.1, qu'est-ce que ça donne ?
-
Même soucis en forçant sur un serveur dns (1.1.1.1 pour mon test). J'ai essayé ce matin.
-
désolé, j'avais mal compris la phrase :
Si je mets l'ip direct de google ou d'un autre site j'y accède bien, mais via les dns ça fonctionne pas.
Comme suggère Vivien :
- traceroute vers le serveur DNS en cas d'incident
- requêtes DNS "manuelles" (pas au travers d'une appli), avec dig ou nslookup (je ne sais pas ce qui est dispo dans un "Terminal" Mac, je suis plutôt Linuxien)
- analyse réseau (ex : wireshark)
-
Ok je vais tenté ça déjà pour voir ce qui se passe.
Merci.
-
+ tester cette page qui ne demande pas de résolution DNS : http://45.85.134.187/
Cela permet de voir si il n'y a que le DNS qui ne répond plus ou si tout internet est cassé.
-
désolé, j'avais mal compris la phrase :Comme suggère Vivien :
- traceroute vers le serveur DNS en cas d'incident
- requêtes DNS "manuelles" (pas au travers d'une appli), avec dig ou nslookup (je ne sais pas ce qui est dispo dans un "Terminal" Mac, je suis plutôt Linuxien)
- analyse réseau (ex : wireshark)
Il y a tout ce qu'il faut :
grvg@MacBook-Pro-de-Bolemo ~ % which dig
/usr/bin/dig
grvg@MacBook-Pro-de-Bolemo ~ % which nslookup
/usr/bin/nslookup
grvg@MacBook-Pro-de-Bolemo ~ % which tcpdump
/usr/sbin/tcpdump
grvg@MacBook-Pro-de-Bolemo ~ % which traceroute
/usr/sbin/traceroute
grvg@MacBook-Pro-de-Bolemo ~ % which ping
/sbin/ping
Et avec homebrew, on peut installer la plupart des paquets disponibles sous linux (mtr, etc…)
-
Bon, c'est pas claire.
Aujourd'hui je ne perd pas que les dns mais toutes la connexion. Mais, c'est hyper étrange. Je ne peux pas ping l'icotera
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Mais, je peux ping les autres ordinateurs du réseaux.
$ ping 192.168.1.46
PING 192.168.1.46 (192.168.1.46): 56 data bytes
64 bytes from 192.168.1.46: icmp_seq=0 ttl=128 time=0.753 ms
64 bytes from 192.168.1.46: icmp_seq=1 ttl=128 time=1.061 ms
64 bytes from 192.168.1.46: icmp_seq=2 ttl=128 time=0.688 ms
Et les autres ordinateur du réseaux par contre peuvent ping le mac et l'icotera sans soucis. Et pendant que ça crash je vérifie sur divers appareil wifi/ethernet dans la maison. Aucun soucis.
:o
Je comprend vraiment pas. Sur la box ADSL wifi/filaire pas de soucis. Sur l'icotera ça crash.
La question est donc, qu'est ce qui fait que le mac perde complètement la connexion à l'icotera comme ça. Et pourquoi j'ai pas eu le soucis avant.
Ps: j'ai des log wireshark si ça interesse, c'est trop cryptique pour moi.
-
Aujourd'hui je ne perd pas que les dns mais toutes la connexion. Mais, c'est hyper étrange. Je ne peux pas ping l'icotera
Mais, je peux ping les autres ordinateurs du réseaux.
Donc effectivement, pas un problème DNS.
N'ayant aucune compétence sur Mac OS, je vais m'abstenir de proposer des pistes de diagnostic, sauf une :
Ca pourrait ressembler quand même à une duplication d'adresse IP sur le réseau local (même adresse IP que le Mac prise par un autre équipement).
-
J'ai fais un tcpdump pour voir ce qu'il se passe aussi quand ça coupe. (jai nettoyé un peu les trucs)
$ sudo tcpdump src 192.168.1.1
11:01:51.859733 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:02:40.108610 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:03:26.674354 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:04:17.542073 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:05:04.078829 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:05:52.019697 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:06:47.148493 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:08:06.291577 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:08:54.570286 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:09:58.157458 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:11:18.764557 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:11:59.692759 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:12:45.732227 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:13:29.457236 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:15:00.205213 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:15:54.154476 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:16:47.116206 ARP, Request who-has Macbook tell 192.168.1.1, length 46
11:17:26.571330 ARP, Request who-has 192.168.1.57 tell 192.168.1.1, length 46
11:18:22.606162 ARP, Request who-has 192.168.1.57 tell 192.168.1.1, length 46
11:19:43.709576 ARP, Reply 192.168.1.1 is-at 00:1e:80:93:xx:xx (oui Unknown), length 46
11:19:49.223752 ARP, Request who-has Macbook tell 192.168.1.1, length 46
Quand ça coupe l'icotera chercher un .57 sur le réseau. Mais ya aucune appareil sur mon réseau qui utilise cette ip.
Mais la pareil, mes faibles compétences en réseaux me permettent pas de dire si c'est un comportement normale du protocole de résolution d'adresse. Ca metonne juste qu'il cherche que la .57 alors qu'elle existe pas et que le macbook est en .15
Faut-il essayer en déclarant une ip locale fix pour le macbook dans l'interface de l'icotera ?
-
A la place de
$ sudo tcpdump src 192.168.1.1
ça serait peut-être plus parlant de lancer
$ sudo tcpdump -ne arp
-
Je test ça et je vous redis.
Si vous voulez d'autre bizarrerie. Je n'ai aucune perte de connexion sur le wifi 5Ghz. Seulement en ethernet et 2.4Ghz....
-
Si vous voulez d'autre bizarrerie. Je n'ai aucune perte de connexion sur le wifi 5Ghz. Seulement en ethernet et 2.4Ghz....
Problème réglé alors = rester sur 5GHz. ;)
Mais par curiosité, autant continuer les investigations ...
-
C'est très curieux en effet…
C'est un conflit entre le Mac et l'icotera… car le routage LAN depuis et vers ton Mac fonctionne bien même pendant le crash (et ça passe par l'Icotera).
On dirait un blocage dans l'Icotera au niveau de l'iptables (forward sur LAN ok mais pas vers WAN ou Icotera elle-même).
Hors du crash, et pendant un crash, tu peux lancer la commande arp -a pour comparer.
Mais ethernet et wifi 2,4 mais pas wifi 5… :o
Peut-être des règles iptables différentes sur l'Icotera justement…
@pju91 : macOS, c'est du Unix, donc même diagnostics que sous Linux.
-
Voilà ce que ça donne quand j'ai une coupure. ça continue de défiler comme si de rien n'était
$ sudo tcpdump -ne arp
12:18:39.291676 78:d2:94:e9:bb:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.237.177, length 46
12:18:39.565559 00:1e:80:93:04:b0 > 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
12:18:39.875095 00:1e:80:93:0b:58 > 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
12:18:39.974130 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:40.565411 00:1e:80:93:04:b0 > 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
12:18:40.860125 38:94:ed:f7:80:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.239.15, length 46
12:18:40.875144 00:1e:80:93:0b:58 > 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
12:18:40.979072 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:41.565422 00:1e:80:93:04:b0 > 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
12:18:42.297612 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:42.975771 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:43.880225 00:1e:80:93:0b:58 > 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
12:18:43.977849 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:44.570463 00:1e:80:93:04:b0 > 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
12:18:44.879955 00:1e:80:93:0b:58 > 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
12:18:45.328141 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:45.570391 00:1e:80:93:04:b0 > 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
12:18:45.582185 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
12:18:45.879986 00:1e:80:93:0b:58 > 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
12:18:45.987877 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:46.570273 00:1e:80:93:04:b0 > 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
12:18:46.590980 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
12:18:46.974845 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:47.600991 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
12:18:48.341177 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:48.610926 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
12:18:48.885184 00:1e:80:93:0b:58 > 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
12:18:48.977361 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:49.575140 00:1e:80:93:04:b0 > 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
12:18:49.629184 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Reply 2.59.238.91 is-at e8:1c:ba:36:01:d0, length 46
12:18:49.885040 00:1e:80:93:0b:58 > 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
12:18:49.977829 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:50.575350 00:1e:80:93:04:b0 > 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
12:18:50.885004 00:1e:80:93:0b:58 > 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
12:18:51.389896 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:51.491247 00:1e:80:93:47:f8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.162, length 46
12:18:51.575000 00:1e:80:93:04:b0 > 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
12:18:51.978760 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:52.981020 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:53.889752 00:1e:80:93:0b:58 > 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
12:18:54.410035 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:54.580125 00:1e:80:93:04:b0 > 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
12:18:54.889917 00:1e:80:93:0b:58 > 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
12:18:54.976964 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:55.580095 00:1e:80:93:04:b0 > 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
12:18:55.789452 00:1e:80:74:a3:b8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 185.238.7.116, length 46
12:18:55.889861 00:1e:80:93:0b:58 > 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
12:18:55.975905 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:56.579853 00:1e:80:93:04:b0 > 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
12:18:57.447311 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:57.974417 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:58.136195 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
12:18:58.899487 00:1e:80:93:0b:58 > 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
12:18:58.976367 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:18:59.176008 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
12:18:59.584933 00:1e:80:93:04:b0 > 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
12:18:59.899654 00:1e:80:93:0b:58 > 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
12:19:00.216028 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
12:19:00.459944 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:19:00.584956 00:1e:80:93:04:b0 > 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
12:19:00.899647 00:1e:80:93:0b:58 > 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
12:19:00.975694 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.255.255 tell 192.168.1.46, length 46
12:19:01.256101 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
12:19:01.584879 00:1e:80:93:04:b0 > 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
-
Voilà ce que ça donne quand j'ai une coupure. ça continue de défiler comme si de rien n'était
Pourquoi voit-on
1. Des équipements en "auto-configuration IP", adresses en 169.254 ? Les équipements LAN devraient trouver le serveur DHCP (box Icotera)
2. Des requêtes ARP pour des IP côté WAN / Internet en 2.59 (sur plage KWAOO / K-Net) ou d'autres adresses publiques ? Ca n'a rien à faire côté LAN.
En revanche, on ne voit pas de requête pour le Mac (en 192.168.1.15 si j'ai bien compris). C'est peut-être encore dans le cache ARP sur la période de capture.
-
Aucune idée, je n'ai malheureusement pas les compétences pour analyser ces résultats.
Bas en attendant je me suis mis sur le wifi 5Ghz et ça tiens bien, pas de coupure depuis.
Si quelqu'un à un jour une autre idée de test, je laisse le sujet ouvert.
-
Pourquoi voit-on
1. Des équipements en "auto-configuration IP", adresses en 169.254 ? Les équipements LAN devraient trouver le serveur DHCP (box Icotera)
2. Des requêtes ARP pour des IP côté WAN / Internet en 2.59 (sur plage KWAOO / K-Net) ou d'autres adresses publiques ? Ca n'a rien à faire côté LAN.
En revanche, on ne voit pas de requête pour le Mac (en 192.168.1.15 si j'ai bien compris). C'est peut-être encore dans le cache ARP sur la période de capture.
Cela est clairement anormal…
Pour comparer, la même commande depuis mon MacBook Pro me retourne que peu de requêtes ARP, toutes dans mon sous-réseau local.
J'utilise un routeur perso.
Il y a à priori un problème de configuration sur la K-Box (soit à cause des paramètres entrés, soit un problème avec ceux envoyés par K-Net à la K-Box) qui provoque des fuites WAN/LAN…
Ces adresses MAC avec des IP APIPA (169.254...) comme 3c:7c:3f:20:c5:55 ou 00:1e:80:93:04:b0 ou encore 00:1e:80:93:0b:58, etc… sont-elles chez toi ? Des appareils à toi ?
Que te donne la commande
arp -adepuis ton MacBook Pro ?
-
Sur les anomalies que je relevais précédemment, et dont rien ne prouve pour le moment qu'elles sont à l'origine des dysfonctionnements, impossible pour moi de poser un diagnostic sans disposer
- de la topologie précise du réseau (ex : switches, autres équipements)
- des paramètres de configuration "inattendus" de la box (ex : port mirroring)
D'autres ont peut-être des idées ...
-
Sur les anomalies que je relevais précédemment, et dont rien ne prouve pour le moment qu'elles sont à l'origine des dysfonctionnements, impossible pour moi de poser un diagnostic sans disposer
- de la topologie précise du réseau (ex : switches, autres équipements)
- des paramètres de configuration "inattendus" de la box (ex : port mirroring)
D'autres ont peut-être des idées ...
Les anomalies ne sont peut-être pas la cause, mais un autre symptôme du problème…
Mais oui, la topologie est essentielle pour aller plus loin ; si l'ONT est relié à un switch et que la box est tous les appareils en ethernet sont sur ce switch, ça expliquerait des choses…
-
Mais oui, la topologie est essentielle pour aller plus loin ; si l'ONT est relié à un switch et que la box est tous les appareils en ethernet sont sur ce switch, ça expliquerait des choses…
hélas oui, c'était le sens de mon message.
-
Que te donne la commande
arp -adepuis ton MacBook Pro ?
? (192.168.1.1) at 0:1e:80:93:xx:xx on en7 ifscope [ethernet]
? (192.168.1.255) at ff:ff:ff:ff:ff:ff on en7 ifscope [ethernet]
? (239.255.255.250) at 1:0:5e:7f:xx:xx on en7 ifscope permanent [ethernet]
Concernant mon architecture elle est basique.
ONT Huawei -> Icotera -> Macbook
(https://i.ibb.co/DM0kctF/Capture-d-e-cran-2022-04-08-a-14-37-50.png) (https://ibb.co/DM0kctF)
-
Concernant mon architecture elle est basique.
ONT Huawei -> Icotera -> Macbook
Je ne vois effectivement rien de suspect là-dedans, et rien qui expliquerait les bizarreries du tcpdump de ce matin, désolé.
-
Bon. J'ai refais un dernier test car ce matin j'avais plein de truc d'ouvert sur le mac qui aurait pu faire un résultat étrange.
Du coup la en ayant que le terminal de lancé (et biensur tout les processus de fond de macos) et un ping pour voir quand je me fais déco (ya pas longtemps à attendre).
Voilà le résultat
(https://i.ibb.co/1bjbTN1/Capture-d-e-cran-2022-04-08-a-15-06-44.png)
─$ 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
15:05:28.423160 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
15:05:30.423552 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
15:05:32.610060 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
15:05:32.610073 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
15:05:33.083288 00:1e:80:92:64:dc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.38, length 46
15:05:36.636967 68:ff:7b:95:b1:49 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 185.238.7.119, length 46
15:05:38.105042 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
15:05:38.106630 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
15:05:43.105323 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
15:05:44.126599 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
15:05:48.105314 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
15:05:53.105349 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
15:05:56.043912 e0:10:7f:2c:73:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 185.238.5.252, length 46
15:05:56.786140 68:ff:7b:ac:7a:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 185.4.76.135, length 46
15:05:58.105383 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
15:05:58.531048 04:42:1a:2e:9d:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.238.55, length 46
15:06:00.531770 04:42:1a:2e:9d:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.238.55, length 46
15:06:02.342647 78:d2:94:e9:bb:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.237.177, length 46
15:06:03.105257 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
15:06:04.128494 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
15:06:08.216925 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
^C
21 packets captured
13610 packets received by filter
0 packets dropped by kernel
-
Voilà le résultat
Préoccupant : on voit du trafic qui devrait rester côté WAN, par exemple d'une autre box Icotera 00:1e:80:92:64:dc ou avec 172.16.100.9 qui est je crois le serveur DHCP K-Net, et qui sert donc à fournir les paramètres IP aux routeurs des clients K-Net.
-
Pour l'historique, quand j'ai reçu ma box je ne pouvais rien paramétrer car dans mon espace client et dans la config de ma box ce n'était pas mon ip mais celle de quelqu'un d'autre. Je n'avais pas non plus le wifi d'actif.
Du coup un technicien a manuellement activer le wifi avec un ssid défini et un mdp.
Ensuite j'ai eu la bonne ip dans mon interface et accés à la box, sauf l'onglet WIFI qui renvoyé toujours vers l'ancienne config.
Enfin, j'ai eu accés à l'onglet wifi, mais à la sauvegarde j'ai un message d'erreur à chaque fois. MAIS ça sauvegarde bien ce que j'ai mis mais ça m'affiche en continuer le message "Vous avez modifié la configuration - Annuler / Enregistrer"
Erreur lors de l'enregistrement de la configuration. Vérifiez les champs.
Erreur retournée par le serveur: "Erreur de communication avec votre équipement. Veuillez re-essayer dans quelques instants."
(https://i.ibb.co/zrpxLcx/Capture-d-e-cran-2022-04-08-a-15-39-48.png) (https://i.ibb.co/zrpxLcx/Capture-d-e-cran-2022-04-08-a-15-39-48.png)
(https://i.ibb.co/S0B6Dw0/Capture-d-e-cran-2022-04-08-a-15-37-44.png) (https://i.ibb.co/S0B6Dw0/Capture-d-e-cran-2022-04-08-a-15-37-44.png)
Ma box est-elle maudite ?
-
Ma box est-elle maudite ?
Est-ce que c'est bien sûr qu'il n'y a pas de port mirroring du port WAN vers le port sur lequel est branché le Mac en Ethernet ?
Voir dans onglet outil du panel de la box, en bas de la page.
-
Non, l'option n'est pas coché.
J'ai fais un tcpdump aussi sur le wifi 5.0Ghz qui ne plante pas pour voir.
Il y a moins de traffic étrange non, à voir si c'est lié au fait que je n'ai plus la même ip ?
$ 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
15:46:15.835928 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
15:46:17.837083 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
15:46:19.072140 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
15:46:29.082206 7c:26:64:de:d4:bc > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.77 tell 192.168.1.254, length 46
15:46:29.082215 3c:22:fb:01:d0:80 > 7c:26:64:de:d4:bc, ethertype ARP (0x0806), length 42: Reply 192.168.1.77 is-at 3c:22:fb:01:d0:80, length 28
15:46:54.518475 7c:26:64:de:d4:bc > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Reply 192.168.1.254 is-at 7c:26:64:de:d4:bc, length 46
15:46:59.522649 7c:26:64:de:d4:bc > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.77 tell 192.168.1.254, length 46
15:46:59.522662 3c:22:fb:01:d0:80 > 7c:26:64:de:d4:bc, ethertype ARP (0x0806), length 42: Reply 192.168.1.77 is-at 3c:22:fb:01:d0:80, length 28
15:47:19.057080 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
15:47:21.057810 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
15:47:23.059289 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
15:47:28.064881 7c:26:64:de:d4:bc > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.77 tell 192.168.1.254, length 46
15:47:28.064894 3c:22:fb:01:d0:80 > 7c:26:64:de:d4:bc, ethertype ARP (0x0806), length 42: Reply 192.168.1.77 is-at 3c:22:fb:01:d0:80, length 28
^C
13 packets captured
90451 packets received by filter
0 packets dropped by kernel
-
Est-ce que c'est bien sûr qu'il n'y a pas de port mirroring du port WAN vers le port sur lequel est branché le Mac en Ethernet ?
Voir dans onglet outil du panel de la box, en bas de la page.
+1 edit : ça y ressemble quand même beaucoup!
Et peut-être aussi vérifier que WAN(bleu) et LAN (jaune Port_n) partent bien chacun du bon coté réseau de la K-box.
-
Mon installation ressemble à ça
(https://i.ibb.co/nPrXxR5/Capture-d-e-cran-2022-04-08-a-16-00-48.png) (https://ibb.co/nPrXxR5) (https://i.ibb.co/w6v2MH9/Capture-d-e-cran-2022-04-08-a-16-01-02.png) (https://ibb.co/w6v2MH9) (https://i.ibb.co/VxWSqfz/Capture-d-e-cran-2022-04-08-a-16-01-50.png) (https://ibb.co/VxWSqfz)
L'ONT sur le WAN
Puis après ça passe de la box a la baie de la maison pour les connexions filaire.
Et le wifi bas, wifi.
Ya en plus une box ADSL mais rien de branché dessus à part le téléphone (comment ça ya un téléphone sur le kbox?)
-
Il y a moins de traffic étrange non, à voir si c'est lié au fait que je n'ai plus la même ip ?
C'est du trafic ARP avec la BBOX (si 192.168.1.254 est bien son adresse) qui fait également de la prévention de duplication de son adresse IP (les broadcasts indiquant ... tell 0.0.0.0).
Je ne vois pas d'ARP avec la K-BOX.
-
Ok.. bon je vais supprimer tout les réseaux du mac vu qu'il m'affiche être sur la kbox 5Ghz alors qu'en fait il utilise le wifi de la Bbox...
Voilà en vraiment 5Ghz
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
16:09:58.169239 00:1e:80:93:5f:82 > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.81 tell 192.168.1.1, length 46
16:09:58.169255 3c:22:fb:01:d0:80 > 00:1e:80:93:5f:82, ethertype ARP (0x0806), length 42: Reply 192.168.1.81 is-at 3c:22:fb:01:d0:80, length 28
16:09:58.186646 00:1e:80:93:5f:82 > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 00:1e:80:93:5f:82, length 46
16:11:28.285084 00:1e:80:93:5f:82 > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 00:1e:80:93:5f:82, length 46
^C
4 packets captured
129009 packets received by filter
0 packets dropped by kernel
-
Ok.. bon je vais supprimer tout les réseaux du mac vu qu'il m'affiche être sur la kbox 5Ghz alors qu'en fait il utilise le wifi de la Bbox...
Les SSID de la BBOX et de la K-Box sont différents ?
Voilà en vraiment 5Ghz
Là on ne voit plus d'adresses extérieures.
-
Oui pas la même SSID
(https://i.ibb.co/yh9Yyg8/Capture-d-e-cran-2022-04-08-a-16-22-00.png) (https://ibb.co/yh9Yyg8)
Un comparatif
Wifi 5.0Ghz Kbox (tout les wifi supprimés avant)
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
16:09:58.169239 00:1e:80:93:5f:82 > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.81 tell 192.168.1.1, length 46
16:09:58.169255 3c:22:fb:01:d0:80 > 00:1e:80:93:5f:82, ethertype ARP (0x0806), length 42: Reply 192.168.1.81 is-at 3c:22:fb:01:d0:80, length 28
16:09:58.186646 00:1e:80:93:5f:82 > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 00:1e:80:93:5f:82, length 46
16:11:28.285084 00:1e:80:93:5f:82 > 3c:22:fb:01:d0:80, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 00:1e:80:93:5f:82, length 46
^C
4 packets captured
129009 packets received by filter
0 packets dropped by kernel
Ethernet Kbox avec wifi coupé
$ sudo tcpdump -ne arp 130 ↵
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
16:13:08.686751 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
16:13:08.843783 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Probe 192.168.1.15, length 28
16:13:09.166233 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Probe 192.168.1.15, length 28
16:13:09.490537 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Probe 192.168.1.15, length 28
16:13:09.811209 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Announcement 192.168.1.15, length 28
16:13:10.132827 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Announcement 192.168.1.15, length 28
16:13:10.456825 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Announcement 192.168.1.15, length 28
16:13:10.457588 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.15, length 28
16:13:10.458329 00:1e:80:93:5f:82 > a0:ce:c8:e7:d4:23, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 00:1e:80:93:5f:82, length 46
16:13:10.458669 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.15, length 28
16:13:10.490560 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.15, length 28
16:13:10.491628 00:1e:80:93:5f:82 > a0:ce:c8:e7:d4:23, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 00:1e:80:93:5f:82, length 46
16:13:10.782809 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.15, length 28
16:13:11.107619 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.15, length 28
16:13:11.432368 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.15, length 28
16:13:11.757101 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.15, length 28
16:13:14.253326 44:4e:6d:ac:0c:3c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.238.171, length 46
16:13:16.377005 00:1e:80:93:74:14 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 45.83.231.47, length 46
16:13:17.347688 00:1e:80:93:0b:58 > 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
16:13:17.616606 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
16:13:17.616615 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
16:13:18.347569 00:1e:80:93:0b:58 > 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
16:13:19.012901 00:1e:80:93:04:b0 > 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
16:13:19.348050 00:1e:80:93:0b:58 > 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
16:13:20.013022 00:1e:80:93:04:b0 > 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
16:13:21.013464 00:1e:80:93:04:b0 > 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
16:13:22.183545 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
16:13:24.915061 10:6f:3f:0f:c0:84 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.237.115, length 46
16:13:25.387126 68:ff:7b:95:b2:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 185.238.7.120, length 46
16:13:27.082115 e0:10:7f:2c:73:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 185.238.5.252, length 46
16:13:29.234524 04:42:1a:2e:9d:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.238.55, length 46
16:13:31.237316 04:42:1a:2e:9d:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.238.55, length 46
16:13:31.886197 00:0e:c4:d2:80:22 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.7.254 tell 185.238.6.33, length 46
16:13:32.190570 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
16:13:32.454925 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
16:13:33.630182 68:ff:7b:95:b1:49 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 185.238.7.119, length 46
16:13:38.717259 00:1e:80:84:1b:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 178.250.209.34 tell 169.254.1.1, length 46
16:13:38.792847 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
16:13:40.786214 e0:23:ff:6d:6e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.4.147 tell 185.238.4.204, length 46
16:13:40.789500 2c:30:33:e6:11:b3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.4.147 tell 185.238.4.237, length 46
16:13:42.194497 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
16:13:46.674459 e8:fc:af:8f:21:c5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.4.147 tell 185.238.4.125, length 46
16:13:46.742695 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
16:13:47.753161 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
16:13:48.763282 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
16:13:49.773365 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
16:13:50.244198 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:13:50.560604 24:a0:74:4c:15:21 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 192.168.1.99, length 46
16:13:50.789093 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Reply 2.59.238.91 is-at e8:1c:ba:36:01:d0, length 46
16:13:53.101012 24:a0:74:4c:15:21 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 192.168.1.99, length 46
16:13:53.283915 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
16:13:54.250881 38:94:ed:f7:80:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.239.15, length 46
16:13:55.244542 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:14:00.244360 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
^C
54 packets captured
43567 packets received by filter
0 packets dropped by kernel
Wifi 2.4Ghz Kbox (tout les wifi supprimés avant)
─$ 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
16:16:11.666963 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:12.639850 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
16:16:16.533603 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
16:16:18.501542 e8:1c:ba:36:01:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 2.59.238.91, length 46
16:16:22.441718 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
16:16:24.838648 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
16:16:24.901552 38:94:ed:f7:80:f3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.239.15, length 46
16:16:25.707081 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:30.709244 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:35.706819 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:36.147686 24:a0:74:4c:15:21 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 56: Announcement 192.168.1.99, length 42
16:16:37.990223 00:1e:80:7f:53:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.86 tell 192.168.1.1, length 46
16:16:38.455900 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
16:16:38.680707 24:a0:74:4c:15:21 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 56: Announcement 192.168.1.99, length 42
16:16:38.730213 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
16:16:40.708718 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:45.706871 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:48.947365 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
16:16:49.995158 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
16:16:50.706551 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
16:16:51.033456 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
16:16:52.073734 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
16:16:53.113278 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
16:16:54.153441 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
16:16:56.514947 b0:a7:b9:87:83:2f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 2.59.237.150, length 46
16:16:56.796332 10:0d:7f:91:6f:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.44 tell 192.168.1.1, length 46
^C
26 packets captured
13234 packets received by filter
0 packets dropped by kernel
Pour compléter la chose, un tcpdump depuis mon windows, en ethernet et qui lui ne perd pas la connexion.
C:\Users\xxx\Downloads\tcpdump_trial_license\tcpdump.exe: verbose output suppressed, use -v or -vv for full protocol decode
listening on \Device\{02B0A39E-751B-4DBA-BFB3-94A39968E2C0}, link-type EN10MB (Ethernet), capture size 262144 bytes
16:52:01.459496 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
16:52:01.459496 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
16:52:01.928102 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
16:52:02.037486 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:02.506125 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
16:52:02.667806 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:02.933397 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
16:52:03.542742 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
16:52:03.667610 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:03.949132 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
16:52:04.138082 78:d2:94:0e:e9:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.59 tell 2.59.239.59, length 46
16:52:04.263047 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
16:52:04.591133 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
16:52:04.965979 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Reply 2.59.238.185 is-at 90:6c:ac:84:9e:e0, length 46
16:52:05.059740 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:05.623708 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
16:52:05.670574 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:06.016535 bc:a5:11:31:f7:ae > 44:82:e5:1d:d4:02, ethertype ARP (0x0806), length 60: Request who-has 192.168.18.1 tell 192.168.18.2, length 46
16:52:06.016535 bc:a5:11:31:f7:ae > 44:82:e5:1d:d4:02, ethertype ARP (0x0806), length 60: Request who-has 192.168.18.1 tell 192.168.18.2, length 46
16:52:06.661760 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
16:52:06.677383 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:06.896081 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
16:52:07.083536 00:1e:80:93:48: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
16:52:07.708389 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
16:52:08.068208 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:08.507189 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
16:52:08.679057 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:08.741542 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
16:52:09.680457 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:09.789807 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
16:52:10.414662 b0:a7:b9:87:83:2f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.237.150 tell 2.59.237.150, length 46
16:52:10.823276 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
16:52:11.088901 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:11.666828 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:11.869871 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
16:52:12.671321 3c:7c:3f:20:c5:55 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.255.255 tell 192.168.1.46, length 28
16:52:12.905641 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
37 packets captured
2500 packets received by filter
0 packets dropped by kernel
Sur l'ethernet et le wifi 2.4 il me deco trés rapidement mais continue à spam des trucs.
La question aussi c'est pourquoi windows s'en fou et continue sa vie, alors que le mac dit fuck et coupe les ponts avec l'icotera
-
Un comparatif
Wifi 5.0Ghz Kbox (tout les wifi supprimés avant)
Ethernet Kbox avec wifi coupé
Wifi 2.4Ghz Kbox (tout les wifi supprimés avant)
Sur l'ethernet et le wifi 2.4 il me deco trés rapidement mais continue à spam des trucs.
Clairement, sur "Ethernet" et sur WIFI 2.4 GHz, c'est totalement anormal, on voit du trafic qui n'a rien à faire là.
Exemples :
pju@fedora ~]$ whois 45.83.231.254 |grep -i netname
netname: KNET-CUSTOMERS
[pju@fedora ~]$ whois 185.238.4.147|grep netname
netname: KNET-CUSTOMERS
[pju@fedora ~]$ whois 2.59.238.91|grep netname
netname: KNET-CUSTOMERS
Je laisse les experts de la KBOX dire ce qu'ils en pensent.
-
L'ONT sur le WAN
Puis après ça passe de la box a la baie de la maison pour les connexions filaire.
Et le wifi bas, wifi.
Ya en plus une box ADSL mais rien de branché dessus à part le téléphone (comment ça ya un téléphone sur le kbox?)
Bin c'est tout bon.
Bizarre et anormal de voir d'autres clients K-net (avec du Netgear, Fortigate...) et la passerelle (.254) sur ton lan.
Ça aurait passionné les anciens employés de K-net qui t'auraient résolu le soucis en trois clics avec le forum CAPS!
-
Est-ce que ça aurait un lien avec le post de bolemo sur l'équipement qui spam sur le réseaux ?
https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg942119/#new
-
Est-ce que ça aurait un lien avec le post de bolemo sur l'équipement qui spam sur le réseaux ?
Sauf erreur, bolemo n'observe rien sur son LAN (mais je crois qu'il n'utilise pas de K-Box)
Est-ce que la K-Box ne résiste pas au trafic WAN irrégulier et se met à fuire ? Je n'en sais rien, mais les paquets qu'on voit côté LAN ne sont pas ceux du "bug" qui préoccupe bolemo.
-
Est-ce que ça aurait un lien avec le post de bolemo sur l'équipement qui spam sur le réseaux ?
https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg942119/#new
Clairement ça ne t'aide pas…
1) Tu es dans le 14 (comme moi), et le GPON du 14 est floodé de requêtes DHCPv6 (environ 4 000 per seconde !)
2) Il y a un perméabilité WAN/LAN anormale sur ton Icotera sur l'ethernet et le wifi 2,4GHz, du coup, le flood passe dans ton LAN…
Tu peux essayer ceci (pas en 5GHz donc) : sudo tcpdump -v udp port 547
Prépare toi à faire un ^C (Contrôle-C) pour interrompre, car tu risque de voir ta fenêtre de terminal se remplir très très vite…
Tout cela étant dit, je soupçonne que ces deux problèmes soient liés… Je pense que les configs de certaines Icotera deviennent complètement corrompues… Un Icotera sur notre GPON est responsable de ce flood (elle a pour MAC WAN 00:1e:80:74:7b:98), probablement suite à une telle corruption.
La tienne semble aussi corrompue… Les règles iptables pour les réseaux LAN ethernet et wifi 2,4 GHz ne sont absolument pas bonnes, ou un réglage forwarding est activé là où il ne devrait pas…
Par contre, le réseau LAN wifi 5 GHz lui est normal.
-
Sauf erreur, bolemo n'observe rien sur son LAN (mais je crois qu'il n'utilise pas de K-Box)
Est-ce que la K-Box ne résiste pas au trafic WAN irrégulier et se met à fuire ? Je n'en sais rien, mais les paquets qu'on voit côté LAN ne sont pas ceux du "bug" qui préoccupe bolemo.
J'ai un routeur perso, et un pare-feu bien solide. J'ai ultra protégé mon LAN avec entre autres des règles ebtables, iptables et Cie que j'ai établies à la main… Donc tous les paquets qui ne sont pas destinés à mon LAN sont bloqués à la porte de mon routeur.
Mais je peux écouter à la porte de mon routeur sur le WAN, et en effet, il y a plein de paquets APIPA et autres… J'en avais parlé à l'époque sur le forum Caps.
En principe, les réglages de base de tout routeur ou toute box doit bloquer ces paquets, mais ici, pour Superpicsou, il est évident que l'Icotera ne fait pas son boulot.
Comme il est dans le 14, et comme les paquets passent à travers son Icotera comme le vent à travers une passoire, je suis assez sûr que le flood DHCPv6 passe au travers. La requête tcpdump -ne arp ne les montre pas, mais tcpdump -v udp port 547 permet de les voir…
D'ailleurs, je vois bien les mêmes choses que lui côté WAN (depuis mon routeur) :
root@HERMES:~$ tcpdump -i ethwan -ne arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
17:30:56.543745 00:1e:80:93:0b:58 > 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
17:30:56.977110 00:1e:80:93:04:b0 > 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
17:30:57.352805 e0:10:7f:2c:73:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.5.252 tell 0.0.0.0, length 46
17:30:57.543839 00:1e:80:93:0b:58 > 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
17:30:57.977047 00:1e:80:93:04:b0 > 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
17:30:58.543776 00:1e:80:93:0b:58 > 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
17:30:58.899946 e8:fc:af:7b:4f:25 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.4.147 tell 185.238.6.208, length 46
17:30:58.977141 00:1e:80:93:04:b0 > 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
17:31:00.205288 00:1e:80:74:a3:b8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.7.116 tell 185.238.7.116, length 46
17:31:00.486107 04:42:1a:2e:9d:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.55 tell 2.59.238.55, length 46
17:31:01.548931 00:1e:80:93:0b:58 > 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
-
3000 lignes en une seconde mdr du coup voici que les 10 premières.
Ce qui est "drole" avec ce soucis de "fuite" réseau, c'est que le macbook apprécie pas du tout ces "spams", dit merde et se deconnecte. Alors que pour windows, pas soucis, on s'en fou et on garde la connexion.
╰─$ sudo tcpdump -v udp port 547
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
17:29:28.042192 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.043363 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.048584 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.055460 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.056595 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.061803 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
^C
3660 packets captured
3740 packets received by filter
0 packets dropped by kernel
-
3000 lignes en une seconde mdr du coup voici que les 10 premières.
Ce qui est "drole" avec ce soucis de "fuite" réseau, c'est que le macbook apprécie pas du tout ces "spams", dit merde et se deconnecte. Alors que pour windows, pas soucis, on s'en fou et on garde la connexion.
quelques commentaires :
- bolemo n'a pas évidemment pas rêvé concernant ce trafic fou côté WAN, d'autres le voient.
- ça ne devrait pas traverser la box de superpicsou. Soit elle est "cassée", soit le câblage est différent de ce que tu indiques.
- petite suggestion : désactiver IPv6 sur le Mac, car à ma connaissance IPv6 n'a pas été rétabli sur le réseau K-Net et donc ça ne sert à rien sur les postes. Ca n'empêchera pas le trafic d'arriver sur le LAN, mais ça soulagera peut-être le Mac.
- je ne propose évidemment pas de mettre une règle de filtrage sur cette box qui fait n'importe quoi.
-
3000 lignes en une seconde mdr du coup voici que les 10 premières.
Ce qui est "drole" avec ce soucis de "fuite" réseau, c'est que le macbook apprécie pas du tout ces "spams", dit merde et se deconnecte. Alors que pour windows, pas soucis, on s'en fou et on garde la connexion.
Last login: Fri Apr 8 16:36:41 on ttys001
╰─$ sudo tcpdump -v udp port 547
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
17:29:28.042192 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.043363 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.048584 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.055460 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.056595 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.061803 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
^C
3660 packets captured
3740 packets received by filter
0 packets dropped by kernel
CQFD…
Sinon, pour le coup, ça peut être un conflit ARP et/ou d'IP… Parce que ton LAN, il inclut toutes les machines présentent dans le GPON ! Et il y en a un paquet avec des adresses comme 192.168.1.1
J'avais fait un recensement il y a quelques années, avec un arpscan poussé (quand on le pouvait encore), et c'était ahurissant le nombre de machines qui sont dans le GPON et ne devraient pas y être… Des fuites LAN/WAN.
Donc pourquoi ton MacBook se déconnecte devient très difficile à diagnostiquer… Mais clairement, utilise le réseau 5GHz… Et je conseille fortement de faire pareil pour des autres appareils… Car pour l'instant, tout ce qui est sur ton LAN en ethernet et wifi 2,4 GHz est grand ouvert sur tout le GPON :-\
-
Car pour l'instant, tout ce qui est sur ton LAN en ethernet et wifi 2,4 GHz est grand ouvert sur tout le GPON :-\
Pour éviter que superpicsou fasse des cauchemars devant son réseau grand ouvert, précisons quand même que ce qu'on a vu sur les traces est du trafic broadcast ou multicast (IPv6), pas de l'unicast.
Ses machines ne sont a priori pas directement accessibles (faute de route vers 192.168.1.0/24 qui amènerait chez lui).
-
Bon bas en tout cas merci pour vos réponses et votre patience.
J'ai envoyé un mail recap à Knet pour qu'ils regardent ce qu'ils peuvent faire au niveau de ma box.
Je vais appliquer les rustines que vous avez proposé en attendant.
Merci
-
Pour éviter que superpicsou fasse des cauchemars devant son réseau grand ouvert, précisons quand même que ce qu'on a vu sur les traces est du trafic broadcast ou multicast (IPv6), pas de l'unicast.
Ses machines ne sont a priori pas directement accessibles (faute de route vers 192.168.1.0/24 qui amènerait chez lui).
Oui, seulement l'arp, le broadcast et le multicast passent (dans les deux sens), donc pas aussi grave que si tout l'unicast était visible, mais ça reste une grosse faille de sécurité…
Toutes les adresses MAC (et donc le type de matériel) du LAN sont visibles si elles utilisent arp… Les IPs, le type de logiciels (pour ceux qui font du boradcast/multicast)… Bref, pas mal d'info déjà.
En fait, on pourrait faire une app pour communiquer entre clients K-Net sur un même GPON via des paquets broadcast ou multicast ;D
-
Un netsend comme sur windows98, le rêve.
-
Si vous n'avez rien a perdre niveau config.
Reset par l'interface caps.
-
Bon bas en tout cas merci pour vos réponses et votre patience.
J'ai envoyé un mail recap à Knet pour qu'ils regardent ce qu'ils peuvent faire au niveau de ma box.
Je vais appliquer les rustines que vous avez proposé en attendant.
Merci
En espérant que tu te sens un peu moi fou que quand tu as ouvert ton post par :
Ca me rend fou, si quelqu'un à une idée, une solution, une piste.
En espérant aussi :
- que tu as appris quelque chose ... et que les futurs lecteurs aussi.
- que ce que tu as retranscrit de ces échanges à K-Net leur permettra de te trouver une solution (Je n'ai rien trouvé de probant sur ce type de problème avec un Icotera sur Internet)
- que K-Net te réponde rapidement
- que l'équipement "fou" en DHCPv6 sera vite mis hors d'état de nuire.
-
Si vous n'avez rien a perdre niveau config.
Reset par l'interface caps.
Cela ne semble pas résoudre le problème. Même après reset complet j'ai toujours du spam venant de l'extérieur.
En tout cas je ne sais pas si c'est lié mais depuis que ça spam mon réseaux, j'ai des soucis, notamment sur le chromecast qui ne gère pas le 5.0Ghz et du coup sur 2.4Ghz il perd tout le temps la connexion, c'est assez erratique. J'ai également certains lag sur mon local.
Je vais voir ce que dit le support ::)
[EDIT] "Vous êtes en place 27 dans la file d'attente" ... HA ;D
-
Cela ne semble pas résoudre le problème. Même après reset complet j'ai toujours du spam venant de l'extérieur.
En tout cas je ne sais pas si c'est lié mais depuis que ça spam mon réseaux, j'ai des soucis, notamment sur le chromecast qui ne gère pas le 5.0Ghz et du coup sur 2.4Ghz il perd tout le temps la connexion, c'est assez erratique. J'ai également certains lag sur mon local.
Je vais voir ce que dit le support ::)
[EDIT] "Vous êtes en place 27 dans la file d'attente" ... HA ;D
C'est typique des symptômes provoqués par ce spam… Même si les paquets DHCPv6 sont inoffensifs, leur quantité perturbe grandement le GPON, et votre LAN, puisqu'ils y passent. Chaque appareil reçoit 4 000 paquets par seconde, paquets qui doivent être écoutés, traités (netfilter), donc ça prend du CPU, et augmente la charge des interfaces, ça ralenti, fait perdre des paquets…
Votre cas est double pas de bol, car votre K-Box a clairement un problème de configuration en ne cloisonnant pas LAN/WAN, et par dessus, ce spam qui arrive en même temps.
Mais la cause des deux problèmes est possiblement commune (configs K-Box chez K-Net qui semblent corrompues à un moment avant d'arriver à certaines box…)
-
Votre cas est double pas de bol, car votre K-Box a clairement un problème de configuration en ne cloisonnant pas LAN/WAN, et par dessus, ce spam qui arrive en même temps.
Je n'arrive toujours pas à comprendre comment un routeur (la box) peut laisser passer le trafic du port WAN au port LAN et se comporter ainsi en pont. Problème de configuration "vérolée" ? problème de firmware altéré ? problème hardware ?
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.
-
Je n'arrive toujours pas à comprendre comment un routeur (la box) peut laisser passer le trafic du port WAN au port LAN et se comporter ainsi en pont. Problème de configuration "vérolée" ? problème de firmware altéré ? problème hardware ?
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.
C'est assez dingue oui…
Je ne connais absolument pas les spécifications des K-Box, mais cette histoire de mirroring n'est pas bête… Clairement, tout ou partie des ports ethernet LAN sont liés avec le wifi 2,4 GHz, et le wifi 5 GHz est séparé, peut-être avec une partie des ports ethernet.
Après, tout est possible, de la configuration corrompue (dans la base de donnée, dans sa transmission ou sa réception ?), au firmware dégradé en passant par un problème hardware (puce NAND défectueuse ?).
Si le problème DHCPv6 vient bien d'une K-Box (et non d'un relais fou), la thèse d'un problème de configuration se renforce… La MAC de la K-Box qui envoie apparemment ces trames est différente de celle qui était impliquée dans le même problème il y a plusieurs semaines…
Je ne comprends pas cependant quel type de corruption peut provoquer un emballement pareil (quel type de client DHCP répète un même SOLLICIT 4 000 fois par seconde ?), car à priori, même avec des données corrompues, un client DHCP n'est pas conçu dans son code pour envoyer autant de paquets ! Peut-être une erreur d'horloge ? Ou une corruption dans l'OS ? Ou encore le client enregistre une variable dans la nvram ou un fichier ram (/tmp), et se base dessus dans une boucle ? si la nvram, la ram ou le répertoire /tmp est corrompu ou compromis…
Parfois, je me demande s'il n'y a pas un malin qui a trouvé un backdoor sur les K-Box et veut nuire à K-Net… Je ne pense pas, mais je me suis posé la question.
-
C'est assez dingue oui…
J'ai cherché la semaine dernière (brièvement) si des problèmes de ce genre (DHCP requêtes folles ou fuite de paquets du WAN vers le LAN) étaient déjà arrivés sur des Icotera, je n'ai rien trouvé.
Un "factory reset" devrait régler ce genre d'incident (jusqu'à la fois suivante), mais je ne sais pas si c'est le "reset" fait par superpicsou pour le bug de son côté.
-
J'ai cherché la semaine dernière (brièvement) si des problèmes de ce genre (DHCP requêtes folles ou fuite de paquets du WAN vers le LAN) étaient déjà arrivés sur des Icotera, je n'ai rien trouvé.
Un "factory reset" devrait régler ce genre d'incident (jusqu'à la fois suivante), mais je ne sais pas si c'est le "reset" fait par superpicsou pour le bug de son côté.
Si c'est une puce nvram corrompue (problème matériel donc), un factory reset ne résoudra à priori rien…
Pareil si c'est une configuration corrompue envoyée, car dès que la K-Box se remettra en ligne, elle chargera la config défectueuse.
-
J'ai fais le factory reset depuis l'interface de l'icotera mais ça n'a rien changé.
-
Alors, j'ai réussi à avoir le hotline (après m'être fait kick en position 1 après 1H d'attente haha).
La dame au téléphone (très gentille d'ailleurs) n'a pas de notion technique donc à par prendre note elle ne savait pas trop.
A priori ils sont au courant que ya des soucis de spam sur le 14, plusieurs personnes semble être impactés. Les ingé ne reprennent le travail qu'à 14H donc elle va voir avec eux.
Elle m'expliquait qu'ils n'ont plus accès à leur outils de support donc peuvent pas suivre les demandes (aïe).
Et à priori ils suivent ce qui se dit sur lafibre.info ou alors quelqu'un lui en a parlé avant moi mais elle m'a parlé du soucis sur le forum ???
Bref, ça résout pas vraiment mon soucis à court terme mais bon.
Je vais voir sur Twitter si FB est pas en vacance et répond à ses DM ;D
-
Alors, j'ai réussi à avoir le hotline (après m'être fait kick en position 1 après 1H d'attente haha).
La dame au téléphone (très gentille d'ailleurs) n'a pas de notion technique donc à par prendre note elle ne savait pas trop.
A priori ils sont au courant que ya des soucis de spam sur le 14, plusieurs personnes semble être impactés. Les ingé ne reprennent le travail qu'à 14H donc elle va voir avec eux.
Elle m'expliquait qu'ils n'ont plus accès à leur outils de support donc peuvent pas suivre les demandes (aïe).
Et à priori ils suivent ce qui se dit sur lafibre.info ou alors quelqu'un lui en a parlé avant moi mais elle m'a parlé du soucis sur le forum ???
Bref, ça résout pas vraiment mon soucis à court terme mais bon.
Je vais voir sur Twitter si FB est pas en vacance et répond à ses DM ;D
Au moins, tu as confirmation que K-Net est informé de te on souci, ainsi que du problème du spam.
À partir de là, ils vont faire ce qu’ils peuvent, et au moins ton problème n’est pas sous leur radars.
J’essaye de garder la pression sur Altitude pour avoir une remontée d’info (sur le spam), mais il est possible qu’ils soient silencieux maintenant, car je ne suis pas leur client direct… On va voir s’il y a un changement et une ouverture vers plus de transparence.
-
Au moins, tu as confirmation que K-Net est informé de te on souci, ainsi que du problème du spam.
Et s'ils suivent les échanges sur ce forum, ils savent déjà où chercher.
À partir de là, ils vont faire ce qu’ils peuvent, et au moins ton problème n’est pas sous leur radars.
identifier par la MAC le client concerné, le contacter directement pour qu'il débranche électriquement sa box ... ça serait déjà un bon début.
J’essaye de garder la pression sur Altitude pour avoir une remontée d’info (sur le spam), mais il est possible qu’ils soient silencieux maintenant, car je ne suis pas leur client direct… On va voir s’il y a un changement et une ouverture vers plus de transparence.
Ca me sidère que les OI n'aient pas d'outil de supervision qui leur remonte une telle anomalie - pas nécessairement dans les détails, mais au minimum sur la charge réseau / CPU des équipements.
Ca leur permettrait d'être un minimum proactif dans ce genre de situation.
-
Bref, ça résout pas vraiment mon soucis à court terme mais bon.
Et sur la question des paquets qu'on ne devrait pas voir sur le LAN, elle transmet aussi ?
-
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
-
Petit retour de FB sur twitter
(https://i.ibb.co/ZM6St4P/Capture.jpg)
-
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é.
-
Il y a une option "port mirroring" sur la box. De mémoire dans avancé.
J'avais demandé la semaine dernière à superpicsou de vérifier que le port mirroring n'était pas activé (https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg942185/#msg942185)
-
Plus de résolution dns depuis samedi midi…
En attente de résolution :(
-
Petit retour de FB sur twitter
(https://i.ibb.co/ZM6St4P/Capture.jpg)
*sigh*
Je suis quasiment sûr que la solution était sur le forum caps.... :(
-
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 ??
-
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.
Bug rare mais connu des Icotera et un ticket était ouvert chez Icotera, il faut que K-Net désactive l'IPv6 et 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).
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…)
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.
-
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 ! :o
-
En tout cas j’ai l’impression que mon soucis ne va pas se régler rapidement…
Du coup trois solutions
- Passer sur un routeur perso, en espérant ne pas avoir de soucis de config et que les échanges avec knet pour le changement de mac se passe bien
- Etre patient avec un service limité. Pas d’ethernet, pas de wifi 2.4, pas de téléphone fixe mais toujours pour 40€ par mois
- Aller voir ailleurs, mais grosse flemme. Je suis client depuis 2017 et avant tout marchait bien navette.
-
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 ! :o
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.
-
Maintenant, ces bogues Icotera sont vraiment graves quand même ! :o
Tu n'as pas connu comme ces Icotera ne pouvait pas faire du NAT Dynmaique pour les consoles de jeux pendant 3 ans.
-
Ce matin c'est encore plus compliqué. Le wifi tiens pas, et la box non plus j'ai l'impression. J'ai du mal à accéder à l'interface de l'icotera.
Oups! Erreur interne du serveur.
Erreur retournée par le serveur: Unable to decode token. The error was:
ou
Oups! Erreur interne du serveur.
Erreur retournée par le serveur: 'NoneType' object has no attribute 'split'
On va passer sur la connexion ADSL pour le moment
-
Au moins j'ai récupéré la connexion, mais ca n'arrete pas de couper que ce soit en ethernet ou sur les 2 réseaux wifi. Je n'arrete pas de switcher toutes les 15 minutes. LOURD >:(
Comme Superpicsou, impossible d'aller sur la gestion de la box.
-
De retour du sav téléphonique.
Donc ouai, pas de solution vraiment à court terme. On est plusieurs à leur avoir passé les solutions de Vincent.
Mais ils semblent vouloir rester sur leur hypothèse d'un soucis au niveau du l'ONT Huawai et on ouvert un ticket chez covage pour demander le changement des boitiers.
Ce qui n'est pas tout à fait ce que FB disait. Il parlait lui plutôt de commander de Routeurs Huawai pour sortir l'icotera de l'équation. Donc leur discours n'est le même en interne.
J'imagine qu'on parle en semaine là et encore, en espérant que c'est bien de là que vient le soucis. Car ils semblent être en désaccord avec le fait que le soucis vienne de l'icotera.
::)
Knet Juin 2017 - Juillet 2021 -> Aucun soucis
Knet Mars/Avril 2022 en 1 mois -> 2 semaines sans wifi et accès à l'interface de la box / Ligne téléphonique toujours pas encore créé / Soucis de connexion depuis 5 jours
-
Problème de spam résolu ce matin à 8h : https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg943242/#msg943242
-
Effectivement. Plus de paquet reçu quand on regarde avec tcpdump -v udp port 547.
Aller y crois, maintenant mon soucis de LAN/WAN qui lui est toujours là !
Merci à toi en tout cas.
-
... et qui confirme ce qu'on a mis en évidence ici depuis plusieurs jours.
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.
known errors : Clairement, quand les employés clef de K-Net sont partis, rien n'avait été mis en place pour la transmission des informations, du savoir et de la connaissance de leur infrastructure.
firmware Icotera : Je doute aussi que K-Net ait développé quoi que ce soit en couche basse… Le MP de FB est intéressant et de bonne volonté de la part de FB, mais n'oublions pas qu'il n'est pas un ingénieur en télécom et ne fait que relayer ce qui lui a été dit par son ingénieur ; FB s'emmêle parfois les pinceaux dans les termes techniques, ou ce qui lui a été dit est approximatif…
Mais FB écoute et suite à mon tweet de cette nuit à 0h45 avec un lien vers le post de FB, le problème a disparu ce matin un peu avant 8h (ouverture des bureaux ?), le problème n'est pas FB qui ne l'oublions pas à lancé le K-Net qu'on aimait tous.
Maintenant, Superpicsou, plus qu'un seul problème… La bonne nouvelle est que le post de VincentO2 lu par FB mentionne aussi ce problème, donc il est dans le viseur de K-Net.
Soit tu patiente, et ça sera résolu, peut-être rapidement (espérons le !), peut-être un peu moins…
Soit, si tu souhaites encore rester chez K-Net, tu peux aller vers un routeur perso qui résoudra ce problème immédiatement. Pas besoin d'attendre pour donner une nouvelle MAC, tu peux cloner la MAC de ta K-Box sur le routeur perso. Si tu fais cela, pense à une solution pour la téléphonie (SPA112 ou autre).
-
Soit tu patiente, et ça sera résolu, peut-être rapidement (espérons le !), peut-être un peu moins…
Soit, si tu souhaites encore rester chez K-Net, tu peux aller vers un routeur perso qui résoudra ce problème immédiatement. Pas besoin d'attendre pour donner une nouvelle MAC, tu peux cloner la MAC de ta K-Box sur le routeur perso. Si tu fais cela, pense à une solution pour la téléphonie (SPA112 ou autre).
Il reste de nombreux (j'espère) clients de K-Net qui utilisent la K-Box v2. C'est mon cas (alors qu'évidemment je pourrais parfaitement prendre une solution personnelle), et ça fait partie de l'offre à laquelle j'ai souscrit et qui convient à mes besoins.
Donc, je souhaite vivement que ce problème K-Box soit réglé. Sinon, ça veut dire que tous les clients avec K-Box risquent un jour de subir la même mésaventure.
-
Il reste de nombreux (j'espère) clients de K-Net qui utilisent la K-Box v2. C'est mon cas (alors qu'évidemment je pourrais parfaitement prendre une solution personnelle), et ça fait partie de l'offre à laquelle j'ai souscrit et qui convient à mes besoins.
Donc, je souhaite vivement que ce problème K-Box soit réglé. Sinon, ça veut dire que tous les clients avec K-Box risquent un jour de subir la même mésaventure.
Ah, mais on est bien d'accord, il faut absolument que ce problème avec les Icotera soit résolu.
Je rappelais simplement à Superpicsou qu'il existe une solution pour rester chez K-Net et résoudre instantanément son problème, mais bien entendu, il ne doit considérer cette solution que si elle est vraiment intéressante pour lui, ses besoins internet et de réseau à la maison.
S'il peut attendre un peu, je suis sûr que son problème sera résolu.
-
Au moins on a récupéré une connexion hier matin. Cependant j'ai toujours des coupures intempestives. Es-ce que c'est le même problème pour toi Superpicsou ? Cela a un rapport avec icotera ?
-
Possible.
Moi je reçois du flux de l'extérieur sur mon réseau local, ce qui n'est pas sensé arrivé et ce qui produit pas mal de perturbation et perte de connexion.
Les appareils sous windows ne semble pas trop être dérangés (en ethernet). Par contre ceux sous macos et ios apprécient pas trop et je me retrouve avec plein de déconnexion, micro coupure ou perte de résolution DNS. Pareil au niveau du chromecast, lui il apprécie pas, la flux lag, et parfois il plante et redémarre tout seul.
Tu peux regarder le trafic qui arrive chez toi avec la commande suivante sous linux/unix
sudo tcpdump -ne arp
Et pareil sous windows en utilisant par exemple http://www.microolap.com/products/network/tcpdump/download/
Depuis la fin du spam DHCPv6 j'ai l'impression que c'est "mieux" dans le sens ou je me prend pas des deconnexions complètes, mais par contre ouai, pas mal de micro coupure où je suis obligé de brancher/debrancher la prise rj45 pour "retrouver" la connexion.
J'attend un peu de voir. Mais étant quelqu'un d'assez impatient, ça commence déjà à me fatiguer et j'ai commencé à regarder les autres offres. Notamment Free avec leur 10G-EPON (Pas sur que sur le réseau du 14 ça passe mais bon) + Nas + Répartiteur wifi
-
Tu peux regarder le trafic qui arrive chez toi avec la commande suivante sous linux/unix
sudo tcpdump -ne arp
J'aurais plutôt suggéré, puisqu'on a vu que c'était ce type de trafic qui "fuyait" :
sudo tcpdump -ne ether broadcast or ether multicast
ou éventuellement
sudo tcpdump -ne ether broadcast or ether multicast | grep -v 192.168.1
pour ne voir que les paquets extérieurs au réseau local, par défaut en 192.168.1.0/24 sur une K-Box. (Pour les puristes, le filtre grep n'est pas aussi précis qu'il le faudrait).
-
sudo tcpdump -ne ether broadcast or ether multicast
sudo tcpdump -ne ether broadcast or ether multicast 130 ↵
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
11:02:50.089269 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:50.429044 c4:04:15:5c:59:43 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c604:15ff:fe5c:5943 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:50.559843 00:1e:80:80:1d:3c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:324 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:50.994704 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
11:02:51.167760 84:1b:5e:da:07:97 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::861b:5eff:feda:797 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:51.240456 a0:ce:c8:e7:d4:23 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 86: 192.168.1.15.57621 > 192.168.1.255.57621: UDP, length 44
11:02:51.556508 00:1e:80:1d:7b:69 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:369 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:51.850348 c0:ff:d4:88:2e:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c2ff:d4ff:fe88:2e25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:51.994277 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
11:02:52.302876 00:1e:80:93:a9:84 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:302 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:52.850286 c0:ff:d4:88:2e:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c2ff:d4ff:fe88:2e25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:52.994412 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
11:02:54.346002 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
11:02:54.994359 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
11:02:55.210173 c0:ff:d4:88:2e:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c2ff:d4ff:fe88:2e25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:55.329558 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
11:02:55.445354 a4:2b:8c:92:87:6b > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:176 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:02:55.819222 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
11:02:56.198615 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.38706 > 224.0.0.251.5353: 10405 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
11:02:56.210141 c0:ff:d4:88:2e:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c2ff:d4ff:fe88:2e25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
^C
20 packets captured
46 packets received by filter
0 packets dropped by kernelsudo tcpdump -ne ether broadcast or ether multicast | grep -v 192.168.1
sudo tcpdump -ne ether broadcast or ether multicast | grep -v 192.168.1
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
11:03:05.122274 e8:fc:af:7b:4d:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe7b:4d25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:05.180401 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
11:03:05.332269 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
11:03:05.916799 c4:04:15:5c:59:43 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c604:15ff:fe5c:5943 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:06.122072 e8:fc:af:7b:4d:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe7b:4d25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:06.331304 00:1e:80:74:92:d8 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 173: fe80::21e:80ff:fe74:92d8.546 > ff02::1:2.547: dhcp6 renew
11:03:08.090866 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:08.347278 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
11:03:09.058254 00:1e:80:80:1d:3c > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 130: fe80::21e:80ff:fe80:1d3c > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
11:03:09.410066 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
11:03:10.347513 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
11:03:10.651923 e8:fc:af:7b:4d:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe7b:4d25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:10.683224 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 45.83.230.126.36593 > 224.0.0.251.5353: 19295 PTR (QM)? 21.0.168.192.in-addr.arpa. (43)
11:03:11.019380 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 45.83.230.126.39895 > 224.0.0.251.5353: 19307 PTR (QM)? 22.0.168.192.in-addr.arpa. (43)
11:03:11.435360 00:1e:80:80:1d:3c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:324 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:11.789693 b0:b9:8a:c1:5f:2f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 45.83.230.17, length 46
11:03:13.588159 00:1e:80:74:7b:98 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::21e:80ff:fe74:7b98 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:03:15.342234 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
11:03:16.217310 c4:04:15:5c:59:6d > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:e5 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:16.351815 e8:fc:af:7b:4d:25 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe7b:4d25 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:18.796584 c4:04:15:5c:59:43 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c604:15ff:fe5c:5943 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:18.808469 04:a1:51:d7:78:d1 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::6a1:51ff:fed7:78d1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:19.023960 00:1e:80:7b:90:e8 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::21e:80ff:fe7b:90e8 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
11:03:21.174697 a4:2b:8c:92:87:6b > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::a62b:8cff:fe92:876b > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:21.406054 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
11:03:21.416469 c4:04:15:5c:59:43 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::c604:15ff:fe5c:5943 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:22.091062 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:22.099262 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 45.83.230.126.48360 > 224.0.0.251.5353: 19311 PTR (QM)? 51.0.168.192.in-addr.arpa. (43)
11:03:22.174618 a4:2b:8c:92:87:6b > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::a62b:8cff:fe92:876b > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:22.211160 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 45.83.230.126.42266 > 224.0.0.251.5353: 19315 PTR (QM)? 155.0.168.192.in-addr.arpa. (44)
11:03:22.491306 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 45.83.230.126.53035 > 224.0.0.251.5353: 19325 PTR (QM)? 22.0.168.192.in-addr.arpa. (43)
11:03:25.125391 a0:ce:c8:e7:d4:23 > 33:33:ff:91:6f:e4, ethertype IPv6 (0x86dd), length 86: fe80::1cad:a9ba:b708:6d54 > ff02::1:ff91:6fe4: ICMP6, neighbor solicitation, who has fe80::120d:7fff:fe91:6fe4, length 32
11:03:25.345440 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
11:03:25.559734 00:1e:80:1d:7b:69 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:369 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:26.119772 a0:ce:c8:e7:d4:23 > 33:33:ff:91:6f:e4, ethertype IPv6 (0x86dd), length 86: fe80::1cad:a9ba:b708:6d54 > ff02::1:ff91:6fe4: ICMP6, neighbor solicitation, who has fe80::120d:7fff:fe91:6fe4, length 32
11:03:27.130048 a0:ce:c8:e7:d4:23 > 33:33:ff:91:6f:e4, ethertype IPv6 (0x86dd), length 86: fe80::1cad:a9ba:b708:6d54 > ff02::1:ff91:6fe4: ICMP6, neighbor solicitation, who has fe80::120d:7fff:fe91:6fe4, length 32
11:03:29.128921 e0:10:7f:2c:73:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Probe 185.238.5.252, length 46
11:03:30.133824 00:1e:80:80:1d:3c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:324 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:30.842680 84:1b:5e:da:0e:e5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.236.252, length 46
11:03:32.115892 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
11:03:33.695856 00:1e:80:7b:66:d0 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:29a > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:34.083110 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 45.83.230.126.53792 > 224.0.0.251.5353: 19347 PTR (QM)? 154.0.168.192.in-addr.arpa. (44)
11:03:34.092280 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:34.494534 00:1e:80:1e:78:71 > 33:33:ff:1e:78:71, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff1e:7871: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00:21e:80ff:fe1e:7871, length 24
11:03:35.269315 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
11:03:35.315533 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
11:03:35.355352 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
11:03:36.330111 00:1e:80:93:a9:84 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:302 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:36.349716 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
11:03:36.496395 10:0d:7f:91:6f:c5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::120d:7fff:fe91:6fc5 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
11:03:38.092436 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
^C101 packets captured
452 packets received by filter
0 packets dropped by kernel
Je n'ai qu'une seul machine de branchée et active actuellement sur le réseau (192.168.1.15)
-
sudo tcpdump -ne ether broadcast or ether multicast
...
11:02:50.994704 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
11:02:51.994277 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
11:02:52.994412 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
11:02:54.994359 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
...
Je n'ai qu'une seul machine de branchée et active actuellement sur le réseau (192.168.1.15)
Tu penses donc que les adresses que j'ai laissées dans la trace ci-dessus ne sont pas chez toi ?
De plus en plus fort, tu verrais donc les broadcasts de LAN d'autres clients K-Net ?
-
Aucune idée, encore une fois je n'ai pas les compétences techniques pour analyser ces flux.
Juste je comprend pas pourquoi ces requête sur des ip local qui n'existe pas chez moi. J'imagine que ya un lien avec le fait que mon réseau local pète les plombs, toutes ces déconnexion et le fait que j'ai du mal à accéder à la config de ma box. Mais encore une fois, simple supposition, aucune idée.
-
Il n'y a pas de moyen de limiter ces problèmes sur Mac le temps que ca soit corrigé coté KNET ?
On est d'accord que KNET est au courant de ces problèmes sur nos box ?
-
Il n'y a pas de moyen de limiter ces problèmes sur Mac le temps que ca soit corrigé coté KNET ?
On est d'accord que KNET est au courant de ces problèmes sur nos box ?
J'espère qu'ils sont au courant.
Perso, avec mon propre routeur Asus j'ai aussi des soucis de résolution DNS depuis samedi vers 14h.
2 appels à knet, réponse laconique.. j'informe nos ingénieurs...
-
Rappel sav téléphonique.
En gros ils avaient ouvert un ticket chez covage pour "perte de service" (donc plus d'internet, ce qui n'était pas mon cas). Avec la résolutions du soucis hier, Covage à clôturé tout les tickets pour ce problème.
Du coup, K-net refait un ticket à Covage pour "dégradation de service" et non plus perte. Et c'est tout.
Donc pour eux, toujours rien à voir avec l'icotera. C'est du côté de Covage.
Wait & See et patiente.
¯\_(ツ)_/¯
-
Rappel sav téléphonique.
¯\_(ツ)_/¯
S'ils t'ont donné un numéro de ticket en [K-NET#20220413xxxxxxx], envoie leur quand même les traces que tu obtiens par tcpdump en mettant ce numéro de ticket en sujet.
-
Tu penses donc que les adresses que j'ai laissées dans la trace ci-dessus ne sont pas chez toi ?
De plus en plus fort, tu verrais donc les broadcasts de LAN d'autres clients K-Net ?
Il y a toujours eu des paquets APIPA et en 192.168… qui traînent dans le GPON…
J'en avais détecté pas mal il y a quelques années, venant d'appareils divers et variés (deux Synology, des IOT genre thermostats, et autres interfaces et même une Freebox…)
Je pensais à l'époque que ça venait de quelqu'un qui avait mis son switch au mauvais endroit, mais c'était peut-être quelqu'un victime de de bogue Icotera…
À l'époque, VincentO2 qui était encore chez K-Net s'était penché sur la question, et la plus grosse difficulté pour K-Net était qu'ils n'ont pas accès au GPON, car ce qu'il s'y passe est filtré avant que ça leur parvienne et ils ne peuvent pas voir tous ces paquets ; je lui avais envoyé une base de donnée avec toutes les adresses MAC de ces appareils, et il a fait ce qu'il a pu, je crois en vain, ça n'avait jamais pu être résolu…
Il y avait tout un sujet dédié que j'avais ouvert sur le forum Caps…
Au final, entre les personnes qui établissent leur réseau incorrectement, ceux qui ont activé par mégarde ou négligence un port mirroring, ceux qui ont du matériel perso et ne savent pas l'utiliser, il y a toujours des fuites de certains LAN sur le GPON.
Mon routeur filtre déjà ces paquets, mais comme ils sont broadcast/multicast, ils forçaient mon routeur à utiliser plus de ressources que nécessaire.
Comme je suis puriste et que j'aime optimiser, j'ai établi des règles ebtables et iptables sur mon routeur pour filtrer tout cela au plus tôt :
root@HERMES:~$ ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 1, policy: ACCEPT
-i ethwan -j auth_macs
Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-i ethwan -j auth_macs
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Bridge chain: auth_macs, entries: 2, policy: ACCEPT
-s 20:e0:9c:53:7a:9 -j RETURN
-j DROP
20:e0:9c:53:7a:9, c'est la MAC de ma passerelle Covage.
Cela signifie que tout ce qui provient depuis le WAN d'un appareil avec une MAC différente de la passerelle Covage sur laquelle je suis relié est rejeté à l'entrée du routeur.
De plus, j'ai aussi cette règle iptables (et son équivalent en ip6tables que je ne mets pas ici pour ne pas surcharger) :
-P PREROUTING ACCEPT
-A PREROUTING -i brwan -m set ! --match-set brwan_in_auth dst -j DROP
Avec
root@HERMES:~$ ipset -L brwan_in_auth
Name: brwan_in_auth
Type: hash:ip
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xb7ec9594
Size in memory: 240
References: 1
Number of entries: 3
Members:
[MON IP]
255.255.255.255
[LE BROADCAST DE MON SOUS-RÉSEAU]
Cette combinaison iptables et ipset s'assure que tout paquet qui arrive du WAN qui n'est pas un broadcast global, un broadcast de mon sous-réseau ou destiné à mon adresse IP est automatiquement rejeté au plus tôt (la table raw étant la première, j'évite que les paquets indésirables polluent les règles suivantes dans les tables mangle, filter, etc…).
J'ai un peu simplifié mes règles ici à celle qui sont pertinentes… Elles sont un peu plus complexes, car j'accède à mon ONT pour du monitoring par exemple…
Et bien ça filtre en masse…
Voici par exemple le tcpdump depuis le routeur qui montre sur 2 secondes tout ce qui ne vient pas en broadcast ou multicast de ma passerelle Covage (donc qui est stoppé par ma règle ebtables) :
root@HERMES:~$ tcpdump -i ethwan -ne ether broadcast or ether multicast | grep -ve 20:e0:9c:53:7a:9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
13:32:31.781315 00:1e:80:74:7b:98 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fe74:7b98.546 > ff02::1:2.547: dhcp6 solicit
13:32:31.798841 00:1e:80:7b:90:e8 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fe7b:90e8.546 > ff02::1:2.547: dhcp6 solicit
13:32:31.802434 00:11:32:81:d5:f0 > 33:33:ff:7f:de:3e, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00:211:32ff:fe81:d5f0 > ff02::1:ff7f:de3e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe7f:de3e, length 32
13:32:32.130331 00:1e:80:27:e6:cc > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:14f4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
13:32:32.135705 00:1e:80:21:6c:85 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 222: fe80::21e:80ff:fe21:6c85.546 > ff02::1:2.547: dhcp6 request
13:32:32.216961 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
13:32:32.267601 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
13:32:32.291344 00:1e:80:8e:91:8c > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fe8e:918c.546 > ff02::1:2.547: dhcp6 solicit
13:32:32.346701 bc:a5:11:31:f7:ae > 33:33:ff:53:78:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980:132:1a1f::1 > ff02::1:ff53:7801: ICMP6, neighbor solicitation, who has fe80::22e0:9cff:fe53:7801, length 32
13:32:32.365227 10:0d:7f:91:6f:e4 > 33:33:ff:05:90:58, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00::1 > ff02::1:ff05:9058: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00:ea44:7eff:fe05:9058, length 32
13:32:32.411618 00:1e:80:21:6c:9d > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:301 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:32.482065 e8:fc:af:8f:1c:2d > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe8f:1c2d > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:32.512524 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
13:32:32.582659 28:c6:8e:92:4e:33 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:cf > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:32.770194 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
13:32:32.802215 00:11:32:81:d5:f0 > 33:33:ff:7f:de:3e, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00:211:32ff:fe81:d5f0 > ff02::1:ff7f:de3e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe7f:de3e, length 32
13:32:32.814336 00:1e:80:1d:7b:69 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:369 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:32.949325 00:1e:80:93:a9:84 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:302 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:32.965383 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:32.978816 e8:fc:af:8f:21:89 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.239.254 tell 2.59.237.58, length 46
13:32:33.149232 00:1e:80:80:1d:3c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:324 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:33.174286 00:1e:80:7f:57:e4 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fe7f:57e4.546 > ff02::1:2.547: dhcp6 solicit
13:32:33.230331 00:0e:58:f6:36:3e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 735: 192.168.1.58.50091 > 255.255.255.255.1900: UDP, length 693
13:32:33.231144 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
13:32:33.365320 10:0d:7f:91:6f:e4 > 33:33:ff:05:90:58, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00::1 > ff02::1:ff05:9058: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00:ea44:7eff:fe05:9058, length 32
13:32:33.439391 00:1e:80:a8:43:0c > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::21e:80ff:fea8:430c > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
13:32:33.441828 00:1e:80:a8:32:5c > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fea8:325c.546 > ff02::1:2.547: dhcp6 solicit
13:32:33.446576 00:1e:80:a8:43:0c > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::21e:80ff:fea8:430c > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13:32:33.452668 00:1e:80:a8:43:0c > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 110: fe80::21e:80ff:fea8:430c > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13:32:33.482128 e8:fc:af:8f:1c:2d > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe8f:1c2d > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:33.509182 00:1e:80:a8:43:0c > 33:33:ff:a8:43:0c, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ffa8:430c: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00:21e:80ff:fea8:430c, length 24
13:32:33.511056 bc:a5:11:31:f7:ae > 33:33:ff:53:78:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980:132:1a1f::1 > ff02::1:ff53:7801: ICMP6, neighbor solicitation, who has fe80::22e0:9cff:fe53:7801, length 32
13:32:33.520647 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
13:32:33.570631 00:1e:80:7f:5d:f0 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fe7f:5df0.546 > ff02::1:2.547: dhcp6 solicit
13:32:33.582909 28:c6:8e:92:4e:33 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:cf > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:33.609619 10:0d:7f:91:6f:c5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::120d:7fff:fe91:6fc5 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:33.630269 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
13:32:33.662852 00:1e:80:7b:66:d0 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:29a > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:33.772631 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
13:32:33.802278 00:11:32:81:d5:f0 > 33:33:ff:7f:de:3e, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00:211:32ff:fe81:d5f0 > ff02::1:ff7f:de3e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe7f:de3e, length 32
13:32:34.130456 00:1e:80:27:e6:cc > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:14f4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
13:32:34.216961 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
13:32:34.365258 10:0d:7f:91:6f:e4 > 33:33:ff:05:90:58, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00::1 > ff02::1:ff05:9058: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00:ea44:7eff:fe05:9058, length 32
13:32:34.411931 00:1e:80:21:6c:9d > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:301 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:34.506620 bc:a5:11:31:f7:ae > 33:33:ff:53:78:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980:132:1a1f::1 > ff02::1:ff53:7801: ICMP6, neighbor solicitation, who has fe80::22e0:9cff:fe53:7801, length 32
13:32:34.530550 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
13:32:34.583002 28:c6:8e:92:4e:33 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::2ac6:8eff:fe92:4e33 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:34.609682 10:0d:7f:91:6f:c5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::120d:7fff:fe91:6fc5 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:34.647389 2c:30:33:e6:0f:15 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::2e30:33ff:fee6:f15 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:34.747982 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.43756 > 255.255.255.255.29810: UDP, length 735
13:32:34.773224 00:11:32:76:4a:7a > 33:33:ff:8e:91:8e, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:fe76:4a7a > ff02::1:ff8e:918e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe8e:918e, length 32
13:32:34.808776 00:1e:80:93:a5:b8 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 222: fe80::21e:80ff:fe93:a5b8.546 > ff02::1:2.547: dhcp6 request
13:32:34.814493 00:1e:80:1d:7b:69 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:369 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:34.951137 00:1e:80:93:a9:84 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:302 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:34.965570 00:1e:80:38:76:1c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:363 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:35.039610 00:1e:80:9b:a2:b0 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 180: fe80::21e:80ff:fe9b:a2b0.546 > ff02::1:2.547: dhcp6 solicit
13:32:35.082378 e8:fc:af:8f:1c:2d > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe8f:1c2d > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:35.189032 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
13:32:35.213462 80:37:73:ee:26:ad > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::8237:73ff:feee:26ad > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:35.360572 00:1e:80:90:48:64 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.3 tell 0.0.0.0, length 46
13:32:35.480847 a4:2b:8c:92:87:6b > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:176 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:35.506651 bc:a5:11:31:f7:ae > 33:33:ff:53:78:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980:132:1a1f::1 > ff02::1:ff53:7801: ICMP6, neighbor solicitation, who has fe80::22e0:9cff:fe53:7801, length 32
13:32:35.527207 00:1e:80:80:1d:3c > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:324 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:35.540797 90:6c:ac:84:9e:e0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.185 tell 0.0.0.0, length 46
13:32:35.609650 10:0d:7f:91:6f:c5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::120d:7fff:fe91:6fc5 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:32:35.630581 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
^C68 packets captured
72 packets received by filter
0 packets dropped by kernel
La plupart de ces paquets sont normaux (en particulier les paquets DHCP (v4 ou v6) [du moment qu'ils ne sont pas spammés 4 000 fois par seconde ;D]) et auraient été bloqués plus loin par mon routeur qui ne les auraient pas routé vers mon LAN.
On voit des paquets anormaux comme 192.168.1.56 venant de la fuite WAN/LAN chez quelqu'un ou une mauvaise configuration de leur réseau ou paramètres, qui eux aussi auraient été bloqués plus loin par mon routeur. Ce sont d'ailleurs les mêmes paquets que Superpicsou voit arriver dans son LAN, puisqu'on est sur le même GPON.
Avec ces règles spécifiques, je bloque ces paquets le plus tôt possible ;)
-
Rappel sav téléphonique.
En gros ils avaient ouvert un ticket chez covage pour "perte de service" (donc plus d'internet, ce qui n'était pas mon cas). Avec la résolutions du soucis hier, Covage à clôturé tout les tickets pour ce problème.
Du coup, K-net refait un ticket à Covage pour "dégradation de service" et non plus perte. Et c'est tout.
Donc pour eux, toujours rien à voir avec l'icotera. C'est du côté de Covage.
Wait & See et patiente.
¯\_(ツ)_/¯
Ils semblent renvoyer la faute à Covage…
Je vois mal comment Covage peut être responsable de ton Icotera qui a un problème (matériel, logiciel ou mauvaise configs envoyées) :o
-
Pour ma part c'est de pire en pire les coupures. 2 coupures le temps d'écrire ce message... (et encore je n'ai pas encore validé)
-
Pour ma part c'est de pire en pire les coupures. 2 coupures le temps d'écrire ce message... (et encore je n'ai pas encore validé)
Cela semble être le cas, mais avez-vous vérifié que votre problème est le même que Superpicsou ?
Avez-vous pu effectuer la commande tcpdump -ne ether broadcast or ether multicast | grep -ve 192.168.1
Et constater la fuite de paquets WAN dans votre LAN ?
-
Haha j'allais venir dire la même chose. L'horreur. La connexion ne tiens pas. En tout cas le mac perd la connexion. Impossible de ping l'icotera en local
ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
c^C
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
et quand je tente un dump ça defile à fond
sudo tcpdump -ne ether broadcast or ether multicast 2 ↵
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
16:03:54.525060 e8:fc:af:8f:21:13 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe8f:2113 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
16:03:55.178294 00:11:32:81:d5:f0 > 33:33:ff:7f:de:3e, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00:211:32ff:fe81:d5f0 > ff02::1:ff7f:de3e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe7f:de3e, length 32
16:03:56.413957 00:1e:80:27:e6:cc > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:14f4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
16:03:56.926421 00:1e:80:9b:a2:b0 > 33:33:ff:73:9f:8b, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff73:9f8b: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00::a373:9f8b, length 24
16:03:57.129984 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
16:03:57.130568 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
16:03:59.051577 00:11:32:76:4a:7a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 2.59.236.229.137 > 2.59.239.255.137: UDP, length 50
16:03:59.130153 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
16:03:59.130430 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.55 tell 192.168.1.36, length 46
16:03:59.130874 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
16:04:00.513703 00:1e:80:32:5a:e5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:7a6 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
16:04:01.056335 00:11:32:76:4a:7a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 2.59.236.229.137 > 2.59.239.255.137: UDP, length 50
16:04:01.059313 00:11:32:76:4a:7a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 2.59.236.229.137 > 2.59.239.255.137: UDP, length 50
16:04:01.111044 00:1e:80:93:a9:84 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:302 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
16:04:02.005136 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.54757 > 224.0.0.251.5353: 24423 PTR (QM)? 192.168.1.168.in-addr.arpa. (44)
16:04:02.037913 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 92.118.99.232.34697 > 224.0.0.251.5353: 24425 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
16:04:02.789550 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60813 > 255.255.255.255.29810: UDP, length 735
16:04:03.062206 00:11:32:76:4a:7a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 2.59.236.229.137 > 2.59.239.255.137: UDP, length 50
16:04:03.065448 00:11:32:76:4a:7a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 225: 2.59.236.229.138 > 2.59.239.255.138: UDP, length 183
16:04:03.130081 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
16:04:04.481509 10:0d:7f:91:6f:c5 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::120d:7fff:fe91:6fc5 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
16:04:04.936343 e8:fc:af:8f:21:13 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:afff:fe8f:2113 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
16:04:05.309811 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 60: 185.4.76.115.51499 > 255.255.255.255.10001: UDP, length 4
16:04:05.312046 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.43538 > 255.255.255.255.60378: UDP, length 130
16:04:05.313125 18:e8:29:b8:7d:5c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 204: 2.59.238.99.53701 > 255.255.255.255.51499: UDP, length 162
16:04:05.313662 74:ac:b9:a2:11:dc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 182: 2.59.237.6.56590 > 255.255.255.255.51499: UDP, length 140
16:04:05.314135 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.56696 > 255.255.255.255.51499: UDP, length 130
16:04:05.314539 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 160: 192.168.1.26.47993 > 255.255.255.255.10001: UDP, length 118
16:04:05.314956 74:ac:b9:a2:09:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 175: 2.59.236.35.52585 > 255.255.255.255.51499: UDP, length 133
16:04:05.315367 74:ac:b9:a2:09:1e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 174: 45.83.231.233.40286 > 255.255.255.255.51499: UDP, length 132
16:04:05.315832 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 160: 192.168.1.26.34049 > 255.255.255.255.10001: UDP, length 118
16:04:05.316246 74:ac:b9:a2:1d:64 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 184: 185.202.61.191.39621 > 255.255.255.255.51499: UDP, length 142
16:04:05.316696 74:ac:b9:a2:06:c6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 182: 2.59.238.238.58074 > 255.255.255.255.51499: UDP, length 140
16:04:05.317120 18:e8:29:b8:7d:5c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 204: 2.59.238.99.58786 > 255.255.255.255.47993: UDP, length 162
16:04:05.317527 74:ac:b9:a2:1d:64 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 184: 185.202.61.191.53293 > 255.255.255.255.47993: UDP, length 142
16:04:05.317965 74:ac:b9:a2:11:dc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 182: 2.59.237.6.43868 > 255.255.255.255.47993: UDP, length 140
16:04:05.318412 68:72:51:2c:72:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 186: 192.168.1.55.49012 > 255.255.255.255.51499: UDP, length 144
16:04:05.318906 74:ac:b9:a2:09:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 175: 2.59.236.35.42494 > 255.255.255.255.47993: UDP, length 133
16:04:05.319313 18:e8:29:b8:7d:5c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 204: 2.59.238.99.34787 > 255.255.255.255.34049: UDP, length 162
16:04:05.319760 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.34176 > 255.255.255.255.35510: UDP, length 130
16:04:05.320222 74:ac:b9:a2:09:1e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 174: 45.83.231.233.37729 > 255.255.255.255.47993: UDP, length 132
16:04:05.320672 68:72:51:2c:72:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 186: 192.168.1.55.34652 > 255.255.255.255.51499: UDP, length 144
16:04:05.321115 74:ac:b9:a2:1d:64 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 184: 185.202.61.191.41998 > 255.255.255.255.34049: UDP, length 142
16:04:05.321590 68:72:51:2c:72:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 186: 192.168.1.55.36020 > 255.255.255.255.47993: UDP, length 144
16:04:05.322014 68:72:51:2c:72:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 186: 192.168.1.55.45257 > 255.255.255.255.34049: UDP, length 144
16:04:05.322466 74:ac:b9:a2:11:dc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 182: 2.59.237.6.56793 > 255.255.255.255.34049: UDP, length 140
16:04:05.322884 74:ac:b9:a2:09:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 175: 2.59.236.35.60798 > 255.255.255.255.34049: UDP, length 133
16:04:05.323323 74:ac:b9:a2:09:1e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 174: 45.83.231.233.49999 > 255.255.255.255.34049: UDP, length 132
16:04:05.323769 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.58135 > 255.255.255.255.43667: UDP, length 130
16:04:05.324207 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.56478 > 255.255.255.255.53149: UDP, length 130
16:04:05.328161 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.44637 > 255.255.255.255.47993: UDP, length 130
16:04:05.329765 74:ac:b9:a2:0b:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 172: 185.4.76.115.59211 > 255.255.255.255.34049: UDP, length 130
16:04:05.852721 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 45.83.230.126.40098 > 224.0.0.251.5353: 25847 PTR (QM)? 21.0.168.192.in-addr.arpa. (43)
16:04:05.872573 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.83.231.254 tell 45.83.228.34, length 46
16:04:05.980999 bc:a5:11:31:f7:ae > 33:33:ff:53:78:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980:132:1a1f::1 > ff02::1:ff53:7801: ICMP6, neighbor solicitation, who has fe80::22e0:9cff:fe53:7801, length 32
16:04:05.996420 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 45.83.230.126.38003 > 224.0.0.251.5353: 25852 PTR (QM)? 104.0.168.192.in-addr.arpa. (44)
16:04:06.332463 c4:41:1e:17:8e:00 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 45.83.230.126.34867 > 224.0.0.251.5353: 25864 PTR (QM)? 22.0.168.192.in-addr.arpa. (43)
16:04:06.979767 bc:a5:11:31:f7:ae > 33:33:ff:53:78:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980:132:1a1f::1 > ff02::1:ff53:7801: ICMP6, neighbor solicitation, who has fe80::22e0:9cff:fe53:7801, length 32
16:04:08.285607 00:1e:80:1d:7b:69 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:369 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
16:04:08.954979 10:0d:7f:91:6f:e4 > 33:33:ff:85:8a:5a, ethertype IPv6 (0x86dd), length 86: 2a03:4980:200:4a00::1 > ff02::1:ff85:8a5a: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00:423f:8cff:fe85:8a5a, length 32
16:04:09.129770 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
16:04:09.130213 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
16:04:09.131633 00:11:2a:22:48:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 62: 2.59.236.124.49150 > 255.255.255.255.49152: UDP, length 20
16:04:10.129923 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
16:04:10.424511 00:1e:80:27:e6:cc > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::21:0:14f4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
16:04:11.127831 00:1e:80:93:a9:84 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::1a:0:302 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
16:04:11.129805 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
16:04:11.130134 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.55 tell 192.168.1.36, length 46
16:04:11.130611 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
16:04:11.688874 ac:84:c9:45:99:b2 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x887b), length 60:
0x0000: 0102 0400 0487 1000 0000 0000 0000 0000 ................
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
^C
70 packets captured
163 packets received by filter
0 packets dropped by kernel
ya des lignes bien chelou genre en seconde 5 (timestamp 16:04:05) je me prend je sais pas combien de truc sur le broadcast. C'est pas sensé être un truc pour les sous réseau local ?
Puis les lignes de ce genre
16:02:45.648139 ac:84:c9:45:99:b2 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x887b), length 60:
0x0000: 0102 0400 0487 1000 0000 0000 0000 0000 ................
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
Bref le réseau il aime pas du tout. Retour sur la connexion ADSL avant de péter un plomb.
-
@superpicsou (et éventuellement les autres)
Dans ta trace de ce matin, le trafic qu'on voyait ce matin était faible (~5 paquets par seconde), ça n'est pas ça qui peut mettre en difficulté ton Mac. Contrairement à la situation où il y avait le trafic DHCPv6 ...
Je te propose une explication possible des "pertes de connexion" que tu subis:
On a vu (confirmé par bolemo dans des observations précédentes) qu'il pouvait y avoir des paquets avec ton adresse réseau LAN (192.168.1) mais ne t'appartenant pas qui arrivent quand même chez toi.
Il se peut donc qu'un équipement avec la même adresse IPv4 que ton Mac fasse des requêtes ARP, ce qui crée de facto une duplication d'adresse IP sur ton LAN.
C'était une hypothèse que j'avais déjà avancée la semaine dernière (d'où la suggestion de faire un tcpdump sur le protocole ARP).
Si c'est ça, et pour tenter d'éviter le phénomène, essaie de configurer ton Mac avec une autre adresse plus improbable (par exemple en essayant successivement .254, .253, .252 etc).
-
La plupart de ces paquets broadcast sont normaux (dans le GPON en s'entend, pas dans votre LAN). Ce sont surtout des clients DHCP (v4 et v6) qui cherchent à renouveler leur bail.
Cela se fait en broadcast, même si un client DHCP bien foutu devrait faire une demande de renouvellement en unicast…
Ce qui est absolument anormal et problématique, c'est que cela se retrouve dans votre LAN
Je viens de voir passer la réponse de pju91, et je pense aussi que c'est plutôt quelque chose comme ça… Une IP commune ou même une MAC commune…
Pouvez-vous mettre votre Mac en configuration IP statique et se passer totalement du DHCP entre la K-Box et votre Mac ? Ça pourrait déjà permettre une stabilité de la connexion dessus… Et qu'en est-il d'utiliser le wifi 5 GHz qui lui était protégé de la fuite ?
-
Ok bas je vais changer l'ip local de la box ainsi que la plage d'ip. J'ai fourni l'ensemble des dump à K-net. On verra.
-
Ok bas je vais changer l'ip local de la box ainsi que la plage d'ip. J'ai fourni l'ensemble des dump à K-net. On verra.
Oui, c'est encore mieux si tu changes la configuration LAN de ta box (mais je croyais que tu avais des soucis pour la reconfigurer).
Dans ce cas, tu peux carrément changer de plage en restant sur les blocs du RFC 1918. Par exemple tu choisis un 10.x.y.0/24.
-
Ok bas je vais changer l'ip local de la box ainsi que la plage d'ip. J'ai fourni l'ensemble des dump à K-net. On verra.
Changer la plage d'IP local de la box, c'est une très bonne idée… Ça réduira considérablement les risques de collision d'IP communes entre ton LAN et les autres LANs qui fuient sur le GPON…
Reste le risque de collision MAC, qui reste quand même assez faible… Si c'était le cas : https://www.alphr.com/change-mac-address-in-macos/
-
(mais je croyais que tu avais des soucis pour la reconfigurer).
J'ai du mal à accéder au panel de configuration de la box depuis la connexion K-net. Mais depuis mon ADSL Bouygue pas de soucis. Du coup j'ai reconfiguré par là. Je vous redis si ça tiens ou pas comme ça.
-
Reste le risque de collision MAC, qui reste quand même assez faible… Si c'était le cas : https://www.alphr.com/change-mac-address-in-macos/
[mode ancien combattant]
Je me souviens du bon temps, il y a longtemps, où il y avait garantie d'unicité des adresses MAC :(
Bon, en même temps, à cette époque, il n'y avait ni FTTH, ni smartphones, etc.
[/mode ancien combattant]
superpicsou : Le risque est effectivement très faible, tu as plus à gagner qu'à perdre à tenter la renumérotation de ton LAN.
-
Dès que j'aurai terminé ma réunion je teste la commande terminal. Je vais aussi changer la plage IP de la box. Cependant quelle plage vous conseilleriez ? A savoir qu'il est hors de question de passer sur du 192.168.2.xxx
Vu que je switch régulièrement sur l'ADSL, j'ai eu trop de galères avec la box 4G avec cette différence de plage.
Par ex la plage 192.168.155 -> 192.168.1.255 ?
Merci pour votre aide.
EDIT : Même en ADSL, je n'arrive pas à accéder à la configuration, donc le sujet risque d'être plutot vite réglé...
-
Dès que j'aurai terminé ma réunion je teste la commande terminal. Je vais aussi changer la plage IP de la box. Cependant quelle plage vous conseilleriez ? A savoir qu'il est hors de question de passer sur du 192.168.2.xxx
Vu que je switch régulièrement sur l'ADSL, j'ai eu trop de galères avec la box 4G avec cette différence de plage.
Par ex la plage 192.168.155 -> 192.168.1.255 ?
Merci pour votre aide.
EDIT : Même en ADSL, je n'arrive pas à accéder à la configuration, donc le sujet risque d'être plutot vite réglé...
Essayez une plage qui a peu de chance d'être utilisée. 192.168.155.1 avec un masque 255.255.255.0 est une bonne idée, ou quelque chose comme 10.14.128.1 avec un masque 255.255.255.0
Il faut que les adresses soient dans ces plages : https://en.wikipedia.org/wiki/Private_network
Evitez les plages 10.2.X.X et 172.X qui sont utilisées par les routeurs Covage et K-Net.
-
J'ai n'ai pas eu de déconnexion depuis que j'ai fais les changements. Hasard ou réelle solution ? On verra sur le long terme !
-
J'ai n'ai pas eu de déconnexion depuis que j'ai fais les changements. Hasard ou réelle solution ? On verra sur le long terme !
On croise les doigts.
Sans être indiscret, tu as pris quel numéro de réseau ? C'est pour éviter que d'autres comme phenomens prenne le même préfixe réseau.
-
J'ai n'ai pas eu de déconnexion depuis que j'ai fais les changements. Hasard ou réelle solution ? On verra sur le long terme !
C'est cohérent, et ça confirme nos soupçons sur les problèmes de déconnexion.
C'est donc (sous réserve que ça tienne) une réelle solution, qui permet que ton LAN fonctionne correctement malgré le problème de la K-Box.
-
Je suis pas aller très loin par flemme. J'ai juste mis 192.168.1.200 pour la box et j'ai fixé une plage ip pour les équipements de 201 à 250.
Par contre je viens d'aller voir dans la config de la box et je viens de voir que les paramètres se sont remis par défaut... ::)
-
Pour ma part j'ai actualisé 100x la page, j'ai jamais réussi à y aller.
-
Bon petit retour d'expérience du coup.
J'ai passé ma box en 192.168.254.199 avec une plage ip 192.168.254.200 à 250. La box recalcule toute seule le masque, c'est cool pour les flemmards.
Et du coup plus de soucis, visible assez instantanément. Plus de lag en local, plus de crash de connexion, plus de perte de wifi ou de signal avec la box.
L'hypothèse d'un conflit d'ip est très fortement probable.
D'après les dumps et pour ceux qui ont des soucis. Evitez les plages qui commencent comme ça, c'est ce que je vois passer le plus.
192.168.1.X
185.238.4.X
192.168.156.X
172.16.100.X
Yen a et yen aura surement d'autre. Sans parler les ip public des autres clients knet et autres (CIKTEL-CABLE ?)
En tout cas le flux entrant lui ne s'arrête pas. Mais au moins ça évite les déconnexion du réseaux et les micros coupure.
-
@Suoperpicsou : Comment as-tu réussi à accéder à la configuration de la box ? Peut importe quand j'essaie j'ai toujours la même erreur :-\
Et l'accès en local ne fonctionne pas sur ces box, ce qui est une grosse connerie selon moi...
-
L'avantage de K-net (comme pour free) c'est que la configuration de la box se fait en ligne et tu peux donc y accéder depuis n'importe où.
Essaye de t'y connecter depuis tas connexion ADSL ou 4G. Moi j'avais du mal depuis la connexion k-net.
Après vérifie que tu es bien connecté à ton espace client : https://espace-client.k-net.fr/ sinon tu ne peux pas accéder à la configuration si tu vas direct sur https://mykbox.caps.services/?s=[id] sans avoir la session ouverte.
-
Petite tentative pour résumer les investigations et les échanges depuis une semaine
7 avril
- superpicsou indique une coupure "à cause de la résolution DNS" qui échoue - mais avec des circonstances bizarres
- vivien, bolemo, pju91 aident superpicsou à diagnostiquer la résolution DNS
8 avril
- superpicsou constate que son MAC perd en fait complètement la connexion
- pju91 évoque une possible duplication d'adresse IP
- superpicsou poste des traces réseau, bolemo et pju91 l'aident à affiner la trace et à diagnostiquer
- pju91 remarque des adresses IP qui n'ont rien à faire sur le LAN de superpicsou, bolemo confirme
- pju91 suggère de vérifier la topologie du réseau et la configuration de la box. RAS
- le lien est fait par superpicsou et bolemo avec l'incident "spam GPON 14 et 91". bolemo n'est pas concerné par la fuite WAN => LAN, car il a un équipement robuste, mais constate le même type de paquet broadcast et multicast côté WAN
- superpicsou est donc "victime" de 2 incidents distincts 1/ le spam GPON et 2/ sa une box fuyarde WAN=>LAN (mais pas toutes les interfaces, le WIFI 5 GHz ne semble pas concerné). bolemo suggère comme cause aux pertes de connexion du Mac la duplication d'adresse IP (même adresse en 192.168.1
- thedark suggère de faire un "reset" de la box, pour tenter resoudre 2/ - sans succès
11 avril
l'incident est bien cerné (nombreux échanges à ce sujet). VincentO2 (ancien de K-Net) confirme que ce sont 2 bugs connus, pour lesquels dans le passé des tickets ont été ouverts chez Icotera et pour lesquels K-Net dispose de "work-arounds".
12 avril
- résolution de l'incident "spam" ; phenomens est aussi concerné par les déconnexions intempestives
- "divagations" de K-Net sur Huawai, pas très claires.
13 avril
- superpicsou et phenomens ont toujours des déconnexions
- sur des traces de superpicsou, pju91 relève des adresses en 192.168.1 qui n'appartiennent pas au LAN de superpicsou, bolemo confirme qu'il a toujours vu des paquets APIPA (169.254) et 192.168 qui trainent sur le WAN. VincentO2 avait tenté d'investiguer ...
- pju91 revient sur l'idée d'une duplication IP et propose de prendre pour le Mac de superpicsou une adresse IP peu probable sur le réseau 192.168.1. superpicsou envisage aussi de changer de numéro de réseau, pju91 et bolemo lui font quelques suggestions.
- superpicsou change d'IP sur le réseau 192.168.1, ça semble fonctionner
14 avril
superpicsou a changé sa plage réseau, ce qui offre a priori de plus faibles risques de duplication d'adresse IP, ça semble fonctionner
A suivre ?
-
Très bon résumé 8)
Y'a plus qu'a changé le titre du topic pour qu'il soit plus parlant pour les gens qui ont des problèmes de déconnexion/micro-coupure chez K-net.
A préciser que ces soucis ont l'aire d'impacter plus facilement les appareils sous macos / ios / android que ceux sous windows.
(https://c.tenor.com/67EGa-wMf5MAAAAM/sherlock-benedict-cumberbatch.gif)
-
Bien joué pju91
A savoir que je n'ai pas changé de plage d'IP et que mis à part une coupure ce matin vers 7-8h, je n'ai eu aucune coupure en wifi. Je ne suis pas resté sur l'ethernet car ca avait l'air de déconner vers 9h. Je suis de nouveau dessus et ca continue de déconner, mais beaucoup moins qu'hier.
@Superpicsou : j'ai passé mon après-midi hier sur l'ADSL et impossible d'accéder à la config de la box. Et j'étais bien connecté à l'espace client. et j'ai essayé avec plusieurs navigateurs, sans succès ni en ADSL ni en fibre, idem ce matin.
-
Bien joué pju91
A savoir que je n'ai pas changé de plage d'IP et que mis à part une coupure ce matin vers 7-8h, je n'ai eu aucune coupure en wifi. Je ne suis pas resté sur l'ethernet car ca avait l'air de déconner vers 9h. Je suis de nouveau dessus et ca continue de déconner, mais beaucoup moins qu'hier.
@Superpicsou : j'ai passé mon après-midi hier sur l'ADSL et impossible d'accéder à la config de la box. Et j'étais bien connecté à l'espace client. et j'ai essayé avec plusieurs navigateurs, sans succès ni en ADSL ni en fibre, idem ce matin.
Bien résumé @pju91 ;)
Sinon, à priori pas de problèmes d'accès à l'espace client ou config de la box, à part une coupure récente entre 12h15 et 12h25… :
(https://i.ibb.co/XXpP3fw/Capture-d-cran-2022-04-14-12-35-27.png)
(https://i.ibb.co/9y8SFLx/Capture-d-cran-2022-04-14-12-35-40.png)
Donc si tu as accès à ton espace client, mais pas la configuration de la box, ça semble être spécifique à toi plutôt qu'un problème général…
As-tu essayé en 4G et/ou avec un VPN ? Si rien ne fonctionne, alors l'accès aux configs de ta box a un problème chez K-Net.
-
Oui bolemo j'ai bien accès à l'espace client mais pas à la config de ma box. Même derrière un VPN. J'ai toujours le même message :
Oups! Erreur interne du serveur.
Erreur retournée par le serveur: 'NoneType' object has no attribute 'split'
Et toujours quelques coupures par-ci par-là. En ethernet, il suffit que j'indique à mon mac de renouveler le bail DHCP et ca revient. Parfois cela revient avant que j'ai besoin de le faire. C'est plus soft que depuis lundi.
-
Oui bolemo j'ai bien accès à l'espace client mais pas à la config de ma box. Même derrière un VPN. J'ai toujours le même message :
Oups! Erreur interne du serveur.
Erreur retournée par le serveur: 'NoneType' object has no attribute 'split'
Et toujours quelques coupures par-ci par-là. En ethernet, il suffit que j'indique à mon mac de renouveler le bail DHCP et ca revient. Parfois cela revient avant que j'ai besoin de le faire. C'est plus soft que depuis lundi.
Est-il possible de mettre votre Mac en configuration IP fixe ?
Dans préférences système -> réseau -> aller sur avancé… puis TCP/IP
Puis de là essayez 'Manuellement' dans le menu déroulant, en laissant le sous-réseau (j'imagine 255.255.255.0) et le routeur (j'imagine 192.168.1.1), mais en choisissant une adresse IPv4 sur votre sous-réseau, par exemple 192.168.1.196
-
Oui bolemo j'ai bien accès à l'espace client mais pas à la config de ma box. Même derrière un VPN. J'ai toujours le même message :
Oups! Erreur interne du serveur.
Erreur retournée par le serveur: 'NoneType' object has no attribute 'split'
Pareil pour moi ce matin. C'est nouveau!
-
Pareil pour moi ce matin. C'est nouveau!
C'est peut-être bon signe… Si cela est une conséquence du fait qu'ils travaillent sur l'interface des K-Box et les problèmes de configuration !
J'ai l'impression maintenant et étant informé de cette situation, qu'à part la téléphonie, la plupart des problèmes que rencontrent les clients K-Net depuis un moment (déconnexions, instabilités…) sont liés à ces bogues Icotera…
-
https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg943750/#msg943750
K-Net semble apprendre et devient efficace 8)
Espérons que ça va être le cas avec ce problème de fuite WAN/LAN :)
-
Malgré le changement d'IP vers une ip fixe sur mon mac en ethernet : 1.196 ou 1.235 ou encore 1.254, j'ai eu 3 coupures en 30 minutes...
@bolemo, j'espère que cela va se résoudre efficacement. C'est vraiment très lourd...
-
Tente le sav téléphonique pour qu'ils fassent la modification d'ip pour toi au pire.
(conseil, si ya plus de 16/18 personnes dans la file, tu peux raccrocher.)
-
Avant d'aller plus loin @phenomens, je n'ai pas vu ta réponse à ceci (je l'ai peut-être manquée) : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943548/#msg943548
Juste pour être sûr à 100% que ton problème est identique à celui de Superpicsou.
Ensuite, très bonne suggestion de @Superpicsou pour que K-Net change depuis chez-eux ta plage IP LAN…
Sinon, de quel matériel disposes-tu ? Seulement K-Box et Mac ou as-tu d'autres appareils ?
– Tu pourrais par exemple avoir un PC relié à la K-Box en ethernet, et faire du partage de connexion en Wifi et connecter ton Mac sur le PC ainsi.
– Ou encore connecter directement ce PC en ethernet sur l'ONT et cloner la MAC de la K-Box sur l'interface du PC et faire du partage de connexion Wifi.
– Si tu as un vieux routeur perso qui traîne, tu pourrais le remettre en service temporairement…
– Ou encore si tu n'utilises que ton Mac, le relier directement en ethernet à l'ONT (en faisant le clonage de l'adresse MAC de la K-Box sur ton Mac en suivant le lien que j'avais posté hier, mais en faisant bien attention de l'attribuer à l'interface ethernet du Mac, pas l'interface Wifi).
-
C'est peut-être bon signe… Si cela est une conséquence du fait qu'ils travaillent sur l'interface des K-Box et les problèmes de configuration !
L'interface k-box est revenue.
-
Avant d'aller plus loin @phenomens, je n'ai pas vu ta réponse à ceci (je l'ai peut-être manquée) : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943548/#msg943548
Juste pour être sûr à 100% que ton problème est identique à celui de Superpicsou.
Pour voir si @phenomens est bien pollué par des adresses IP en 192.168.1 qui ne lui appartiennent pas, autant inverser le grep :
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
Ensuite, très bonne suggestion de @Superpicsou pour que K-Net change depuis chez-eux ta plage IP LAN…
Encore faut-il parvenir à les joindre ...
Sinon, de quel matériel disposes-tu ? Seulement K-Box et Mac ou as-tu d'autres appareils ?
– Tu pourrais par exemple avoir un PC relié à la K-Box en ethernet, et faire du partage de connexion en Wifi et connecter ton Mac sur le PC ainsi.
– Ou encore connecter directement ce PC en ethernet sur l'ONT et cloner la MAC de la K-Box sur l'interface du PC et faire du partage de connexion Wifi.
– Si tu as un vieux routeur perso qui traîne, tu pourrais le remettre en service temporairement…
– Ou encore si tu n'utilises que ton Mac, le relier directement en ethernet à l'ONT (en faisant le clonage de l'adresse MAC de la K-Box sur ton Mac en suivant le lien que j'avais posté hier, mais en faisant bien attention de l'attribuer à l'interface ethernet du Mac, pas l'interface Wifi).
Dans ta dernière option (si elle est envisageable, selon la configuration des lieux), le MAC aura l'adresse IP publique actuellement prise par la box, donc unique.
Est-ce que du coup le MAC peut être "routeur" WAN / WiFi pour les autres équipements du réseau de @phenomens
? J'imagine que oui ...
-
L'interface k-box est revenue.
Bonne nouvelle. Par contre ça ne semble pas être dû à un correctif de notre problème.
15:09:23.525393 00:11:32:81:xx:xx > 01:00:5e:00:xx:xx, ethertype IPv4 (0x0800), length 168: 45.83.xxx.x.5353 > 224.0.x.xxx.5353: 0 [4q] SRV (QM)? MacBook Pro de Romary (2)._airplay._tcp.local. TXT (QM)? F4D4885E04FD@MacBook Pro de Romary (2)._raop._tcp.local. SRV (QM)? F4D4885E04FD@MacBook Pro de Romary (2)._raop._tcp.local. TXT (QM)? MacBook Pro de Romary (2)._airplay._tcp.local. (126)
Je vois des copain sur le réseaux c'est sympa. Ca explique ptet aussi pourquoi les mac ont plus de soucis.
AirPlay does not require any configuration to be able to find compatible devices on the network, thanks to [DNS-based service discovery], based on [Multicast DNS], aka Bonjour.
-
Dans ta dernière option (si elle est envisageable, selon la configuration des lieux), le MAC aura l'adresse IP publique actuellement prise par la box, donc unique.
Est-ce que du coup le MAC peut être "routeur" WAN / WiFi pour les autres équipements du réseau de @phenomens
? J'imagine que oui ...
C'est exactement ça. Et oui, le Mac peut partager la connexion : https://support.apple.com/fr-ca/guide/mac-help/mchlp1540/mac
J'ai l'impression qu'il y a un petit paquet de K-Box qui fuient en fait…
-
Je vois des copain sur le réseaux c'est sympa. Ca explique ptet aussi pourquoi les mac ont plus de soucis.
Ta nouvelle trace me plaît bien. Les adresses multicast en 224 sont définies comme "locales au lien". Là, tu vois un Mac (ailleurs que chez toi) qui fait du Multicast DNS (mDNS, port 5353).
Est-ce un MAC directement branché sur le WAN ? Ou bien est-ce un MAC derrière un routeur qui fuit dans le sens LAN => WAN ?
Il faut poser la question un ami. bolemo?
-
Ta nouvelle trace me plaît bien. Les adresses multicast en 224 sont définies comme "locales au lien". Là, tu vois un Mac (ailleurs que chez toi) qui fait du Multicast DNS (mDNS, port 5353).
Est-ce un MAC directement branché sur le WAN ? Ou bien est-ce un MAC derrière un routeur qui fuit dans le sens LAN => WAN ?
Il faut poser la question un ami. bolemo?
Quelqu'un veut gagner des millions ici ? ;D
Je n'ai pas la réponse, mais soit beaucoup de monde a des configs réseau très curieuses (switches avant routeurs, appareils reliés au WAN…), soit il y a pas mal de routeurs qui fuient…
Si je pense qu'il existe effectivement quelques réseaux LAN mal conçus qui en conséquence fuient sur le WAN, je pense que cela reste rare et donc une très petite minorité… De plus, statistiquement, ceux qui ont un tel matériel s'y connaissent un minimum dans ce domaine et savent donc évider ces grossières erreurs.
Les routeurs perso ne fuient pas… Et quelqu'un qui a un routeur perso, comme dans le premier point, s'y connais en principe suffisamment pour ne pas provoquer de fuite (il faudrait pour cela manuellement altérer les configurations qui par défaut ne provoquent pas de telles fuites).
On sait aussi que le GPON que l'on peut voir sur nos WAN ne concerne que les clients de K-Net. Il n'y a pas de fuite entre opérateurs au niveau de Covage.
Le plus probable, c'est que cela provient d'Icoteras qui ont ce bogue de fuite.
Superpicsou, soit ce MacBook Pro de Romary que tu vois est celui de phenomens, et vous êtes donc 2 clients avec ce problème (probablement un peu plus puisqu'il y a d'autres paquets privés qui ne sont à aucun de vous deux), soit c'est encore quelqu'un d'autre… Et là, on est déjà à au moins 3 (et probablement plus) clients, rien que dans notre GPON… C'est statistiquement élevé quand même !
Je pense vraiment que c'est un problème beaucoup moins rare qu'on ne le pense, et la source de bien des soucis rencontrés par les clients K-Net ces derniers temps…
La bonne nouvelle, c'est que résoudre la cause de ce problème devrait résoudre bien des symptômes d'un coup.
-
Un dump de plusieurs secondes avec comme filtre "192.168" implique en particulier deux interfaces MAC qui sont très bavardes sur le GPON :
root@HERMES:~$ tcpdump -i ethwan -v broadcast or multicast | grep -ie 192.168
tcpdump: listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
232-99-118-92.ftth.cust.kwaoo.net.60643 > 224.0.0.251.mdns: 15767 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.59791 > 224.0.0.251.mdns: 15768 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.39969 > 224.0.0.251.mdns: 15769 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.35327 > 224.0.0.251.mdns: 15770 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.56776 > 224.0.0.251.mdns: 15771 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
232-99-118-92.ftth.cust.kwaoo.net.37592 > 224.0.0.251.mdns: 15772 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
16:11:29.983038 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
192.168.1.36.10101 > 224.0.0.250.10101: UDP, length 38
16:11:33.983226 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.25 tell 192.168.1.36, length 46
16:11:33.983257 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:11:34.982976 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.56 tell 192.168.1.36, length 46
192.168.1.56.46833 > 255.255.255.255.29810: UDP, length 735
16:11:37.983069 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:11:37.983226 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:11:37.983413 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:11:39.066387 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.36 tell 192.168.1.36, length 46
16:11:39.149830 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.36 tell 192.168.1.36, length 46
232-99-118-92.ftth.cust.kwaoo.net.42087 > 224.0.0.251.mdns: 15773 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.42336 > 224.0.0.251.mdns: 15774 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.47388 > 224.0.0.251.mdns: 15775 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.33524 > 224.0.0.251.mdns: 15776 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.38723 > 224.0.0.251.mdns: 15777 PTR (QM)? 192.168.1.185.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.42804 > 224.0.0.251.mdns: 15778 PTR (QM)? 192.168.1.185.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.43813 > 224.0.0.251.mdns: 15779 PTR (QM)? 192.168.1.120.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.34557 > 224.0.0.251.mdns: 15780 PTR (QM)? 192.168.1.120.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.48948 > 224.0.0.251.mdns: 15781 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
232-99-118-92.ftth.cust.kwaoo.net.47230 > 224.0.0.251.mdns: 15782 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
16:11:41.983101 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
16:11:42.436771 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 (Broadcast) tell 192.168.1.26, length 46
16:11:45.983132 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.25 tell 192.168.1.36, length 46
16:11:46.983351 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.56 tell 192.168.1.36, length 46
192.168.1.56.46833 > 255.255.255.255.29810: UDP, length 735
16:11:49.983288 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:11:49.983319 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:11:49.983319 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:11:49.983475 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:11:53.983319 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:11:53.983351 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
16:11:53.984506 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.36 tell 34-228-83-45.ftth.cust.kwaoo.net, length 46
232-99-118-92.ftth.cust.kwaoo.net.34106 > 224.0.0.251.mdns: 15783 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.49969 > 224.0.0.251.mdns: 15784 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.57402 > 224.0.0.251.mdns: 15785 PTR (QM)? 192.168.1.208.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.55821 > 224.0.0.251.mdns: 15786 PTR (QM)? 192.168.1.208.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.35488 > 224.0.0.251.mdns: 15787 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.59889 > 224.0.0.251.mdns: 15788 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.48368 > 224.0.0.251.mdns: 15789 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
232-99-118-92.ftth.cust.kwaoo.net.55204 > 224.0.0.251.mdns: 15790 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
192.168.1.56.46833 > 255.255.255.255.29810: UDP, length 735
16:11:57.983507 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.25 tell 192.168.1.36, length 46
16:11:58.983413 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:12:01.983475 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:12:01.983632 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:12:01.983788 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:12:05.983507 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:12:05.983507 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
232-99-118-92.ftth.cust.kwaoo.net.34491 > 224.0.0.251.mdns: 15791 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.53787 > 224.0.0.251.mdns: 15792 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.37766 > 224.0.0.251.mdns: 15793 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.59968 > 224.0.0.251.mdns: 15794 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.58012 > 224.0.0.251.mdns: 15795 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
232-99-118-92.ftth.cust.kwaoo.net.39326 > 224.0.0.251.mdns: 15796 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
16:12:06.983569 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
192.168.1.56.46833 > 255.255.255.255.29810: UDP, length 735
16:12:09.983663 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.25 tell 192.168.1.36, length 46
16:12:10.066575 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.36 tell 192.168.1.36, length 46
16:12:10.983757 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:12:13.983694 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:12:13.983850 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:12:13.984007 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:12:14.079039 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 (Broadcast) tell 192.168.1.26, length 46
192.168.1.56.46833 > 255.255.255.255.29810: UDP, length 736
232-99-118-92.ftth.cust.kwaoo.net.48484 > 224.0.0.251.mdns: 15797 PTR (QM)? 192.168.1.242.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.43449 > 224.0.0.251.mdns: 15798 PTR (QM)? 192.168.1.242.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.38712 > 224.0.0.251.mdns: 15799 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.36830 > 224.0.0.251.mdns: 15800 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.41537 > 224.0.0.251.mdns: 15801 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.32879 > 224.0.0.251.mdns: 15802 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
232-99-118-92.ftth.cust.kwaoo.net.48950 > 224.0.0.251.mdns: 15803 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
232-99-118-92.ftth.cust.kwaoo.net.39889 > 224.0.0.251.mdns: 15804 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
^C727 packets captured
759 packets received by filter
0 packets dropped by kernel
L'une a pour MAC 40:3f:8c:85:8a:5a qui est un appareil TP-Link
L'autre a pour MAC 60:31:97:7a:84:da qui est un appareil Zyxel
On voit aussi une IP publique 92.118.99.232 qui est à un client K-Net à Ballainvilliers (91) (à priori avec l'interface TP-Link)
https://ip-address-lookup-v4.com/lookup.php?host=ip-address-lookup-v4.com&ip=+92.118.99.232&x=78&y=26
Et son IP est impliquée avec du mdns (multicast DNS, genre Bonjour justement) avec des IP 92.168.1.X
Donc ces trames me font mentir, puisque ces personnes n'ont à priori pas de K-Box, mais des routeurs perso… Du coup, je penche pour un switch placé en amont, ou une mauvaise configuration sur les routeurs…
EDIT: voir mon post plus bas, 40:3f:8c:85:8a:5a c'est un plafonnier AP TP-Link, donc pas le routeur du client
-
Quelqu'un veut gagner des millions ici ? ;D
Un certain Franck ? ;D
Le plus probable, c'est que cela provient d'Icoteras qui ont ce bogue de fuite.
Superpicsou, soit ce MacBook Pro de Romary que tu vois est celui de phenomens, et vous êtes donc 2 clients avec ce problème (probablement un peu plus puisqu'il y a d'autres paquets privés qui ne sont à aucun de vous deux), soit c'est encore quelqu'un d'autre… Et là, on est déjà à au moins 3 (et probablement plus) clients, rien que dans notre GPON… C'est statistiquement élevé quand même !
Il faudrait recenser et comparer les adresses MAC que superpicsou et toi voyez ...
Je pense vraiment que c'est un problème beaucoup moins rare qu'on ne le pense, et la source de bien des soucis rencontrés par les clients K-Net ces derniers temps…
je ne m'avancerais pas autant.
La bonne nouvelle, c'est que résoudre la cause de ce problème devrait résoudre bien des symptômes d'un coup.
J'admire ton optimisme.
-
Et en écoutant un peu plus profondément, je peux en dire plus sur cette interface TP-Link…
version : TP-LINK.ECS.ver.1.3.0
Mac : 60:a4:b7:ef:cc:2
device : ap
model : EAP245
name : EAP245-60-A4-B7-EF-CC-2E
firmwareVersion : 5.0.2.Build.20210303.Rel..34713
modelVersion : 3.0
hardwareVersion : 3.0
upTime : 13.days.08:04:01
ip : 192.168.1.56
etc…
Donc ce n'est pas un routeur mais un plafonnier AP*… Donc ce n'est pas le routeur principal de ce client… Du coup, il a peut-être bien une K-Box qui fuie…
* https://www.tp-link.com/fr/business-networking/omada-sdn-access-point/eap245/
-
Quand j'étais très très débutant en réseau, j'avais oublié d'enlever le client DHCP d'un des switchs qui fait le Trunk LAN/WAN chez moi.
VincentO m'avait signalé très rapidement qu'il n'aimait pas voir des trames DHCP Request avec des adresses privées. J'avais donc mis le switch en adresse fixe et vérifier que je n'avais pas merder mes VLan.
C'était donc encore surveillé en 2019!
Ma k-box était aussi sous surveillance à cause de ses hausses de ping bizarres que bolemo voit aussi sur son monitoring.
-
Donc ce n'est pas un routeur mais un plafonnier AP*… Donc ce n'est pas le routeur principal de ce client… Du coup, il a peut-être bien une K-Box qui fuie…
... qui fuit donc du LAN vers le WAN.
Jusqu'à présent, on avait vu l'inverse : des paquets WAN qui se retrouvaient sur le LAN.
C'est quand même préoccupant tout ça.
-
... qui fuit donc du LAN vers le WAN.
Jusqu'à présent, on avait vu l'inverse : des paquets WAN qui se retrouvaient sur le LAN.
C'est quand même préoccupant tout ça.
Mais je pense que les fuites sont bidirectionnelles justement…
Le LAN de Superpicsou (enfin paquets broadcast et multicast seulement) fuit probablement dans le GPON…
-
Pour voir si @phenomens est bien pollué par des adresses IP en 192.168.1 qui ne lui appartiennent pas, autant inverser le grep :
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
Je n'avais pas eu le temps de le faire. Je l'ai fait tout à l'heure et j'avais pas mal de lignes, puis je l'ai refait il y a quelques instants : aucune ligne excepté celles-ci :
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
pktap_filter_packet: pcap_add_if_info(utun3, 0) failed: not a broadcast link
0 packets captured
46 packets received by filter
0 packets dropped by kernel
Malheureusement j'avais fermé l'autre fenêtre entre temps sans avoir copié le contenu...
Dans ta dernière option (si elle est envisageable, selon la configuration des lieux), le MAC aura l'adresse IP publique actuellement prise par la box, donc unique.
Est-ce que du coup le MAC peut être "routeur" WAN / WiFi pour les autres équipements du réseau de @phenomens
? J'imagine que oui ...
Malheureusement je n'ai pas ces équipements pour faire des tests.
A savoir que cela doit bien faire 2h que je suis repassé sur la KBox et je n'ai pas de coupures. Je relancerai la commande de temps en temps.
L'interface k-box est revenue.
Et dans mon cas, toujours la même erreur ::)
-
Je viens d'essayer l'autre commande :
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
Et voici le résultat :
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
pktap_filter_packet: pcap_add_if_info(utun5, 0) failed: not a broadcast link
4 packets captured
131 packets received by filter
0 packets dropped by kernel
17:35:38.388205 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 272: 192.168.1.23.17500 > 255.255.255.255.17500: UDP, length 230
17:35:38.388912 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 176: 192.168.1.23.17500 > 255.255.255.255.17500: UDP, length 134
17:35:38.389466 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 272: 192.168.1.23.17500 > 192.168.1.255.17500: UDP, length 230
17:35:38.389829 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 176: 192.168.1.23.17500 > 192.168.1.255.17500: UDP, length 134
Recommencé quelques instants après => 0 packets capturés.
-
Je viens d'essayer l'autre commande :
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
Et voici le résultat :
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
pktap_filter_packet: pcap_add_if_info(utun5, 0) failed: not a broadcast link
4 packets captured
131 packets received by filter
0 packets dropped by kernel
17:35:38.388205 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 272: 192.168.1.23.17500 > 255.255.255.255.17500: UDP, length 230
17:35:38.388912 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 176: 192.168.1.23.17500 > 255.255.255.255.17500: UDP, length 134
17:35:38.389466 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 272: 192.168.1.23.17500 > 192.168.1.255.17500: UDP, length 230
17:35:38.389829 14:98:77:67:e1:04 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 176: 192.168.1.23.17500 > 192.168.1.255.17500: UDP, length 134
Recommencé quelques instants après => 0 packets capturés.
Il semble que tu n'aies pas (plus) de fuite WAN/LAN.
La MAC 14:98:77:67:e1:04 est un appareil Apple, probablement ton MacBook Pro, donc normal de voir ces paquets dans ton LAN.
Tu verrais beaucoup de paquets s'il y avait la fuite.
Je pense que K-Net travaille sur le problème.
-
Il semble que tu n'aies pas (plus pour le moment) de fuite WAN/LAN.
La MAC 14:98:77:67:e1:04 est un appareil Apple, probablement ton MacBook Pro, donc normal de voir ces paquets dans ton LAN.
Tu verrais beaucoup de paquets s'il y avait la fuite.
Je pense que K-Net travaille sur le problème.
Super, ça progresse.
Je me suis permis de modifier légèrement la phrase de bolemo ci-dessus, restons circonspects.
Si l'adresse IP 192.168.1.23 est bien celle de ton MAC, il ne faut pas s'inquiéter de ces broadcasts, qui semblent être liés au service Dropbox LanSync (https://lafibre.info/index.php?action=post;quote=943845;topic=50989.132)
-
Ok je vais continuer de checker de temps en temps. En effet c'est l'ip de mon macMini.
-
Super, ça progresse.
Je me suis permis de modifier légèrement la phrase de bolemo ci-dessus, restons circonspects.
Si l'adresse IP 192.168.1.23 est bien celle de ton MAC, il ne faut pas s'inquiéter de ces broadcasts, qui semblent être liés au service Dropbox LanSync (https://lafibre.info/index.php?action=post;quote=943845;topic=50989.132)
Merci de préciser « pour le moment » qui effectivement est sous-entendu pour moi (mais pas forcément pour les lecteurs…)
Rappelons que ni pju91 ni moi ne sommes employés K-Net ou même en relation directe avec eux.
Donc nos théories et hypothèses sont à prendre avec un grain de sel et ne sont pas des certitudes.
@phenomens : j'imagine que les déconnexions et instabilités ont également disparues ? Donc pour l'instant, tu as un retour à la normal, espérons le pour de bon.
Le fait que ça ait changé indique que K-net a fait quelque chose, car c'était ta K-Box qui laissait perméable le GPON et ton LAN. Le fait que ces paquets aient disparus signifie que le changement s'est produit au niveau de ta K-Box et non que les paquets ont disparus du GPON.
Donc c'est encourageant…
Déjà, K-Net est devenu réactif au bogue du spam DHCPv6, et maintenant ils semblent s'attaquer à celui de la fuite.
-
Rappelons que ni pju91 ni moi ne sommes employés K-Net ou même en relation directe avec eux.
... et que tu n'envoies pas de factures à K-Net pour toutes les analyses et le monitoring que tu fais.
Donc nos théories et hypothèses sont à prendre avec un grain de sel et ne sont pas des certitudes.
car nos moyens d'investigation et de preuve sont finalement très limités, ne pouvant pas savoir ce qu'il se passe réellement chez l'OI ou chez K-Net.
-
Manifestement pas tout à fait résolu, cela fait 30 minutes que j’ai une coupure toutes les 5 minutes.
-
Manifestement pas tout à fait résolu, cela fait 30 minutes que j’ai une coupure toutes les 5 minutes.
Ça s’en va et ça revient…
-
Je me demande ce que vaut un petit sbc comme celui là : https://www.electronics-lab.com/orange-pi-r1-plus-router-sbc-with-dual-gigabit-ethernet/
S'il est assez puissant (je ne sais pas), un petit sbc comme celui là, placé entre l'ONT et la K-Box, avec un Ubuntu minimum et quelques règles ebtables devrait prévenir ce genre de soucis…
Un mini pare-feu quoi…
-
Je me demande ce que vaut un petit sbc comme celui là : https://www.electronics-lab.com/orange-pi-r1-plus-router-sbc-with-dual-gigabit-ethernet/
S'il est assez puissant (je ne sais pas), un petit sbc comme celui là, placé entre l'ONT et la K-Box, avec un Ubuntu minimum et quelques règles ebtables devrait prévenir ce genre de soucis…
Un mini pare-feu quoi…
Ou un PC de récupération (avec 2 cartes Ethernet)
N'importe quel Linux devrait faire l'affaire, avec nftables (https://fr.wikipedia.org/wiki/Nftables) (qui remplace en particulier ebtables).
Le jeu en vaut-il la chandelle pour un bug qui pourrait être corrigé dans un avenir plus ou moins proche ?
-
De mon côté toujours aucune coupure depuis mon changement d'ip local mercredi soir.
Le flux entrant spam toujours bien fort mais ça perturbe pas mon réseau.
Donc pour ceux qui ont les mêmes symptômes foncez !
Penomens, j'ai essayé la commande de pju91
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."Je pensais aussi ne rien avoir, mais si tu attend un peu ça arrive d'un coup.
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
11:52:46.035325 00:0e:58:f6:36:3e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 710: 192.168.1.58.54964 > 255.255.255.255.1900: UDP, length 668
11:52:46.209439 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:52:46.209932 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:52:47.209454 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
11:52:48.694904 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 781: 192.168.1.56.47098 > 255.255.255.255.29810: UDP, length 739
11:52:50.209437 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
11:52:51.209381 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
11:52:54.209376 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
11:52:55.209329 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
11:52:56.374340 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 85: 92.118.99.232.52772 > 224.0.0.251.5353: 18245 PTR (QM)? 192.168.1.11.in-addr.arpa. (43)
11:52:58.209368 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:52:58.209780 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:52:58.715308 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 778: 192.168.1.56.47098 > 255.255.255.255.29810: UDP, length 736
11:52:59.209418 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
11:53:02.209398 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
11:53:03.209336 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
11:53:06.209363 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
11:53:07.209313 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
11:53:07.330435 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.26, length 46
11:53:08.734470 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 778: 192.168.1.56.47098 > 255.255.255.255.29810: UDP, length 736
11:53:10.209255 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:53:10.656723 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Announcement 192.168.1.36, length 46
11:53:14.209177 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
11:53:15.209116 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
11:53:18.209231 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
11:53:18.754802 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.47098 > 255.255.255.255.29810: UDP, length 735
11:53:19.209284 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
11:53:19.209679 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
11:53:20.980866 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.40008 > 224.0.0.251.5353: 18254 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
11:53:22.209016 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:53:22.209543 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
11:53:22.210720 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.36 tell 45.83.228.34, length 46
11:53:26.209301 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
11:53:27.209057 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
11:53:28.774151 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.47098 > 255.255.255.255.29810: UDP, length 735
11:53:30.209213 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
11:53:31.209116 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
11:53:31.209547 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
^C270 packets captured
680 packets received by filter
0 packets dropped by kernel
A retester peut-être ?
et juste tcpdump -ne ether broadcast or ether multicast ça donne quoi ?
-
Bien entendu, s'il faut investir, autant le faire dans un routeur perso. Sinon, si un client qui est victime de ce problème possède déjà un PC ou SBC qui est disponible avec 2 cartes ethernet gigabit, ça vaut la peine de l'utiliser en pare-feu.
Sinon, en effet, ceux qui peuvent changer la plage IP du LAN de leur K-Box comme Superpicsou, c’est la solution la plus facile et simple.
Enfin, je constate que lui aussi voit les mêmes paquets, en particulier de ce client à Ballainvilliers… Et je pense que si ce client ne fuyait pas sur le GPON, ça poserait un peu moins de problèmes, car ils envoie pas mal de requêtes mdns sur la plage 192.168.1.0/24
Mais tout cela, c’est de la rustine, il faut absolument que K-Net résolve ce problème très sérieux…
-
De mon côté toujours aucune coupure depuis mon changement d'ip local mercredi soir.
Content pour toi 8)
Le flux entrant spam toujours bien fort mais ça perturbe pas mon réseau.
S'il il n'y a pas les paquets DHCP v6, le flux reste modeste : moins de 10 paquets par seconde, pas de quoi perturber tes équipements.
Donc pour ceux qui ont les mêmes symptômes foncez !
Penomens, j'ai essayé la commande de pju91
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."Je pensais aussi ne rien avoir, mais si tu attend un peu ça arrive d'un coup.
Donc tu continues à voir des paquets en 192.168.1 arriver sur ton LAN, mais comme tu as changé de numéro de réseau, ça ne t'affecte pas ... :P
et juste
tcpdump -ne ether broadcast or ether multicast
ça donne quoi ?
Ca devrait permettre de constater une "pollution massive" par les fameux paquets DHCPv6 lorsque ça arrive
-
Je confirme que le client avec l'IP 92.118.99.232 que j'avais mentionné hier possède une Icotera avec la MAC 00:1e:80:9b:2f:90.
Il est donc aussi victime de cette fuite.
Je fais un tweet à FB de ce pas (tweet qui sera publique car on ne peut lui envoyer de MP par tweeter…)
https://x.com/omelob/status/1514913062419107846
-
(tweet qui sera publique car on ne peut lui envoyer de MP par tweeter…)
Moi il m'a ouvert ses DM si jamais.
Par contre la question que je me pose c'est comment voir si moi j'ai des fuites dans les deux sens ? Il est possible que ma box envoi aussi des paquets partout.
-
Moi il m'a ouvert ses DM si jamais.
Par contre la question que je me pose c'est comment voir si moi j'ai des fuites dans les deux sens ? Il est possible que ma box envoi aussi des paquets partout.
Il a du me bloquer :(
Moi j'ai : Il n'est pas possible d'envoyer des messages à @fbknet.
-
Moi il m'a ouvert ses DM si jamais.
Par contre la question que je me pose c'est comment voir si moi j'ai des fuites dans les deux sens ? Il est possible que ma box envoi aussi des paquets partout.
Si tu me donnes ton IP en MP, je peux voir… et en prime mettre une sonde si tu veux
-
Il a du me bloquer :(
Moi j'ai : Il n'est pas possible d'envoyer des messages à @fbknet.
En ce moment il a l'air très occupé avec la présidentielle...
-
Par contre la question que je me pose c'est comment voir si moi j'ai des fuites dans les deux sens ? Il est possible que ma box envoi aussi des paquets partout.
Comme tu reçois des paquets qui proviennent des LAN d'autres clients, on peut penser que ce même bug fait que ta box envoie aussi tes paquets broadcast et multicast sur le WAN.
-
La commande ultime pour filtrer les paquets IPv4 qui proviennent probablement de fuites sur le GPON :
tcpdump -nnevv '( broadcast or multicast ) and ( net 192.168.0.0/16 or net 172.16.0.0/12 or net 10.0.0.0/8 ) and ! net 172.16.100.9'On écoute tout ce qui est broadcast ou multicast sur les adresses IPv4 dites privées sauf 172.16.100.9 qui est le serveur DHCP de K-Net et transmets des paquets légitimes en broadcast dans le GPON pour les clients DHCP.
Exemple sur quelques secondes :
root@HERMES:~$ tcpdump -i ethwan -nnevv '( broadcast or multicast ) and ( net 192.168.0.0/16 or net 172.16.0.0/12 or net 10.0.0.0/8 ) and ! net 172.16.100.9'
tcpdump: listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
12:50:13.338708 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.26 tell 192.168.1.36, length 46
12:50:13.338739 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
12:50:14.338802 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.56 tell 192.168.1.36, length 46
12:50:15.338708 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.25 tell 192.168.1.36, length 46
12:50:15.699658 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: (tos 0xa0, ttl 64, id 3937, offset 0, flags [none], proto UDP (17), length 763)
192.168.1.56.34993 > 255.255.255.255.29810: [udp sum ok] UDP, length 735
12:50:17.307280 78:62:56:4d:99:e1 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 136: (tos 0x0, ttl 255, id 60607, offset 0, flags [DF], proto UDP (17), length 122)
192.168.1.19.5353 > 224.0.0.251.5353: [udp sum ok] 8 [2q] PTR (QM)? _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local. PTR (QM)? _googlecast._tcp.local. (94)
12:50:17.310217 54:60:09:ff:56:f8 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 385: (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 371)
192.168.1.36.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/3 _googlecast._tcp.local. PTR Google-Home-567e9bc21c37d610e479da487ee3cb5b._googlecast._tcp.local. ar: Google-Home-567e9bc21c37d610e479da487ee3cb5b._googlecast._tcp.local. (Cache flush) TXT "id=567e9bc21c37d610e479da487ee3cb5b" "cd=D3323C35CC1CD90DB0DB42FCE03BA8E3" "rm=" "ve=05" "md=Google Home" "ic=/setup/icon.png" "fn=Salon" "ca=199172" "st=0" "bs=FA8FCA7B45A9" "nf=1" "rs=", Google-Home-567e9bc21c37d610e479da487ee3cb5b._googlecast._tcp.local. (Cache flush) SRV 567e9bc2-1c37-d610-e479-da487ee3cb5b.local.:8009 0 0, 567e9bc2-1c37-d610-e479-da487ee3cb5b.local. (Cache flush) A 192.168.1.36 (343)
12:50:18.338833 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
12:50:19.338895 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.58 tell 192.168.1.36, length 46
12:50:20.805781 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.36 tell 192.168.1.36, length 46
12:50:20.806905 60:31:97:7a:84:da > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.36 tell 45.83.228.34, length 46
12:50:21.194722 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.26, length 46
12:50:25.338927 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
12:50:25.719370 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: (tos 0xa0, ttl 64, id 57677, offset 0, flags [none], proto UDP (17), length 763)
192.168.1.56.34993 > 255.255.255.255.29810: [udp sum ok] UDP, length 735
12:50:26.338864 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.56 tell 192.168.1.36, length 46
12:50:27.338958 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.25 tell 192.168.1.36, length 46
12:50:30.338864 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.40 tell 192.168.1.36, length 46
12:50:31.339114 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.58 tell 192.168.1.36, length 46
12:50:32.339052 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.26 tell 192.168.1.36, length 46
12:50:35.739739 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: (tos 0xa0, ttl 64, id 58703, offset 0, flags [none], proto UDP (17), length 763)
192.168.1.56.34993 > 255.255.255.255.29810: [udp sum ok] UDP, length 735
12:50:37.310967 78:62:56:4d:99:e1 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 136: (tos 0x0, ttl 255, id 62186, offset 0, flags [DF], proto UDP (17), length 122)
192.168.1.19.5353 > 224.0.0.251.5353: [udp sum ok] 9 [2q] PTR (QM)? _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local. PTR (QM)? _googlecast._tcp.local. (94)
12:50:37.317215 54:60:09:ff:56:f8 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 385: (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 371)
192.168.1.36.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/3 _googlecast._tcp.local. PTR Google-Home-567e9bc21c37d610e479da487ee3cb5b._googlecast._tcp.local. ar: Google-Home-567e9bc21c37d610e479da487ee3cb5b._googlecast._tcp.local. (Cache flush) TXT "id=567e9bc21c37d610e479da487ee3cb5b" "cd=D3323C35CC1CD90DB0DB42FCE03BA8E3" "rm=" "ve=05" "md=Google Home" "ic=/setup/icon.png" "fn=Salon" "ca=199172" "st=0" "bs=FA8FCA7B45A9" "nf=1" "rs=", Google-Home-567e9bc21c37d610e479da487ee3cb5b._googlecast._tcp.local. (Cache flush) SRV 567e9bc2-1c37-d610-e479-da487ee3cb5b.local.:8009 0 0, 567e9bc2-1c37-d610-e479-da487ee3cb5b.local. (Cache flush) A 192.168.1.36 (343)
12:50:37.339145 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.36, length 46
^C
23 packets captured
23 packets received by filter
0 packets dropped by kernel
-
Comme tu reçois des paquets qui proviennent des LAN d'autres clients, on peut penser que ce même bug fait que ta box envoie aussi tes paquets broadcast et multicast sur le WAN.
Je pense aussi que le bogue est bidirectionnel… Les K-Box affectées agissent comme un bridge et les paquets du port WAN sont forwardés sur le LAN et vice-versa.
À mon avis tout passe, même les paquets unicast… mais la passerelle Covage qui reçoit des paquets unicast qui ne lui sont pas destinés les bloque et ne laisse passer que les paquets broadcast et unicast vers le GPON.
-
Ce qui est assez dingue, c'est que ce soient des clients techniquement aguerris qui identifient le problème de KNET et proposent une résolution...
Ils sont ou les ingénieurs réseau et le directeur technique de KNET ?
Edit : Je ne suis pas technique mais de ce que je comprends, si j'achète un routeur perso, fini les problèmes ? C'est ça ?
-
tu peux essayer si la solution de changer l'ip local de la box et la plage ip fonctionne pour toi. Dans l'onglet LAN de la Kbox.
Plus d'infos : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943589/#msg943589
-
Ce qui est assez dingue, c'est que ce soient des clients techniquement aguerris qui identifient le problème de KNET et proposent une résolution...
C'est l'avantage de ce forum, partager la connaissance et les informations. Merci à vivien et aux modérateurs pour ce lieu d'échange.
Note que ni bolemo ni moi ne sommes affectés par cet incident. bolemo dispose de son matériel, j'ai une K-Box qui est sur un réseau Covage non touché pour le moment par cet incident.
Ils sont ou les ingénieurs réseau et le directeur technique de KNET ?
Ils ont l'air débordés. On espère tous qu'à la fin de cette crise, ils pourront remettre en place un service client opérationnel et efficace. Actuellement, c'est quand même difficile de les joindre.
Edit : Je ne suis pas technique mais de ce que je comprends, si j'achète un routeur perso, fini les problèmes ? C'est ça ?
Tu as bien compris.
Il vaut mieux écrire "fini ce problème" (il peut y avoir d'autres incidents).
-
Merci pour votre suivi. Je vais acheter un routeur... c'est quelque chose que j'ai toujours fait auparavant mais cette fois, pour faciliter la communication avec KNET, j'avais choisi l'option "box".
Force est de constater que le routeur perso a encore un bel avenir...
-
Merci pour votre suivi. Je vais acheter un routeur... c'est quelque chose que j'ai toujours fait auparavant mais cette fois, pour faciliter la communication avec KNET, j'avais choisi l'option "box".
Force est de constater que le routeur perso a encore un bel avenir...
Mon opinion et expérience : un routeur perso permet justement d'éviter ce genre de problème… Tu sais exactement ce qu'il fait, comment il est paramétré, etc… Tu y a accès depuis chez toi, avec ou sans internet (pas dépendent d'un portail cloud).
Ça ne résoudra pas tous les problèmes qui peuvent survenir, mais je pense que tes soucis perso actuels seront réglés (problèmes de connexion instable, micro-coupures…). Un routeur perso peux te protéger des conséquences d'un spam comme la boucle infernale DHCPv6.
J'ai choisi K-Net justement pour le routeur perso ;)
-
Pour un budget de 200-250 €, un produit plutôt user friendly (je ne suis pas compétent pour taper du code Unix ou autre...), que conseillerais tu bolemo ?
J'avais repéré le Asus Zenwifi XT8 qui me paraissait pas mal avec pilotage via appli smartphone. Peut être d'autres modèles ?
Merci 8)
-
Pour un budget de 200-250 €, un produit plutôt user friendly (je ne suis pas compétent pour taper du code Unix ou autre...), que conseillerais tu bolemo ?
J'avais repéré le Asus Zenwifi XT8 qui me paraissait pas mal avec pilotage via appli smartphone. Peut être d'autres modèles ?
Merci 8)
Alors le meilleur conseil que je puisse te donner, c'est de voir avec ceux qui utilisent déjà un routeur perso avec K-Net chez Covage ; j'ai ouvert ce post pour toi ;) :
https://lafibre.info/k-net-internet/retour-dexperience-routeurs-perso/msg944057/#msg944057
Asus est une bonne marque, et à priori n'importe quel routeur de bonne marque doit faire l'affaire (il suffit qu'il accepte le DHCPv4 et DHCPv6 pour quand l'IPv6 reviendra, ce que tout routeur sait gérer…)
-
merci !
-
Pour ma part j'ai enfin trouvé un opérateur national qui a bien voulu se casser la tête 2 minutes pour trouver mon logement sur une carte plutôt que de se borner à utiliser une adresse postale !! (Orange)
Donc dans 15 jours, fini KNet. Je crois qu'entre la coupure de 3 jours le we dernier et les coupures incessantes toute la semaine ont fini de me décider. J'y reviendrai peut-être un jour, mais là c'est trop ; sur 3 mois et demi d'abonnement j'ai eu plus de 3 semaines sans internet et 2 semaines avec des coupures quasiment non stop.
-
Pour ma part j'ai enfin trouvé un opérateur national qui a bien voulu se casser la tête 2 minutes pour trouver mon logement sur une carte plutôt que de se borner à utiliser une adresse postale !! (Orange)
Donc dans 15 jours, fini KNet. Je crois qu'entre la coupure de 3 jours le we dernier et les coupures incessantes toute la semaine ont fini de me décider. J'y reviendrai peut-être un jour, mais là c'est trop ; sur 3 mois et demi d'abonnement j'ai eu plus de 3 semaines sans internet et 2 semaines avec des coupures quasiment non stop.
Je comprends… En te souhaitant la meilleur transition possible :)
Je suis tombé par hasard aujourd'hui sur cet article qui parle de situation de crise pour les sociétés (ici pour les affaires Buitoni et Kinder) : https://www.la-croix.com/amp/1201210583?utm_medium=referral&utm_source=upday
Je cite l’introduction de l'article :
« En matière de gestion de crise, le pire est de ne rien dire » : voilà la prescription de Géraldine Michel, responsable de la chaire marques et valeurs à la Sorbonne, pour des entreprises prises dans la tourmente d’une crise alimentaire. « Il faut communiquer sur les rappels, ne pas hésiter à les élargir, adopter de nouveaux codes sanitaires et faire profil bas sur le reste », ajoute la professeure. « Il ne faut surtout pas donner l’impression que rien n’est fait », insiste Laurent Vibert, le président de Nitidis, agence de communication de crise.
-
Je suis tombé par hasard aujourd'hui sur cet article qui parle de situation de crise pour les sociétés (ici pour les affaires Buitoni et Kinder) : https://www.la-croix.com/amp/1201210583?utm_medium=referral&utm_source=upday
Par chance, la crise K-Net n'a pas les mêmes conséquences sur la santé des clients - en tout cas on l'espère, la panne de téléphonie aurait pu avoir des conséquences tragiques.
Pour les anglophones, cet article de blog est également intéressant :
https://blog.hubspot.com/marketing/reputation-management
On y parle des clients en tant qu'actifs principaux de l'entreprise, de surveiller ce qui se dit sur l'entreprise, de communiquer sans délai.
Et pourtant, https://www.k-net.fr/etat-du-reseau-et-des-services/ n'a pas été mis à jour depuis une semaine, il n'y a toujours pas d'info sur les progrès des investigations en cours, une date de retour à la normale, etc.
C'est triste. :(
-
Par chance, la crise K-Net n'a pas les mêmes conséquences sur la santé des clients - en tout cas on l'espère, la panne de téléphonie aurait pu avoir des conséquences tragiques.
Pour les anglophones, cet article de blog est également intéressant :
https://blog.hubspot.com/marketing/reputation-management
On y parle des clients en tant qu'actifs principaux de l'entreprise, de surveiller ce qui se dit sur l'entreprise, de communiquer sans délai.
Et pourtant, https://www.k-net.fr/etat-du-reseau-et-des-services/ n'a pas été mis à jour depuis une semaine, il n'y a toujours pas d'info sur les progrès des investigations en cours, une date de retour à la normale, etc.
C'est triste. :(
Les conséquences ne sont heureusement pas aussi importantes que pour un problème de santé publique (avec des morts quand même :( ), mais en effet les problèmes de téléphonie peuvent être dramatiques… Sur Tweeter, quelqu'un s'était plaint récemment à FB suite à une situation d'urgence, leur mobile était déchargé et la téléphonie K-Net HS, et ils ont du appeler depuis des voisins.
Les conseils donnés dans cet article et celui que tu partages semblent évident, et je ne comprends vraiment pas pourquoi K-Net n'a pas pris le temps de développer cela un minimum… Je ne comprends pas l'intervention du conseil en communication qui n'a de l'extérieur rien changé…
J'ai conseillé à FB de communiquer via une page dédiée (de crise), et en demandant via Tweeter, la page d'incidents est parfois mise-à-jour, mais c'est fou que ce soit encore une fois sur demande de clients qui insistent…
Il faut aller à la pêche, bien armé et insister pour avoir des informations, ou alors les chercher soi-même (comme le monitoring smokeping, du GPON, de l'ONT…)
Autre absurdité, K-Net dispose de nombreux clients ou ex-clients qui sont prêt à aider, comme toi pju91 ou TheDark, Steph… Et leur forum était vraiment un atout énorme pour leur communication et la résolution de problèmes. Heureusement que LaFibre.info est là !
-
On a surtout l'impression que leur grand chef FB prend tout le monde de haut et est persuadé de mener sa barque comme personne. Quand au Dir Technique, j'ai ouï dire qu'il était plutôt controversé dans le métier. Mais ça non plus, ça n'est pas gênant à priori.
Avec des melons gros comme ça, je ne suis pas sur que les "ingé" de KNET (s'il y en a encore des valides) s'inspirent de LaFibreInfo pour réparer leurs problèmes.
Par contre, pour ouvrir 10000 tickets chez COVAGE et attendre leur non résolution, ils savent faire 8)
Trêve de plaisanterie, j'ai bien peur que le temps qu'ils redressent la barre techniquement parlant, il n'y aura plus beaucoup d'abonnés à servir et ils vont faire un bon de 10 ans en arrière (quand on voit le dernier résultat publié, ça fait peur...)
Perso, j'attends l'arrivée d'Orange dans ma rue et je tirerais ma révérence aussi. 47€ par mois pour ce service déplorable et aucune communication, même si y'a plein de bénévoles comme vous tous qui tentent d'aider tant bien que mal, ce n'est plus possible.
Faut être un peu masochiste pour rester chez KNET 8)
-
On a surtout l'impression que leur grand chef FB prend tout le monde de haut et est persuadé de mener sa barque comme personne. Quand au Dir Technique, j'ai ouï dire qu'il était plutôt controversé dans le métier. Mais ça non plus, ça n'est pas gênant à priori.
Avec des melons gros comme ça, je ne suis pas sur que les "ingé" de KNET (s'il y en a encore des valides) s'inspirent de LaFibreInfo pour réparer leurs problèmes.
Par contre, pour ouvrir 10000 tickets chez COVAGE et attendre leur non résolution, ils savent faire 8)
Trêve de plaisanterie, j'ai bien peur que le temps qu'ils redressent la barre techniquement parlant, il n'y aura plus beaucoup d'abonnés à servir et ils vont faire un bon de 10 ans en arrière (quand on voit le dernier résultat publié, ça fait peur...)
Perso, j'attends l'arrivée d'Orange dans ma rue et je tirerais ma révérence aussi. 47€ par mois pour ce service déplorable et aucune communication, même si y'a plein de bénévoles comme vous tous qui tentent d'aider tant bien que mal, ce n'est plus possible.
Faut être un peu masochiste pour rester chez KNET 8)
Vu comme c'est parti, ils vont continuer à perdre des clients, mais garder une petite base dont la seule réelle concurrence est/sera MilkyWan.
Pour un certain nombre, comme moi, ça fonctionne bien. À part l'IPv6 dont j'attends le retour, j'ai pas de coupures, j'ai de très bons débits, la téléphonie, et la TV.
Je pense que les Icotera sont un problème potentiel, et que les routeurs perso épargnent pas mal de soucis… Après, pour certains comme pju91, la K-Box fonctionne bien, donc peut-être une série est plus prone aux problèmes, ou c'est une histoire de chance…
Dans mon cas (je ne généralise pas), Orange SFR ou Bouyges ne m'offrent rien de plus, au contraire.
K-Net peut survivre, et retrouver l'excellence ; s'il y a eu des efforts de fait depuis janvier, avec moins de problèmes de téléphonie, ils sont encore victimes des bogues Icotera qui peuvent rapidement dégoûter les clients qui sont affectés à répétition… Là une communication annonçant (reconnaissant) l'existence de ces bogues (qui viennent d'Icotera), les symptômes, présentant des excuses et un plan pour diminuer puis résoudre cela aiderait…
Les efforts en communication sont pour l'instant inexistants… Oui, une section prometteuse dans l'espace client, mais pas encore fonctionnelle et pas annoncée officiellement… Une page des problèmes réseaux pas à jour (ou qui donne l'impression de ne pas l'être…), un service client difficile à joindre et ce bogue des 1h qui coupe qui est toujours là… Plein de petites choses qui au final comptent énormément et jouent sur le moral et la confiance des clients.
-
Vu comme c'est parti, ils vont continuer à perdre des clients, mais garder une petite base dont la seule réelle concurrence est/sera MilkyWan.
Pas d'accord, ceux qui resteront sont ceux qui se fichent de leur accès internet/tv/téléphone, et ceux là ne viendront pas chez nous :)
-
Pas d'accord, ceux qui resteront sont ceux qui se fichent de leur accès internet/tv/téléphone, et ceux là ne viendront pas chez nous :)
C'est un peu rapide comme jugement : je reste, alors que j'ai besoin d'Internet au quotidien (télétravailleur permanent) donc je ne m'en fiche pas.
Mais il est vrai que j'ai la chance de ne pas avoir été victime d'incidents collectifs qui touchent d'autres coins de l'Essonne.
Je n'utilise que peu la téléphonie (ayant encore une ligne cuivre, plusieurs abonnements mobiles pour les membres de la famille, une solution de communication avec passerelle téléphonique de mon boulot).
Je regarde les flux TV sur ordinateur (plus que sur la box TV), et si ça ne fonctionne plus, je fais tout simplement autrement.
En plus, pour le moment, je ne viendrai pas chez toi puisque ta solution ne vient pas chez moi ... Et comme répété souvent ici, l'offre de K-Net reste malgré tout compétitive.
-
Pas d'accord, ceux qui resteront sont ceux qui se fichent de leur accès internet/tv/téléphone, et ceux là ne viendront pas chez nous :)
Sois un peu gentleman…
Tirer à boulets rouge sur un concurrent qui traverse une crise, ce n'est pas nécessaire ni très beau.
Attention aussi à ne pas attraper le virus de l'arrogance tant reproché à K-Net.
Je dis cela en toute amitié, j'ai de l'estime et du respect pour toi et ce que tu fais.
Je reste chez K-Net, et je ne me fiche absolument pas de mon accès internet/tv/téléphone.
MilkyWan est pour moi un concurrent qui a éveillé mon intérêt, mais je suis fidèle et ne sauterai ce pas que si K-Net ne survit pas à cette crise ou si leur services se dégradent sans espoir. De toute façon MW n'est pas disponible chez Covage. Si un jour je saute ce pas, je serai alors aussi fidèle à MW, sans pour autant critiquer la concurrence.
La concurrence c'est bien, j'apprécie l'arrivée et la montée en force de MW, mais ça serait dommage que K-Net disparaisse pour autant…
-
Il n’empêche que c’est le fond de ma pensée, ceux qui resteront seront les personnes âgées, les résidences secondaires et tous les gens qui n’ont pas besoin de leur accès pour travailler.
-
Il n’empêche que c’est le fond de ma pensée, ceux qui resteront seront les personnes âgées, les résidences secondaires et tous les gens qui n’ont pas besoin de leur accès pour travailler.
On en reparlera quand il faudra géré plus de 1000 clients et investir massivement dans une grosse infra. Au début, tout est facile...
-
Je dirais qu'au contraire, au début c'est bien plus compliqué
-
Ce fil va bientôt finir dans la section bistro (https://lafibre.info/bistro-sujet-libre/)
-
Il n’empêche que c’est le fond de ma pensée, ceux qui resteront seront les personnes âgées, les résidences secondaires et tous les gens qui n’ont pas besoin de leur accès pour travailler.
Tu exagères un peu sur ce coup ou tu as des infos sur ce qui va se passer...
-
Pas spécialement d'infos non, mais visiblement la communication ce n'est tjs pas à l'ordre du jour et le forum n'est pas prêt de revenir.
-
La com, c'est pas ça, c'est clair, mais l'écoute s'améliore et la technique revient un peu.
Dans le 74, ça marche.
Et si ma k-box part en couille (elle a toujours des hausses de latences bizarre sur certaines destinations tournantes qui avait intrigué VincentO), je mets mon vieux routeur de secours à la place et basta...
-
Tout le monde semble oublier un grand pilier de la santé d'une entreprise : sa politique commerciale.
Beaucoup rejettent la faute (ou du moins une éventuelle responsabilité) sur MilkyWan. Sauf que dans les faits, MW c'est <1% des résils, honnêtement, on s'en fout. Du coup les gens ratent la vraie cible, la réelle concurrence, le réel danger : les OCEN avec des promos attractives, qui s'accaparent >99% des abonnés qui partent. Et ce danger là, il est pareil pour MW hein.
Donc pour moi l'urgence n'est plus dans la technique ou dans la communication, mais bien dans le repositionnement commercial pour repartir en reconquête de nouveaux clients. Et il ne faut pas trainer, la grande saison des fin d'années scolaires, des déménagements & cie, approche à grands pas.
-
Je pense sincèrement que MW fait plus d'ombre aux OCEN qu'à K-Net!
-
Tout le monde semble oublier un grand pilier de la santé d'une entreprise : sa politique commerciale.
Beaucoup rejettent la faute (ou du moins une éventuelle responsabilité) sur MilkyWan. Sauf que dans les faits, MW c'est <1% des résils, honnêtement, on s'en fout. Du coup les gens ratent la vraie cible, la réelle concurrence, le réel danger : les OCEN avec des promos attractives, qui s'accaparent >99% des abonnés qui partent. Et ce danger là, il est pareil pour MW hein.
Donc pour moi l'urgence n'est plus dans la technique ou dans la communication, mais bien dans le repositionnement commercial pour repartir en reconquête de nouveaux clients. Et il ne faut pas trainer, la grande saison des fin d'années scolaires, des déménagements & cie, approche à grands pas.
Je pense que c''est un peu ce que j'ai exprimé le 25 mars : https://lafibre.info/k-net-incident/recapitulatif-des-problemes-en-cours-et-non-resolus/msg938221/#msg938221
-
Je pense sincèrement que MW fait plus d'ombre aux OCEN qu'à K-Net!
J'ai beaucoup de respect pour Hugues et MW. Alors non aucun petit fai ne fait d'ombre aux OCEN.
-
J'ai beaucoup de respect pour Hugues et MW. Alors non aucun petit fai ne fait d'ombre aux OCEN.
C'est bien mal me connaitre... ;)
-
Alors non aucun petit fai ne fait d'ombre aux OCEN.
Très clairement
-
Pour vivre heureux, vivons cachés.
Je pourrais avoir Orange, SFR et Free et pourtant je ne veux que des petits FAI.
C'est donc inexplicable...
-
Pour vivre heureux, vivons cachés.
Je pourrais avoir Orange, SFR et Free et pourtant je ne veux que des petits FAI.
C'est donc inexplicable...
Je suis atteint du même syndrome ;D
Clairement, niveau pouvoir financier et nombre de clients, il y a les OCEN d'un côté, et les petits FAI de l'autre… Ces derniers pour la grande majorité, n'existent que grâce à l'écosystème des OI et RIP qui ont ouvert des lignes là où les OCEN ne voulaient pas s'embêter à investir (il leur suffit d'attendre quelques années que les réseaux soient en place, qu'il y ait suffisamment de clients raccordables, et de prendre le train en marche pour récolter ce qu'ils n'ont pas semé…)
Les OCEN sont importants, car ils ont de grosses structures, des réseaux, ils posent et entretiennent des câbles sous-marins, etc… Donc importants pour notre pays et notre indépendance.
Mais les OCEN sont de grosse machines, devenues impersonnelles, avec des centre d'appels délocalisés (ou non) qui suivent des scripts, des offres rigides et standardisées, des box quasiment obligatoires et incontournables… Quand ça marche, c'est formidable, si on a un problème classique, c'est résolu rapidement… Si on a un problème qui n'a pas été pensé dans les scripts des services clients… Bon courage !
Les petits FAI qui n'ont pas d'originalité et ne font que copier les OCEN vont disparaître. Seuls resteront ceux qui se différencient.
K-Net était de ceux-là. Pour le moment, c'est un point d'interrogation, on attend de voir s'ils vont retrouver leur identité, leur culture, et surtout mettre en avant ce qui les différencie… Je répète ce que j'ai déjà dit depuis janvier : infrastructure transparente, service client accessible et de proximité, accès aux techniciens et ingénieurs, possibilité de matériel perso, communauté de clients (forum)…
Clairement, de nombreux points de cette identité sont aujourd'hui compromis… L'avenir nous dira si c'est temporaire et non-intentionnel, une conséquence de la crise en cours, ou si c'est intentionnel et part de la stratégie (ou absence de stratégie). Pour moi (et d'autres comme par exemple pju91), seul un retour à ces valeurs peut permettre à K-Net de survivre et de se trouver un marché dans lequel les OCEN sont présents.
MW lui est intéressant du fait qu'il arrive tard dans ce marché, qu'il est un association, et qu'il ne s'est pas construit en l'absence des OCEN. Il vise clairement les geeks et techniciens amateurs ou professionnels avec du matériel perso. Sur ce segment, ils partagent des valeurs avec K-Net (transparence, service client accessible et de proximité, accès direct aux ingénieurs, communauté de clients…). Donc pour moi, ils sont sans aucun conteste concurrents au moins sur ce segment.
Aujourd'hui, MW marque des points, car ils sont jeunes (pas encore de crises de croissance…), tout est neuf et beau et fonctionnel, les équipes sont réactives, soudées et boostées par leur succès et la nouveauté… Comme K-Net il y a plusieurs années… De l'autre côté, K-Net traverse une crise, ils ont déjà une infrastructure, des clients, du matériel (K-Box)… Comme l'ont rappelé si bien certains ici, c'est moins facile à gérer, et ça le sera moins pour MW dans l'avenir qui aura des défis, des premières crises de croissance, quand il faudra embaucher… des décisions à prendre sur des questions qui ne sont même pas encore envisageables (surprises de l'avenir)…
Pour moi, et c'est dommage, on est passé à côté de quelque chose : un mélange de la jeunesse de MW avec l'expérience de K-Net aurait été la synergie idéale.
K-Net est méfiant envers MW, ayant l'impression d'avoir été abusé, utilisé pour lancer MW. S'il y a probablement un peu de vérité derrière, c'est en majorité, je crois, non fondé… Basé sur des ressentis entre individus plutôt que sur des faits.
Il y a eu des échanges un peu durs de la part de représentants de MW envers K-Net, basés sur ces ressentiments émotionnels.
Chez K-net, certains ont aussi tenu (moins publiquement cependant) des propos durs envers des anciens de K-Net et MW, là aussi basé sur des ressentiments personnels…
FB, à part des maladresses n'a pas à ma connaissance beaucoup participé à ces échanges ; ce doit être compliqué pour lui tout cela (je ne lui donne pas des excuses, mais constate que ça doit être dur de voir sa boîte traverser une crise, s'il a de la fierté pour K-Net de voir beaucoup de clients mécontents et partir… de voir ses employés sous pression… De se voir accusé de ceci ou cela, à tort ou à raison…)
Ces piques et critiques (non constructives) sont dommageables, elle n'embellissent ni K-Net, ni MW.
-
@bolemo, puisque tu me mentionnes, et je t'en remercie, je te confirme que je partage ce que tu as écrit concernant K-Net ;)
Pour avoir eu une autre casquette avant 2020 et tenté de faire venir des OCEN sur un RIP, j'ai surtout vu qu'ils se tiraient la bourre sur les zones AMII, qui ont conduit au partage du gateau entre Orange et SFR. C'est là qu'ils ont investi. Du coup, ils ont complètement négligé les RIP pendant des années.
Je partage également ton avis sur le fait que les propos tenus ici (donc publics) devraient être respectueux de tous, clients comme fournisseurs.
-
Ce week end encore un enfer la connexion qui va et qui vient toutes les 10 min.
J’espère que le routeur que je reçois demain va résoudre le problème…
Sinon, je serais dans l’obligation de résilier… c’est trop handicapant pour le télétravail ce problème et je n’ai pas l’impression que ça avance malgré les x tickets ouverts par Knet chez Covage. Les 2 se renvoient la responsabilité d’après ce que j’ai compris…
Bref, affaire à suivre demain…
-
Pour info, concernant le sujet de "fuite" entre LAN et WAN, je suis parvenu à établir un contact avec le support d'Icotera, qui normalement ne communique qu'avec ses clients opérateurs.
Voyons si ça nous conduit quelque part.
-
Icotera a pris connaissance de la description du bug de "fuite LAN <=> >WAN" et des traces réseau présentes dans ce fil et va contacter "officiellement" K-Net pour continuer les investigations et rechercher la solution.
Ils n'observent bien sûr pas ce type de comportement sur leurs versions actuelles de firmware.
-
Nouveau routeur installé. Pour l'instant, ça marche :)
On verra par la suite
-
Icotera a pris connaissance de la description du bug de "fuite LAN <=> >WAN" et des traces réseau présentes dans ce fil et va contacter "officiellement" K-Net pour continuer les investigations et rechercher la solution.
Ils n'observent bien sûr pas ce type de comportement sur leurs versions actuelles de firmware.
Flippant que c'est aux utilisateurs de faire le support et le debug.
-
Flippant que c'est aux utilisateurs de faire le support et le debug.
On a pris l'habitude avec Covage.
K-net prend le même chemin...
-
Flippant que c'est aux utilisateurs de faire le support et le debug.
D'accord avec toi.
Mais je trouve qu'avoir cette "épée de Damoclès" d'une box qui se met à fuire pour des raisons inconnues est encore plus flippant (quand on utilise comme moi une K-Box).
C'est pour ça que j'ai tenté d'avancer de mon côté, bien que non impacté actuellement.
-
D'accord avec toi.
Mais je trouve qu'avoir cette "épée de Damoclès" d'une box qui se met à fuire pour des raisons inconnues est encore plus flippant (quand on utilise comme moi une K-Box).
C'est pour ça que j'ai tenté d'avancer de mon côté, bien que non impacté actuellement.
Il faut voir si Kiwi possède le même souci.
-
Contacté aujourd’hui par un membre de l’équipe technique Knet.
Ils sont en recherche de résolution pour le problème de l’Icotera et ont fait quelques testes sur ma box. J’ai renvoyé divers logs de dump.
Ils étaient présent sur le forum caps et continuent de suivre ce qui se dit ici.
Affaire à suivre donc.
-
Contacté aujourd’hui par un membre de l’équipe technique Knet.
Ils sont en recherche de résolution pour le problème de l’Icotera et ont fait quelques testes sur ma box. J’ai renvoyé divers logs de dump.
Ils étaient présent sur le forum caps et continuent de suivre ce qui se dit ici.
Affaire à suivre donc.
Tiens donc, est-ce que c'est suite à notre sollicitation directe d'Icotera que K-Net t'a contacté ou est-ce simplement une coïncidence ?
En tout cas je me réjouis de constater que le sujet est pris en compte de leur côté.
Merci de "jouer le jeu" en leur fournissant les éléments que tu peux collecter.
-
Ils sont en recherche de résolution pour le problème de l’Icotera et ont fait quelques testes sur ma box. J’ai renvoyé divers logs de dump.
*Sigh*
De mes souvenirs, c'était une race condition qui faisait qu'une règle ebtables n'était pas appliquée dans certaines conditions très spécifiques.
Toujours de mes souvenirs, Icotera avait préparé un patch et fournit un workaround pour les anciennes versions (activer le serveur http de l'icotera, quitte à mettre une acl y bloquant tout accès, ce qui avait été fait par Antho ; la race condition ne se produit pas dans ce cas là).
Par contre, dès qu'une Icotera leak, toutes les autres sur le même domaine de diffusion se mettent à avoir des soucis - je ne vais pas rentrer dans les détails techniques de pourquoi.
Ça impliquait deux choses :
- en cas de réaffectation d'Icotera entre abonnés différents, l'Icotera ne doit pas juste être reset mais doit passer par Amiens pour être flashée.
- le support doit demander au NOC avant de demander à un client de faire la combinaison magique qui bascule l'Icotera sur l'autre memory bank (de toute façon ils doivent le faire pour une autre raison)
Si malheureusement le problème se produit, K-Net :
- peut limiter le problème en programmant des ACL directement en ASIC. (hint pour K-Net : en SSH, après avoir obtenu un *vrai* shell, `diag` et fouillez les commandes commençant par `rg`; il faudra bloquer un ethertype en particulier + des subnets spécifiques, j'en ai déjà mentionné un dans un autre message). Pour le NOC, si vous ne l'avez pas, demandez si quelqu'un a encore le zshrc que j'avais fait, y'avait des fonctions pour gérer ces cas.
- peut trouver l'origine du problème avec un parallel-ssh pour trouver les Icotera sans règle ebtables, puis les redémarrer
C'était assez pénible à diagnostiquer la première fois, j'espère pour les gens du NOC qu'ils n'auront pas à refaire le diagnostique une deuxième fois... :(
-
Si seulement K-Net avait su garder ses ingénieurs talentueux, merci Vincent !
-
Si jamais l'ingé qui m'a appelé l'autre jour passe par là et lit ces lignes :
Vous pouvez me faire un update de la situation par rapport à ma box ? Soit par téléphone soit ici.
Depuis les dernières testes sur le panel j'ai toujours l'image de la netgear et je n'ai pas accès à l'onglet 'info'. J'ai toujours
La KBOX est actuellement injoignable, réessayez ultérieurement
Merci.
Des bisous.
-
Un petit point sur la situation des fuites K-Box/Icotera.
Mesure des fuites impliquant des adresses APIPA sur quelques secondes. Il y en a quand même pas mal.
L'échantillon montre 3 K-Box impliquées et un appareil Siemens.
root@HERMES:~$ tcpdump -i ethwan -e "net 169.254.0.0/16"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
17:43:56.407340 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:57.121992 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:57.407403 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:57.720180 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:58.121929 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:58.720117 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:59.122179 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:59.720024 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:00.150452 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 1514: 169.254.1.2.52310 > 169.254.1.1.2325: UDP, bad length 1818 > 1472
17:44:00.150483 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 380: 169.254.1.2 > 169.254.1.1: udp
17:44:00.412588 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:01.412682 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:02.112120 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:02.412432 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:02.725209 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:03.112057 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:03.725147 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:04.112120 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:04.725053 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:05.417618 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:06.417712 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:07.117149 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:07.417618 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:07.730239 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:08.117056 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:08.730145 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:09.117149 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:09.730239 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:10.427709 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:10.861229 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 1514: 169.254.1.2.52310 > 169.254.1.1.2325: UDP, bad length 1818 > 1472
17:44:10.861261 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 380: 169.254.1.2 > 169.254.1.1: udp
17:44:11.427646 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:12.122335 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:12.427740 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:12.765228 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:13.122148 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:13.765322 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:14.122335 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:14.765259 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:15.432738 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:15.859230 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype ARP (0x0806), length 60: Reply 169.254.1.2 is-at 00:11:33:55:77:cc (oui Unknown), length 46
17:44:16.432832 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:17.127365 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:17.432738 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
^C
44 packets captured
44 packets received by filter
0 packets dropped by kernel
En revanche, les paquets impliquant des IPv4 privées sont absent… Une bonne nouvelle, et donc à priori une avancée du côté de K-Net sur ce problème.
root@HERMES:~$ tcpdump -i ethwan -e "(broadcast or multicast) and (net 192.168.0.0/16 or net 10.0.0.0/8 or net 172.16.0.0/12) and not (net 172.16.100.9/32 or net 10.2.0.211/32)"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes-> silence, aucun paquet reçu.
Les deux adresses que je retire de l'écoute 172.16.100.9 et 10.2.0.211 sont le serveur DHCP de K-Net et le relais/passerelle Covage, qui envoient et reçoivent des paquets broadcast/multicast normaux (principalement les négociations DHCP avec les clients).
-
Un petit point sur la situation des fuites K-Box/Icotera.
Mesure des fuites impliquant des adresses APIPA sur quelques secondes. Il y en a quand même pas mal.
L'échantillon montre 3 K-Box impliquées et un appareil Siemens.
S'agit-il vraiment de fuites ?
Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA ?
Je ne connais pas l'algorithme pour les adresses MAC des K-Box, mais j'ai constaté qu'il y a une différence de 2 entre la MAC LAN et la MAC WAN de ma box.
S'il y a une règle connue (ex chez moi : 10 côté WAN et :12 côté LAN), ça permettrait de confirmer ce que j'ai écrit. D'autant plus qu'un paquet avec une adresse APIPA ne doit pas être routé (en théorie).
En revanche, les paquets impliquant des IPv4 privées sont absent… Une bonne nouvelle, et donc à priori une avancée du côté de K-Net sur ce problème.
root@HERMES:~$ tcpdump -i ethwan -e "(broadcast or multicast) and (net 192.168.0.0/16 or net 10.0.0.0/8 or net 172.16.0.0/12) and not (net 172.16.100.9/32 or net 10.2.0.211/32)"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes-> silence, aucun paquet reçu.
bonne nouvelle effectivement.
-
S'agit-il vraiment de fuites ?
Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA ?
Je ne connais pas l'algorithme pour les adresses MAC des K-Box, mais j'ai constaté qu'il y a une différence de 2 entre la MAC LAN et la MAC WAN de ma box.
S'il y a une règle connue (ex chez moi : 10 côté WAN et :12 côté LAN), ça permettrait de confirmer ce que j'ai écrit. D'autant plus qu'un paquet avec une adresse APIPA ne doit pas être routé (en théorie).
C'est peut-être les mêmes fuites (APIPA côté LAN qui fuie) ou un troisième bogue…
Dans tous les cas ces paquets ne devraient pas être émis sur le GPON. Je n'ai pas encore essayé de les étudier en détail ni de mesurer sur un plus bogue période.
L'appareil Siemens est soit sur un LAN qui fuit, soit derrière l'ONT (switch…).
Bonne idée pour la différence MAC LAN/WAN… S'il y avait une règle, ça aiderait bien ; je verrai ça dès que j'en ai le temps.
Sinon, le silence des fuites d'adresses privées est très agréable.
-
Ce qui provient des adresses APIPA des K-Box, c'est des requêtes ARP.
Les deux K-Box ont la MAC 00:1e:80:93:0b:58 et 00:1e:80:93:04:b0 (la troisième n'est plus là… peut-être que son possesseur a lu mon post et fait quelque chose entre temps).
Elles ont toutes deux l'adresse 169.254.1.3 et cherchent à joindre 169.254.1.1 en ARP.
L'appareil Siemens ne communique pas seulement en broadcast ou multicast, mais aussi en unicast ! (donc peut-être directement connecté au GPON ?)
Il a pour MAC 00:11:33:55:77:cc et pour IP 169.254.1.2.
On le voit répondre en ARP à une requête ARP (que je ne reçois pas) envoyée par 00:11:33:55:77:bb (un autre appareil Siemens) :
19:35:18.098780 00:11:33:55:77:cc > 00:11:33:55:77:bb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 169.254.1.2 is-at 00:11:33:55:77:cc, length 46
Et il communique depuis le port 52310 en udp vers cet autre appareil Siemens ayant pour MAC 00:11:33:55:77:bb et pour IP 169.254.1.2, qui reçoit en udp sur le port 2325
Un échantillon montre que ce sont principalement des statistiques réseau qui sont transmises :
0x0050: 8bdb 0120 2053 7461 7469 7374 6963 732e .....Statistics.
0x0060: 2e2e 0a20 2020 2075 705f 7469 6d65 3a20 .......up_time:.
0x0070: 3838 3234 3331 3773 200a 2020 2020 6368 8824317s......ch
0x0080: 5f75 7469 6c69 7a61 7469 6f6e 3a09 3135 _utilization:.15
0x0090: 0a20 2020 2074 785f 7469 6d65 3a20 2020 .....tx_time:...
0x00a0: 2020 2020 300a 2020 2020 7278 5f74 696d ....0.....rx_tim
0x00b0: 653a 2020 2020 2020 2030 0a20 2020 2074 e:.......0.....t
0x00c0: 785f 7061 636b 6574 733a 2020 2020 3236 x_packets:....26
0x00d0: 3130 3535 360a 2020 2020 7478 5f62 7974 10556.....tx_byt
0x00e0: 6573 3a20 2020 2020 2033 3639 3038 3038 es:......3690808
0x00f0: 3738 310a 2020 2020 7478 5f6d 676e 745f 781.....tx_mgnt_
0x0100: 706b 7473 3a20 3139 3437 3337 340a 2020 pkts:.1947374...
0x0110: 2020 7478 5f75 6361 7374 5f70 6b74 733a ..tx_ucast_pkts:
0x0120: 2034 3534 3639 3032 0a20 2020 2074 785f .4546902.....tx_
0x0130: 6d63 6173 745f 706b 7473 3a20 3637 3030 mcast_pkts:.6700
0x0140: 0a20 2020 2074 785f 6263 6173 745f 706b .....tx_bcast_pk
0x0150: 7473 3a20 3433 3238 0a20 2020 2074 785f ts:.4328.....tx_
0x0160: 7265 7472 7973 3a20 2020 2020 3231 3433 retrys:.....2143
0x0170: 3333 0a20 2020 2074 785f 6661 696c 733a 33.....tx_fails:
0x0180: 2020 2020 2020 3534 3133 0a20 2020 2074 ......5413.....t
0x0190: 785f 6472 6f70 733a 2020 2020 2020 3731 x_drops:......71
0x01a0: 3039 0a20 2020 2074 785f 646d 615f 6572 09.....tx_dma_er
0x01b0: 723a 2020 2020 300a 2020 2020 7278 5f64 r:....0.....rx_d
0x01c0: 6d61 5f65 7272 3a20 2020 2030 0a20 2020 ma_err:....0....
Peut-être un routeur et son satellite, mal paramètres (parce que en APIPA) et qui fuient sur le LAN ?
-
J'ai parlé trop vite pour les fuites d'adresses privées qui sont parties…
Ma commande initiale ne les capte pas les IP en 224.xxx (mdns)
Donc en ayant ajusté la commande, on voit encore des fuites qui implique des adresses privées :
root@HERMES:~$ tcpdump -i ethwan -tnev "ether[6:2] == 0x001e and ether[8:1] == 0x80" | grep -e " 192.168." -e " 10." -e " 172.16." -B1
tcpdump: listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33548, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.55782 > 224.0.0.251.5353: 11533 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33549, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.57556 > 224.0.0.251.5353: 11534 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33551, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.44442 > 224.0.0.251.5353: 11535 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33552, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.47410 > 224.0.0.251.5353: 11536 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33553, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.40434 > 224.0.0.251.5353: 11537 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33554, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.59524 > 224.0.0.251.5353: 11538 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33557, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.59130 > 224.0.0.251.5353: 11539 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33558, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.56713 > 224.0.0.251.5353: 11540 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
--
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34182, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.35433 > 224.0.0.251.5353: 11541 PTR (QM)? 192.168.1.209.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34183, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.59909 > 224.0.0.251.5353: 11542 PTR (QM)? 192.168.1.209.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34184, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.42246 > 224.0.0.251.5353: 11543 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34186, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.50066 > 224.0.0.251.5353: 11544 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34187, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.48482 > 224.0.0.251.5353: 11545 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34188, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.47755 > 224.0.0.251.5353: 11546 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
--
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34189, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.60920 > 224.0.0.251.5353: 11547 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34190, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.47587 > 224.0.0.251.5353: 11548 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34192, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.45269 > 224.0.0.251.5353: 11549 PTR (QM)? 192.168.1.120.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34193, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.42585 > 224.0.0.251.5353: 11550 PTR (QM)? 192.168.1.120.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34196, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.51903 > 224.0.0.251.5353: 11551 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34197, offset 0, flags [DF], proto UDP (17), length 72)
92.118.99.232.51611 > 224.0.0.251.5353: 11552 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
^C122 packets captured
123 packets received by filter
0 packets dropped by kernel
-
J'ai parlé trop vite pour les fuites d'adresses privées qui sont parties…
Ma commande initiale ne les capte pas les IP en 224.xxx (mdns)
Donc en ayant ajusté la commande, on voit encore des fuites qui implique des adresses privées :
Bizarre, ça ne m'avait pas interpelé en regardant ton post précédent. Je pensais qu'avec les conditions de ton filtre tcpdump qui doit garder les multicasts (comme 01:00:5e:00:00:fb) avec une adresse en 192.168/16, les paquets mDNS auraient été conservés.
Et on voit bien sur cette nouvelle trace que ces paquets ont une entête IP correcte, avec un TTL à 1, confirmant d'ailleurs qu'ils ne doivent pas traverser un routeur.
-
De mon côté c'est quand même plus calme.
On passe de ça vendredi en quelques secondes
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\." 130 ↵
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
16:26:16.482212 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
16:26:16.517714 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:18.482067 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
16:26:19.020972 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
16:26:20.760805 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
16:26:21.482139 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
16:26:22.706413 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
16:26:22.926856 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.36341 > 224.0.0.251.5353: 21672 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:26:23.482125 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:26:24.482088 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:24.482408 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:26.537951 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:28.481897 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
16:26:29.247672 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.26, length 46
16:26:30.481830 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
16:26:33.967220 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.33527 > 224.0.0.251.5353: 21680 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:26:33.998734 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.41385 > 224.0.0.251.5353: 21682 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
16:26:34.030211 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.34575 > 224.0.0.251.5353: 21684 PTR (QM)? 192.168.1.168.in-addr.arpa. (44)
16:26:35.481786 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:26:36.557669 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:40.482126 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
16:26:40.482556 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
16:26:42.481746 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
16:26:42.482187 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:45.169935 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.58670 > 224.0.0.251.5353: 21694 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:26:46.577506 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:47.481692 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:26:52.481924 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
16:26:52.482211 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
16:26:54.481830 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
16:26:54.482122 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:54.482529 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:56.597905 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:56.666724 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.53264 > 224.0.0.251.5353: 21710 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
16:26:59.481808 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:27:00.886674 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.26, length 46
16:27:04.481722 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
16:27:06.481741 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
16:27:06.617468 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 778: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 736
16:27:07.537293 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.40481 > 224.0.0.251.5353: 21711 PTR (QM)? 192.168.1.242.in-addr.arpa. (44)
16:27:07.569811 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.39840 > 224.0.0.251.5353: 21713 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:27:07.613010 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.39121 > 224.0.0.251.5353: 21716 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
16:27:11.481740 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:27:12.481711 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
16:27:12.482018 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
^C456 packets captured
852 packets received by filter
0 packets dropped by kernel
à ça aujourd'hui en plusieurs minutes
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
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
09:14:10.958801 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.52696 > 224.0.0.251.5353: 14241 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
09:14:22.271957 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.58543 > 224.0.0.251.5353: 14257 PTR (QM)? 192.168.1.111.in-addr.arpa. (44)
09:14:33.377681 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.34218 > 224.0.0.251.5353: 14264 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
^C109 packets captured
1237 packets received by filter
Faudrait que je test en repassant en 192.168.1.1 voir si ya toujours des perturbation.
Par contre j'ai toujours des soucis d'accés à l'interface 'info' de ma box depuis les tests des ingés.
-
Faudrait que je test en repassant en 192.168.1.1 voir si ya toujours des perturbation.
Par contre j'ai toujours des soucis d'accés à l'interface 'info' de ma box depuis les tests des ingés.
Je serais toi, je resterais sur le numéro de réseau que tu as configuré. Tu as peut-être mieux à faire que débugger les problèmes K-Net.
Est-ce juste la partie "info" du panel qui bloque ? Ou tous les onglets ?
Pour info, chez moi, il faut actuellement plus de 20 secondes pour que l'onglet "info" s'affiche. Ca reste en "récupération des informations" un bon moment !
-
Bizarre, ça ne m'avait pas interpelé en regardant ton post précédent. Je pensais qu'avec les conditions de ton filtre tcpdump qui doit garder les multicasts (comme 01:00:5e:00:00:fb) avec une adresse en 192.168/16, les paquets mDNS auraient été conservés.
Et on voit bien sur cette nouvelle trace que ces paquets ont une entête IP correcte, avec un TTL à 1, confirmant d'ailleurs qu'ils ne doivent pas traverser un routeur.
En fait, le filtre « net » de tcpdump regarde seulement la source et la destination, qui ici sont 92.118.99.232 et 224.0.0.251, donc aucune n'est dans domaine privé.
Le TTL est intéressant… L'appareil Covage se comporte comme un simple relais pour tout ce qui est broadcast et multicast, ce qui est assez logique pour les transactions DHCP (IPv4 et IPv6).
En revanche, il laisse passer des paquets unicast comme ceux APIPA !?, mais heureusement pas ceux des clients connectés à leur passerelles (traffic internet).
Le problème de fuite (qu'elles quelles soient : DHCPv6, APIPA, mdns…) est double à mon avis :
1) La source du problème avec les K-Box qui fuient.
C'est un problème sérieux à résoudre (et apparemment bien pris sérieusement par K-Net)
2) Le fait que des paquets passent entre clients sur même GPON.
Comme Covage dispose d'un relais local DHCP qui gère les transactions pour le compte du serveur K-Net (un relais quoi), je ne comprends pas pourquoi ils laissent passer les paquets broadcast et multicast sur le GPON entre clients, ainsi que quelques paquets unicast. Comme ils filtrent déjà la plupart des paquets unicast, pourquoi ne pas améliorer le filtrage pour avoir une étanchéité totale entre les clients ?
Dans ce cas, même avec des fuites, elles seraient contenues puisqu'il y aurait une étanchéité entre clients.
Depuis 2 ans, il y a eu des progrès… Je pouvais faire un arping sur tous les clients (K-Net) du GPON et obtenir leur adresses MAC et les associer à leur IP. Donc je pouvais activement chercher et trouver tous les clients. Depuis, Covage a amélioré cela et si je peux toujours faire les arpings et trouver les IP publiques K-Net existantes sur mon GPON, l'adresse MAC retournée est toujours celui de la passerelle Covage, donc la MAC des clients et protégée de recherches actives (la recherche passive reste possible en écoutant les transactions DHCP impliquant du broadcast ou du multicast, excluant les DHCPv4 renew qui sont unicast)
Les problèmes existent parce que les points 1 et 2 existent simultanément.
Question aux experts réseau et infrastructure : y-a-t'il une difficulté technique ou une raison particulière empêchant Covage de réaliser une étanchéité totale entre clients sur un même GPON ?
-
Pour info, chez moi, il faut actuellement plus de 20 secondes pour que l'onglet "info" s'affiche. Ca reste en "récupération des informations" un bon moment !
J'ai directement le message
pLa KBOX est actuellement injoignable, réessayez ultérieurement
-
La KBOX est actuellement injoignable, réessayez ultérieurement
Bah, ils on connecté l'interface sur la même architecture que la téléphonie… ;D
-
En fait, le filtre « net » de tcpdump regarde seulement la source et la destination, qui ici sont 92.118.99.232 et 224.0.0.251, donc aucune n'est dans domaine privé.
J'avais effectivement lu la trace un peu rapidement, la source des paquets est l'adresse publique côté box, pas l'adresse en 192.168/16. Donc ton filtre initial ne fonctionnait pas.
Le TTL est intéressant… L'appareil Covage se comporte comme un simple relais pour tout ce qui est broadcast et multicast, ce qui est assez logique pour les transactions DHCP (IPv4 et IPv6).
En revanche, il laisse passer des paquets unicast comme ceux APIPA !?, mais heureusement pas ceux des clients connectés à leur passerelles (traffic internet).
Je ne te suis pas ...
Pour moi, la box est elle-même serveur DHCP sur la plage que tu configures par l'interface, en IPv4.
Elle n'est pas relais DHCP et les paquets DHCP du LAN n'ont pas à sortir.
Les paquets APIPA quels qu'ils soient n'ont pas à sortir du LAN non plus.
Je reste sur l'hypothèse que j'évoquais hier : Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA (sur leur interface WAN)?
...
Question aux experts réseau et infrastructure : y-a-t'il une difficulté technique ou une raison particulière empêchant Covage de réaliser une étanchéité totale entre clients sur un même GPON ?
C'est hors de mon champ de compétences.
Je ne suis d'ailleurs pas sûr que le réseau de mon OI (Covage canal historique) soit en GPON (plutôt en P2P).
-
J'avais effectivement lu la trace un peu rapidement, la source des paquets est l'adresse publique côté box, pas l'adresse en 192.168/16. Donc ton filtre initial ne fonctionnait pas.
C'est bien ça.
Je ne te suis pas ...
Pour moi, la box est elle-même serveur DHCP sur la plage que tu configures par l'interface, en IPv4.
Elle n'est pas relais DHCP et les paquets DHCP du LAN n'ont pas à sortir.
Les paquets APIPA quels qu'ils soient n'ont pas à sortir du LAN non plus.
Je reste sur l'hypothèse que j'évoquais hier : Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA (sur leur interface WAN)?
Par machine ou appareil Covage, je fais référence à la passerelle/relais chez Covage qui collecte les clients K-Net, ce sur quoi tous les clients K-Net du GPON (14 et 91) sont raccordés, et qui :
– laisse passer les paquets broadcast et multicast et l'unicast APIPA de l'appareil Siemens… depuis et vers tous les clients : comportement de proxy ou switch,
– fait office de relais DHCP pour le compte de K-Net (les clients DHCP WAN v4 ou v6 des clients ne se connectent pas directement au serveur DHCP de K-Net, mais au relais DHCP de Covage qui ajoute ses ACL et modifie la dure du bail à 5 minutes [le serveur K-Net demande 24h je crois]) ; bien entendu le relais Covage communique avec le serveur K-Net (cf. protocole DHCP Relay https://www.it-connect.fr/chapitres/quest-ce-quun-agent-relais-dhcp/).
– fait office de passerelle de routage et ne laisse (heureusement) pas passer les paquets unicast entre les clients (à part ce Siemens…).
En ce qui concerne la K-Box, on est bien d'accord :
– elle possède un serveur DHCP LAN pour la configuration IP des appareils sur le LAN. Ce n'est bien sûr pas un relais et ça doit rester uniquement sur le LAN. D'ailleurs, même avec les fuites, je crois qu'on ne voit pas passer de trames DHCP du LAN des clients impactés… Donc probablement un filtrage Covage de que les clients émettent sur les ports serveur DHCPv4 et v6, ce qui évite de plus gros problèmes encore dans le GPON avec plusieurs serveurs DHCP qui seraient en compétition…
– les paquets d'adresses APIPA de la K-Box (quelle que soit leur raison d'être) n'ont pas à être sur le GPON (donc envoyés côté WAN par les K-Box).
Sur l'origine des adresses APIPA, c'est le plus logiquement (comme tu le suppose) :
– soit une configuration automatique APIPA de l'interface côté LAN qui fuit sur le GPON (donc on voit ces paquets à cause du bogue de la fuite déjà mentionné),
– soit une configuration automatique APIPA de l'interface côté WAN qui du coup ne fuit pas, mais ce serait là une grossière erreur de conception…
Maintenant, pourquoi Covage ne bloque-t'il pas (entre autres) les adresses APIPA dans le GPON ? Car non seulement les paquets APIPA broadcast et multicast sont transmis entre les clients du GPON, mais également certains paquets unicast (paquets Siemens…)
Pourquoi Covage relais-t'il les paquets broadcast et multicast entre tous les clients d'un même GPON ? Ils pourrait déjà restreindre aux seuls paquets nécessaires (DHCP), et par la suite cloisonner les clients (je ne vois vraiment pas ce qui pourrait bloquer cela techniquement, mais sans un datagram de l'infra de collecte Covage, on ne peut que discuter dans le vide).
C'est hors de mon champ de compétences.
Je ne suis d'ailleurs pas sûr que le réseau de mon OI (Covage canal historique) soit en GPON (plutôt en P2P).
Peut-être une différence qui explique pourquoi tu ne rencontres pas de problèmes avec ta K-Box ?
Peut-être que tu as des fuites, mais que la partie Covage historique ne les laisse pas passer, donc au final tout va bien. Si tu as le temps un jour, je serais curieux de savoir ce que tu entends dans ta boucle… Peut-être est-elle silencieuse…
Mon GPON est tout le 14 et une partie du 91 (Tutor historique), et force est de constater que les problèmes de fuite (LAN/WAN) et le bogue de boucle DHCPv6 ne semblent se présenter (ou être visibles) que sur mon GPON et peut-être quelques autres, mais ce n'est apparemment pas présent dans toutes les collectes Covage de France, et à priori pas du tout chez les autres OI… Donc je suspecte qu'il y a probablement plus de K-Box défaillantes qu'on ne le pense, mais selon les boucles de collectes dans lesquelles elles se trouvent, ces défaillances sont invisibles et sans conséquences (pour le client et ses voisins de boucle…)
Ca semble aussi confirmer que certaines boucles sont peut-être mieux conçues (meilleur cloisonnement des clients) que d'autres…
Autre indice… tu n'as jamais eu IPv6 fonctionnel… Alors que moi si. Donc nous sommes sur deux boucles bien différentes (Covage historique et Tutor historique).
-
Merci de tes réponses précises. On s'y perd un peu entre "fuite LAN", "WAN trop bavard" etc.
D'autant plus qu'on est un peu aveugles (moi plus que toi) sur les composants d'infrastructure Covage entre nos PTO et K-Net.
Sur ta suggestion :
Peut-être une différence qui explique pourquoi tu ne rencontres pas de problèmes avec ta K-Box ?
Peut-être que tu as des fuites, mais que la partie Covage historique ne les laisse pas passer, donc au final tout va bien. Si tu as le temps un jour, je serais curieux de savoir ce que tu entends dans ta boucle… Peut-être est-elle silencieuse…
J'ai un vieux PC sous fedora branché en Ethernet à la box (tout le reste est en WIFI chez moi), je tenterai un "port mirroring" un soir pour chercher des paquets suspects côté WAN.
-
Sur ta suggestion :J'ai un vieux PC sous fedora branché en Ethernet à la box (tout le reste est en WIFI chez moi), je tenterai un "port mirroring" un soir pour chercher des paquets suspects côté WAN.
Premier tentative de port mirroring du port WAN de la K-Box vers le port Ethernet où se trouve le PC sur lequel je lance tcpdump.
Je ne vois pas le trafic WAN :(
La configuration modifiée apparaît bien dans le panel de la box, que j'ai redémarrée pour être sûr que les modifications avaient été appliquées (alors que l'enregistrement de la modification de configuration provoque déjà un reboot de la box).
-
Premier tentative de port mirroring du port WAN de la K-Box vers le port Ethernet où se trouve le PC sur lequel je lance tcpdump.
Je ne vois pas le trafic WAN :(
La configuration modifiée apparaît bien dans le panel de la box, que j'ai redémarrée pour être sûr que les modifications avaient été appliquées (alors que l'enregistrement de la modification de configuration provoque déjà un reboot de la box).
Tu ne vois rien du tout ?
L'autre solution est de mettre le PC directement sur l'ONT, et de cloner la MAC de la K-Box.
Sinon sur les paquets APIPA, VincentO2 avait déjà donné les clefs ici : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943167/#msg943167
Il m'a expliqué que les paquets APIPA viennent bien de la K-Box dont l'architecture possède deux SoC (un séparé pour le Wifi 5 GHz).
Les box qui fuient sont donc détectables par ces paquets APIPA, et j'améliorerai mon script (celui qui log les spam DHCPv6 s'ils survenaient à nouveau) pour logger les MAC des K-Box qui fuient sur mon GPON.
-
Tu ne vois rien du tout ?
L'autre solution est de mettre le PC directement sur l'ONT, et de cloner la MAC de la K-Box.
Rien non plus chez moi (Covage74) sur le WAN sauf quand j'avais merdé la config de mon trunck (VLAN marqué) entre étage. A l'époque VincentO me l'avait signalé et je m'était un peu demandé comment il l'avait repéré (maintenant je sais comment!).
J'ai un switch manageable entre ONT et k-box, avec lequel je peux faire du port-mirroring vers mon LAN.
Absolument aucun paquet qui ne m'est pas destiné.
Et tous les paquets que je vois passer sont bien issus de la MAC de la passerelle K-net (IP.254).
-
Tu ne vois rien du tout ?
L'autre solution est de mettre le PC directement sur l'ONT, et de cloner la MAC de la K-Box.
J'ai fait ça brièvement ce matin en branchant mon PC sous Fedora directement sur l'ONT après avoir cloné l'adresse MAC WAN de ma box.
Rappel de la procédure sur Linux :
- identifier son adresse MAC côté WAN, en allant sur l'espace client K-Net
- identifier le nom de son interface Ethernet (ex : sudo ip link show)
- (débrancher le PC s'il est branché ailleurs)
- cloner l'adresse MAC : sudo ip link set dev nom-de-l-interface address adresse-MAC-KBOX
- activer l'interface : sudo ip link set dev nom-de-l-interface up
- brancher le PC sur l'ONT. Le PC prend l'adresse IP publique de la box, s'il est configuré en client DHCP.
Rien de suspect a priori sur une minute de tcpdump :
- du trafic émis par mon PC (je n'avais pas désactivé les services, ni même fermé les applications)
- du trafic TCP destiné à mon adresse publique rejeté par le PC : ça peut être des connexions qui pré-existaient sur mon LAN (avec le NAT en place sur la box), ou des tentatives de connexion en provenance de quelques sources extérieures (séquences TCP SYN/RESET).
- quelques multicasts pour de l'IGMP. Les sources sont 10.0.0.11, 10.0.0.111, 10.0.0.113. Ca doit des routeurs du réseau COVAGE, mais dans un bloc d'adresse différent (je vois 10.2.0.143 comme hop lors des traceroute)
Et tous les paquets que je vois passer sont bien issus de la MAC de la passerelle K-net (IP.254).
Je n'avais pas pris l'option de tcpdump pour garder les entêtes Ethernet, je referai l'expérience une autre fois pour confirmer l'origine des paquets que je reçois.
-
Je n'avais pas pris l'option de tcpdump pour garder les entêtes Ethernet, je referai l'expérience une autre fois pour confirmer l'origine des paquets que je reçois.
Je triche en utilisant https://www.wireshark.org/ (https://www.wireshark.org/) qui affiche tout le contenu des paquets facilement. ;)
-
C'est intéressant…
Sur 1 seconde d'écoute, pour tout ce qui ne me concerne pas en broadcast et multicast, j'obtiens une dizaine de packets :
root@HERMES:~$ timeout 1 tcpdump -i ethwan -ne broadcast or multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
13:53:13.072716 00:1e:80:93:04:b0 > 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
13:53:13.113828 00:11:32:XX:XX:XX > 33:33:ff:91:6f:e4, ethertype IPv6 (0x86dd), length 86: fe80::211:32ff:XXXX:XXXX > ff02::1:ff91:6fe4: ICMP6, neighbor solicitation, who has fe80::120d:7fff:fe91:6fe4, length 32
13:53:13.254878 00:11:32:XX:XX:XX > 33:33:ff:7f:de:3e, ethertype IPv6 (0x86dd), length 86: 2a02:c442:c1b9:XXXX:XXXX:XXXX:XXXX:XXXX > ff02::1:ff7f:de3e: ICMP6, neighbor solicitation, who has fe80::21e:80ff:fe7f:de3e, length 32
13:53:13.292397 2c:30:33:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::2e30:33ff:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:53:13.398583 e8:fc:af:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:53:13.465437 00:1e:80:XX:XX:XX > 33:33:ff:2a:2e:22, ethertype IPv6 (0x86dd), length 78: :: > ff02::XXXX:XXXX:XXXX: ICMP6, neighbor solicitation, who has 2a03:4980:200:4a00::672a:2e22, length 24
13:53:13.594709 00:1e:80:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:53:13.613859 3c:7c:3f:XX:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.219.207.254 tell 185.219.XXX.XXX, length 46
13:53:13.625168 00:1e:80:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:53:13.685806 00:1e:80:93:0b:58 > 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
13:53:13.698239 00:1e:80:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::21:0:1, length 32
13:53:13.775090 a4:2b:8c:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::a62b:XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:53:13.799489 e8:fc:af:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::eafc:XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
13:53:13.813578 84:1b:5e:XX:XX:XX > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2a03:4980::XXXX:XXXX:XXXX > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2a03:4980::1a:0:1, length 32
14 packets captured
14 packets received by filter
0 packets dropped by kernel
Deux paquets APIPA venant de deux K-Box en mode fuite
Le reste sont des requêtes ARP et des neighbor solicitation ICMP6
Ce n'est que sur une seule seconde. Durant cette seconde particulière, je n'ai capturé aucun paquet BOOTP (DHCPv4) ou DHCPv6, mais il sont aussi très fréquents (les négociations normales DHCPv4 et v6 des clients).
Il semble donc qu'entre mon GPON d'un côté, et ceux de Steph ou pju91, il y ait bien une différence de conception, puisqu'ils ne voient aucun de ce type de paquets.
Covage 91 historique et Covage 74 semblent donc avoir une réelle étanchéité de tous les paquets entre les clients, y compris pour le broadcast et multicast.
Ca semble donc confirmer mon hypothèse que les problèmes rencontrés par les clients K-Net sur la boucle Tutor historique 14 et 91 proviennent de la conjonction de deux choses :
1- les différents problèmes au niveau de certaines K-Box (fuite, spam DHCPv6…)
2- la porosité dans le GPON entre les clients aux paquets broadcast, multicast et certains unicast.
Bien entendu, les problèmes de fuite des K-Box doivent absolument être résolu.
Par ailleurs, si Covage 14 et 91 (réseau Tutor historique) pouvait améliorer l'étanchéité entre clients, ça serait bien aussi…
-
C'est intéressant…
Sur 1 seconde d'écoute, pour tout ce qui ne me concerne pas en broadcast et multicast, j'obtiens une dizaine de packets :
<<< couic >>>
Ce n'est que sur une seule seconde. Durant cette seconde particulière, je n'ai capturé aucun paquet BOOTP (DHCPv4) ou DHCPv6, mais il sont aussi très fréquents (les négociations normales DHCPv4 et v6 des clients).
voir ci-dessous (il trainait encore un mdns issu de mon PC) :
$ egrep -v "mon-ip-publique|mdns" trace-retravaillee.txt
08:05:02.386997 IP 10.0.0.113 > 224.0.0.1: igmp query v2
08:05:29.719343 IP6 fe80::7386:746f:4f84:4cb0 > ff02::2: ICMP6, router solicitation, length 8
08:05:32.210504 IP 10.0.0.110 > 224.0.0.1: igmp query v2
08:05:38.017117 IP 10.0.0.11 > 224.0.0.1: igmp query v2 [max resp time 200]
C'est tout ce que j'ai vu ce matin. Je n'avais pas de filtre tcpdump.
Il semble donc qu'entre mon GPON d'un côté, et ceux de Steph ou pju91, il y ait bien une différence de conception, puisqu'ils ne voient aucun de ce type de paquets.
Covage 91 historique et Covage 74 semblent donc avoir une réelle étanchéité de tous les paquets entre les clients, y compris pour le broadcast et multicast.
Ca semble donc confirmer mon hypothèse que les problèmes rencontrés par les clients K-Net sur la boucle Tutor historique 14 et 91 proviennent de la conjonction de deux choses :
1- les différents problèmes au niveau de certaines K-Box (fuite, spam DHCPv6…)
2- la porosité dans le GPON entre les clients aux paquets broadcast, multicast et certains unicast.
Bien entendu, les problèmes de fuite des K-Box doivent absolument être résolu.
Par ailleurs, si Covage 14 et 91 (réseau Tutor historique) pouvait améliorer l'étanchéité entre clients, ça serait bien aussi…
Clairement, l'ingéniérie des réseaux Tutor et Covage (historique) n'est pas la même.
Comme en plus, je bénéficie d'un raccordement à un PM récent (ouverture commerciale fin 2018), ce n'est pas encore la jungle et je ne subis pas de déconnexions intempestives comme sur des réseaux plus anciens où le "churn" et les nouveaux raccordements dégradent les PBO et PM, donc mon accès Internet est très stable.
-
voir ci-dessous (il trainait encore un mdns issu de mon PC) :
$ egrep -v "mon-ip-publique|mdns" trace-retravaillee.txt
08:05:02.386997 IP 10.0.0.113 > 224.0.0.1: igmp query v2
08:05:29.719343 IP6 fe80::7386:746f:4f84:4cb0 > ff02::2: ICMP6, router solicitation, length 8
08:05:32.210504 IP 10.0.0.110 > 224.0.0.1: igmp query v2
08:05:38.017117 IP 10.0.0.11 > 224.0.0.1: igmp query v2 [max resp time 200]
C'est tout ce que j'ai vu ce matin. Je n'avais pas de filtre tcpdump.
Clairement, l'ingéniérie des réseaux Tutor et Covage (historique) n'est pas la même.
Comme en plus, je bénéficie d'un raccordement à un PM récent (ouverture commerciale fin 2018), ce n'est pas encore la jungle et je ne subis pas de déconnexions intempestives comme sur des réseaux plus anciens où le "churn" et les nouveaux raccordements dégradent les PBO et PM, donc mon accès Internet est très stable.
J'aime bien le <<< couic >>> ;D
Mon NRO/PM a aussi ouvert en 2018, donc le réseau physique est propre, je n'ai jamais connu les problèmes de déconnexion LOS rouge dus à des sous-maltraitants…
Suite à un effacement des réseaux aériens programmé, ma ligne fibre va être à nouveau toute neuve jusqu'au NRO.
Ma connexion est aussi très stable, et depuis 2018, à part quelques très rares coupures dues essentiellement à Covage (maintenances), et en janvier une (moins de 24h) due à K-Net, tout fonctionne bien.
L'IPv6 était aussi très stable avant son interruption par K-Net.
C'est simplement que le design de la collecte Tutor historique et différente de celle de Covage historique. Je n'ai pas à ma connaissance de paquets igmp dans ma boucle… tcpdump -i ethwan igmp ne retourne absolument rien.
Tu as cependant un ICMPv6… il vient de ton PC ? Ou du relais Covage ? Si non, il n'y aurait donc pas une étanchéité totale… Peut-être que tu ne verrais que certains paquets seulement sur ton PM ?
Parce que pour mon GPON, c'est tous les paquets broadcast, multicast et quelques unicast de l'ensemble du 14 et de la partie Tutor historique du 91 que je vois… C'est large quand même !
-
Tu as cependant un ICMPv6… il vient de ton PC ? Ou du relais Covage ? Si non, il n'y aurait donc pas une étanchéité totale… Peut-être que tu ne verrais que certains paquets seulement sur ton PM ?
Mon PC s'autoconfigure certes en IPV6 (avec une adresse link local). Je ne l'ai pas regardée durant mon test, mais un calculateur d'adresse IPv6 link local (par rapport à la MAC de la K-Box ou à l'adresse physique) me donne d'autres adresses que celle vue dans la trace.
Toutefois, comme c'est du multicast pour "tous les routeurs du réseau local", ça ne me choque pas de trouver un tel paquet.
Je referai des tests sur une plus longue période (et en gardant les entêtes Ethernet).
-
Mon PC s'autoconfigure certes en IPV6 (avec une adresse link local). Je ne l'ai pas regardée durant mon test, mais un calculateur d'adresse IPv6 link local (par rapport à la MAC de la K-Box ou à l'adresse physique) me donne d'autres adresses que celle vue dans la trace.
Toutefois, comme c'est du multicast pour "tous les routeurs du réseau local", ça ne me choque pas de trouver un tel paquet.
Je referai des tests sur une plus longue période (et en gardant les entêtes Ethernet).
Non ce n'est pas choquant bien sûr, et vu la très faible quantité que tu vois, si ça venait d'un autre appareil que ton PC ou le relais, c'est à priori local à ton PM, donc beaucoup moins déraisonnable que l'ensemble des PM d'un département et demi !
Et en plus, ça serait limité aux ICMP… car tu ne vois pas apparemment les ARP et DHCP… donc pas les mêmes risques de collisions entres LAN qui serait connectés par mégarde sur la boucle.
-
Pour être sûr, je viens de refaire un dump en filtrant petit à petit pour ne rien louper.
Coté LAN : Absolument rien du WAN. :) Ma k-box ne permet pas de téléphoner mais elle ne fuit pas!
Coté WAN : Tout le trafic extérieur vient de la passerelle K-net-Covage74. Je ne vois même pas les DHCP Discover, les ARP, les ICMP 4 ou 6 .
J'aimerais bien voir du SIP mais c'est silence téléphone chez moi!
Ma mac K-box LAN : finie en b6
Ma mac K-box WAN : finie en b4
-
J'aimerais bien voir du SIP mais c'est silence téléphone chez moi!
Trouvez-vous donc un ami venu d'ailleurs.
FB téléphone maaiiiison.
-
Pour être sûr, je viens de refaire un dump en filtrant petit à petit pour ne rien louper.
Coté LAN : Absolument rien du WAN. :) Ma k-box ne permet pas de téléphoner mais elle ne fuit pas!
Coté WAN : Tout le trafic extérieur vient de la passerelle K-net-Covage74. Je ne vois même pas les DHCP Discover, les ARP, les ICMP 4 ou 6 .
J'aimerais bien voir du SIP mais c'est silence téléphone chez moi!
Ma mac K-box LAN : finie en b6
Ma mac K-box WAN : finie en b4
Autres tests de mon côté.
TL;DR : je confirme ce que Steph a trouvé, sur 10 minutes de trace côté WAN : rien de suspect. Lorsque je prends des traces régulièrement côté LAN, rien de suspect non plus.
1. J'ai obtenu une trace WAN, après avoir rebranché mon PC directement sur l'ONT par :
$ sudo timeout 600 tcpdump -i enp3s0f4u1 -nev >trace-`date "+%F-%H-%M"`
2. j'ai ensuite "anonymisé mes adresses IP et MAC dans le fichier obtenu et recherché les paquets qui ne me concernaient pas :
$ grep ether anon |grep -v ma-mac
19:54:43.349750 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:55:12.133183 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:55:17.961273 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:55:43.423853 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:56:12.204715 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:56:18.021330 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:56:43.473737 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:57:12.295667 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:57:18.122548 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:57:43.577163 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:58:12.378247 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:58:18.214669 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:58:43.686676 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:59:12.484144 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:59:18.303763 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:59:43.756094 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:11.880361 00:02:5d:bb:1d:78 > 01:00:5e:10:8a:02, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:12.548478 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:18.353845 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:43.754904 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:01:12.489243 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:01:18.293895 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:01:43.687233 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:02:12.433424 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:02:18.248531 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:02:43.634368 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:03:12.370115 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:03:18.185380 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:03:43.577282 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:04:12.333938 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:04:18.138524 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
3. J'ai regardé de plus près ces (31) paquets, qui proviennent toujours de la même source Ethernet (routeur Covage ?), mais sur des VLAN différents.
$ grep -A1 IGMP trace-2022-04-26-19-54-anon|head -15
19:54:43.349750 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.113 > 224.0.0.1: igmp query v2
--
19:55:12.133183 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.110 > 224.0.0.1: igmp query v2
--
19:55:17.961273 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.11 > 224.0.0.1: igmp query v2 [max resp time 200]
--
19:55:43.423853 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.113 > 224.0.0.1: igmp query v2
--
19:56:12.204715 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.110 > 224.0.0.1: igmp query v2
--
4. J'ai vérifié que ces paquets viennent de 3 adresses IP distinctes, sur le réseau Covage a priori :
$ grep -A1 IGMP anon |grep -o "10.0.0.*> " |sed 's/ >//'|sort|uniq -c
10 10.0.0.11
10 10.0.0.110
11 10.0.0.113
Donc, pas de "pollution" par les autres types de paquets que voit bolemo...
-
Autres tests de mon côté.
TL;DR : je confirme ce que Steph a trouvé, sur 10 minutes de trace côté WAN : rien de suspect. Lorsque je prends des traces régulièrement côté LAN, rien de suspect non plus.
1. J'ai obtenu une trace WAN, après avoir rebranché mon PC directement sur l'ONT par :
$ sudo timeout 600 tcpdump -i enp3s0f4u1 -nev >trace-`date "+%F-%H-%M"`
2. j'ai ensuite "anonymisé mes adresses IP et MAC dans le fichier obtenu et recherché les paquets qui ne me concernaient pas :
$ grep ether anon |grep -v ma-mac
19:54:43.349750 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:55:12.133183 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:55:17.961273 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:55:43.423853 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:56:12.204715 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:56:18.021330 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:56:43.473737 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:57:12.295667 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:57:18.122548 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:57:43.577163 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:58:12.378247 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:58:18.214669 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:58:43.686676 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:59:12.484144 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:59:18.303763 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
19:59:43.756094 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:11.880361 00:02:5d:bb:1d:78 > 01:00:5e:10:8a:02, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:12.548478 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:18.353845 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:00:43.754904 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:01:12.489243 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:01:18.293895 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:01:43.687233 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:02:12.433424 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:02:18.248531 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:02:43.634368 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:03:12.370115 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:03:18.185380 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:03:43.577282 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:04:12.333938 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
20:04:18.138524 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
3. J'ai regardé de plus près ces (31) paquets, qui proviennent toujours de la même source Ethernet (routeur Covage ?), mais sur des VLAN différents.
$ grep -A1 IGMP trace-2022-04-26-19-54-anon|head -15
19:54:43.349750 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.113 > 224.0.0.1: igmp query v2
--
19:55:12.133183 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.110 > 224.0.0.1: igmp query v2
--
19:55:17.961273 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 167, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.11 > 224.0.0.1: igmp query v2 [max resp time 200]
--
19:55:43.423853 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 113, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.113 > 224.0.0.1: igmp query v2
--
19:56:12.204715 00:02:5d:bb:1d:78 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 180, p 4, ethertype IPv4 (0x0800), (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
10.0.0.110 > 224.0.0.1: igmp query v2
--
4. J'ai vérifié que ces paquets viennent de 3 adresses IP distinctes, sur le réseau Covage a priori :
$ grep -A1 IGMP anon |grep -o "10.0.0.*> " |sed 's/ >//'|sort|uniq -c
10 10.0.0.11
10 10.0.0.110
11 10.0.0.113
Donc, pas de "pollution" par les autres types de paquets que voit bolemo...
Très propre en effet, et les rares paquets sont normaux.
-
Bon voilà,
J'ai donc amélioré mon script qui mesure les fuites APIPA et les spam DHCPv6 et vérifie toutes les 2 minutes.
Il envoie les données à mon serveur grafana qui génère un suivi en temps réel (à 2 minutes près) et offre un historique des MAC concernées et du type de problème (fuite ou spam DHCPv6).
Il me reste à trouver comment partager mon dashboard publiquement, et je donnerai le lien à K-Net.
(https://i.ibb.co/GPvLyBW/Capture-d-cran-2022-04-27-16-49-02.png)
La mesure nommée "Moniteur" est un témoin indiquant que le monitoring est actif. Si j'ai une coupure internet, ou que je fais une maintenance sur mon serveur (ou routeur), alors le témoin permet de savoir que l'absence de données vient du fait que mon monitoring est off.
Voilà qui complète mon monitoring du réseau et de l'infra… Mes sondes smokeping (depuis ma connexion et depuis l'extérieur), mon betteruptime, mon suivi des statistiques mesurées par ONT, et maintenant cela.
Un mini NOC à la maison ;D
-
Il me reste à trouver comment partager mon dashboard publiquement, et je donnerai le lien à K-Net.
Un mini NOC à la maison ;D
A ce niveau, tu peux leur vendre ta solution !
Bravo !
-
Parce que pour mon GPON, c'est tous les paquets broadcast, multicast et quelques unicast de l'ensemble du 14 et de la partie Tutor historique du 91 que je vois… C'est large quand même !
1 - c'est que t'es pas en gpon
2 - version altyernative : tous les gpon arrive sur un switch, qui te met dans le vlan k-net, et tu vois tout.
-
A ce niveau, tu peux leur vendre ta solution !
Bravo !
Il faudrait presque que les collectivités locales qui ont financé les OI possèdent un outils de monitoring sur la qualité de l'infra OI… Mais évidemment, s'ils ont délégué la gestion à un OI, c'est bien pour ne pas avoir à gérer tout cela eux-même.
1 - c'est que t'es pas en gpon
2 - version altyernative : tous les gpon arrive sur un switch, qui te met dans le vlan k-net, et tu vois tout.
Comme Covage est d'un silence total, impossible d'en savoir plus sur l'infra… On ne peut que constater que 14 (qui était Tutor) et une partir du 91 (celle qui était Tutor) sont liés… Peut-être les GPON reliés sur un vlan K-Net. Je ne vois pas d'autres régions Covage et encore moins d'autres OI. On sait aussi que la partie 91 qui est toujours Covage, mais qui n'était pas Tutor (celle où se trouve pju91) a une infra différente.
-
Comme Covage est d'un silence total, impossible d'en savoir plus sur l'infra… On ne peut que constater que 14 (qui était Tutor) et une partir du 91 (celle qui était Tutor) sont liés… Peut-être les GPON reliés sur un vlan K-Net. Je ne vois pas d'autres régions Covage et encore moins d'autres OI. On sait aussi que la partie 91 qui est toujours Covage, mais qui n'était pas Tutor (celle où se trouve pju91) a une infra différente.
Steph en Haute-Savoie aussi semble être sur un réseau "propre".
-
https://atlas.ripe.net/frames/probes/?search=24904&status=1&af=&country#tab-public
La sonde 21312 qui possède une IPV4 K-NET et IPV6 Freebox :P
-
https://atlas.ripe.net/frames/probes/?search=24904&status=1&af=&country#tab-public
La sonde 21312 qui possède une IPV4 K-NET et IPV6 Freebox :P
Du coup, comment interprètes tu les informations de disponibilité de l'onglet network :
https://atlas.ripe.net/frames/probes/21312/#tab-network ?
-
Voilà, j'ai donné le lien de mon monitoring à FB, au NOC K-Net et Altitude Infra.
-
Bon, avec un peu de distance, ça fonctionne bien :
(https://i.ibb.co/z5vpPmm/Capture-d-cran-2022-04-28-12-37-02.png)
Espérons que cela aide K-Net à cibler les K-Box à problème (car depuis leur infra, ils ne peuvent pas voir ces fuites).
-
C'est vraiment top, bravo. 8)
-
C'est vraiment top, bravo. 8)
Merci.
C'était une occasion d'approfondir mes connaissances dans Grafana ;)
-
Coincidence ?
Toutes les K-Box qui fuyaient ne fuient plus :)
Reste simplement l'appareil Siemens sur lequel K-Net n'a probablement aucun contrôle (un routeur perso ou une mauvaise installation du réseau local de ce client ?).
(https://i.ibb.co/jGCWnms/Capture-d-cran-2022-04-28-15-06-23.png)
-
Coincidence ?
Toutes les K-Box qui fuyaient ne fuient plus :)
Reste simplement l'appareil Siemens sur lequel K-Net n'a probablement aucun contrôle (un routeur perso ou une mauvaise installation du réseau local de ce client ?).
Certainement pas une coïncidence.
Excellent !
-
Certainement pas une coïncidence.
Excellent !
Oui, c'est excellent !
Et VincentO2 avait bien raison (je n'en doutais pas), maintenant qu'il n'y a plus de K-Box avec des fuites APIPA, on ne voit plus non plus de fuites des réseaux privés :
tcpdump -i ethwan -te net 192.168.0.0/16 retourne un beau silence.
-
Oui, c'est excellent !
Et VincentO2 avait bien raison (je n'en doutais pas), maintenant qu'il n'y a plus de K-Box avec des fuites APIPA, on ne voit plus non plus de fuites des réseaux privés :
tcpdump -i ethwan -te net 192.168.0.0/16 retourne un beau silence.
superpicsou a ouvert ce fil il y a 3 semaines.
Quand on compare au temps de résolution de certains incidents, c'est plutôt bien comme TTR ;)
Bon, il faut que K-Net utilise ton monitoring pour faire ce qui est nécessaire quand un incident de ce type survient.
Et maintenant, on espère que les clients n'auront plus ces phénomènes "bizarres" qui finalement sont en fait des duplications d'adresse IP sur leurs LAN.
-
superpicsou a ouvert ce fil il y a 3 semaines.
Quand on compare au temps de résolution de certains incidents, c'est plutôt bien comme TTR ;)
Bon, il faut que K-Net utilise ton monitoring pour faire ce qui est nécessaire quand un incident de ce type survient.
Et maintenant, on espère que les clients n'auront plus ces phénomènes "bizarres" qui finalement sont en fait des duplications d'adresse IP sur leurs LAN.
Oui, je crois que le blocage principal était l'absence de visibilité de K-Net sur la boucle locale ici.
Dans l'idéal, sur une offre active Covage, et sur une collecte qui laisse passer les paquets broadcast et multicast entre les clients, Covage devrait donner un accès au FAI pour ce genre de situation…
Au moins, nous avons mis le doigt sur le problème, aidés par VincentO2.
Mon monitoring ne fait que montrer qu'il existe des solutions assez simples pour tracker les K-Box, et j'espère dynamise (et motive) les équipes de K-Net, et permettra d'améliorer la communication K-Net/Covage.
J'espère aussi que ce progrès va se ressentir chez ceux qui avaient des coupures et problèmes de syncro sur cette large boucle.
Cela montre aussi que K-Net ne dort pas… Je leur donne un outil permettant de voir ce qu'ils ne peuvent voir (mais Covage peut…), et ils agissent en quelques heures.
Je vais bien sûr laisser mon monitoring en service, ça me prend très peu de ressources, et c'est intéressant aussi. C'est agréable de savoir qu'on peut aider :)
-
Je trouve ça dommage que k-net ne te remercie même pas, tu les aides énormément en faisant ça. Mais bon.
-
Je trouve ça dommage que k-net ne te remercie même pas, tu les aides énormément en faisant ça. Mais bon.
Faut croire que Monsieur Kom a dit de ne pas le faire et que monsieur CTO est jaloux! :P
C'est comme mon tour de France des routeurs K-net ou l'état de l'IPv6 sur les différentes plaques sur feu Caps ou les soucis SNMP ou les K-box a hausse de ping depuis et vers certaines destination ou le traitement des dossiers sensibles (Gailles) ! ::)
C'est comme ta modération sur Caps.
On ne le fait pas pour les remerciements, mais c'est vrai que se faire ignorer comme cela est un comble pour de la proximité! :(
-
Bravo bolemo
-
Je pense qu'il y a un mot d'ordre de ne pas communiquer… Comme le suppose Steph, probablement sur recommandation du consultant com… C'est aussi une stratégie de plusieurs grosses boîtes.
C'est dommage, car cette approche com est nuisible plus qu'autre chose à K-Net. D'autant que certain clients comme moi sont aussi investisseurs. J'ai assez prouvé par mes actions (comme beaucoup d'autres ici ou sur Caps) que je ne suis pas anti K-Net et que je n'aimerais rien de mieux que de les voir redevenir ce FAI unique, efficace, proche et transparent.
C'est dommage, parce que techniquement, ils tiennent le coup (tout ne s'est pas écroulé), et qu'à part de réels soucis qui doivent évidemment absolument être résolus (téléphonie qui semble encore problématique pour un certain nombre de clients, IPv6…) leur talon d'Achille est la communication. On ne sait pas où ils veulent aller, ni où ils en sont, ni ce qu'ils font.
Certain problèmes qui affectaient de nombreux clients, surtout dans ma collecte (un département et demi), auraient pu être résolu plus rapidement avec une communication…
Ils ont pu être résolu parce que nous leur avons communiqué les problèmes, parce que VincentO2 a donné des explications, parce que pju91 a contacté Icotera, et parce que suite à tout cela, j'ai mis en place un monitoring effectif ; ou parce que j'avais tweeté à FB, Covage, Altitude et le Département sur le spam DHCPv6…
D'ailleurs, on va bien voir leur réactivité, car les fuites reviennent depuis environ 18h :
(https://i.ibb.co/ths5nFQ/Capture-d-cran-2022-04-28-18-06-45.png)
-
Les boxs qui fuitent sont synchrones?!!
-
Les boxs qui fuitent sont synchrones?!!
Bonne remarque. ;)
-
Oui, j'ai remarqué… Et il y a une petite nouvelle (K-Box) dans le lot.
Je crois que VincentO disait qu'il suffisait d'un élément déclencheur pour démarrer le bal…
Je ne vais pas poster ici ce qu'il ma indiqué (pour ne pas donner des idées…) mais il y a une vulnérabilité matérielle qui peut être exploitée…
-
... Je crois que VincentO disait qu'il suffisait d'un élément déclencheur pour démarrer le bal ...
ah ? que la fête commence ! ::) C'est la m... ça
-
Sinon, j'ai aussi amélioré le visuel du monitoring qui a maintenant un onglet spécifique pour ne voir que les K-Box. Grafana, c'est pas mal quand même…
(https://i.ibb.co/B3T8Vtd/Capture-d-cran-2022-04-28-18-55-46.png)
PS : il y a un patch firmware, mais c'est probablement pour ça que les K-Box concernées doivent retourner en atelier…
-
Sinon, j'ai aussi amélioré le visuel du monitoring qui a maintenant un onglet spécifique pour ne voir que les K-Box. Grafana, c'est pas mal quand même…
Dommage que ça soit revenu ... et qu'à cette heure ci, personne ne regarde ton monitoring chez K-Net.
-
Dommage que ça soit revenu ... et qu'à cette heure ci, personne ne regarde ton monitoring chez K-Net.
Oui, le problème est revenu à la fermeture des bureaux… curieux. On verra demain.
-
Encore un coup du KGB :D
-
Je crois que VincentO disait qu'il suffisait d'un élément déclencheur pour démarrer le bal…
Je ne vais pas poster ici ce qu'il ma indiqué (pour ne pas donner des idées…) mais il y a une vulnérabilité matérielle qui peut être exploitée…
Vulnérabilité matérielle ?
Si l'événement déclencheur est connu (j'imagine que c'est un paquet sur le réseau), il faudrait que l'OI parvienne à le filtrer, ou que K-Net pousse une règle ebtables sur toutes les K-Box (mais moins sûr que ça fonctionne, ça dépend du bug).
-
Vulnérabilité matérielle ?
Si l'événement déclencheur est connu (j'imagine que c'est un paquet sur le réseau), il faudrait que l'OI parvienne à le filtrer, ou que K-Net pousse une règle ebtables sur toutes les K-Box (mais moins sûr que ça fonctionne, ça dépend du bug).
Je t’ai MP…
@TempsNyx, merci.
-
Je t’ai MP…
Merci, on a échangé en MP.
Ton monitoring détecte les 3-4 mêmes K-Box, alors qu'il y en a certainement beaucoup plus sur ta boucle WAN.
Est-ce qu'elles pourraient être d'une autre génération que la majorité ? vulnérables à "l'événement déclencheur" ?
-
Merci, on a échangé en MP.
Ton monitoring détecte les 3-4 mêmes K-Box, alors qu'il y en a certainement beaucoup plus sur ta boucle WAN.
Est-ce qu'elles pourraient être d'une autre génération que la majorité ? vulnérables à "l'événement déclencheur" ?
C'est une histoire de sous-réseau (même broadcast), VincentO2 l'avait indiqué ici : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg944984/#msg944984
-
Bon, c'est toujours là…
J'ai vu de l'activité dans les access log, donc c'est bien consulté. Alors que s'est-il passé hier pour que les fuites cessent pour quelques heures ?
(https://i.ibb.co/84ymJMh/Capture-d-cran-2022-04-29-13-43-44.png)
-
Bon, c'est toujours là…
J'ai vu de l'activité dans les access log, donc c'est bien consulté. Alors que s'est-il passé hier pour que les fuites cessent pour quelques heures ?
IP SFR c'est moi. 77.196.X.X
-
IP SFR c'est moi. 77.196.X.X
Je n'ai regardé qu'une fois ce matin depuis une adresse de : 185.251.160.0/22
-
Je vois bien aujourd’hui thedark (Chrome sur Windows 10), ainsi qu’un 77.67…, un 165.225… (Edge sur Windows 10) mais je ne vois pas pju91 :o
Mais hier j’ai eu un Chrome sur Fedora, je suppose pju91 ;)
Je vais faire un reset des sessions, car au début j’avais oublié de rediriger les IP dans mon reverse proxy et les IP étaient toutes celles du reverse proxy.
-
Je vois bien aujourd’hui thedark (Chrome sur Windows 10), ainsi qu’un 77.67…, un 165.225… (Edge sur Windows 10) mais je ne vois pas pju91 :o
Mais hier j’ai eu un Chrome sur Fedora, je suppose pju91 ;)
C'était sans doute moi - et je viens de refaire un petit tour pour que tu me reconnaisses. (185.251.160.0/22)
-
C'était sans doute moi - et je viens de refaire un petit tour pour que tu me reconnaisses. (185.251.160.0/22)
Oui, je te vois :P
-
Bon, j'ai remarqué que les fuites mDNS provenant de K-Box ne sont pas les mêmes que celles qui fuient en APIPA :o
Du coup, j'ai amélioré mon monitoring pour inclure la mesure des fuites mDNS aussi (K-Box et autres…), ai j'ai aussi optimisé les commandes tcpdump pour utiliser un minimum de ressources…
(https://i.ibb.co/GT82CWP/Capture-d-cran-2022-04-30-15-49-31.png)
Et pour les curieux, le code du script qui fait les mesures, qui se trouve sur le routeur et est appelé par un crontab :
#!/bin/sh
TMP='/tmp/knet-covage-monitor'
mkdir $TMP
TO=1
TO2=30
TH=50
DATE="$(/bin/date +%s)000000000"
echo "knetmon,mac=Moniteur pb=0i $DATE">"$TMP/moniteur"
{
/opt/bin/timeout --foreground $TO /usr/sbin/tcpdump -i ethwan -Q in -s 62 -qKnte 'udp port 547 and multicast' | \
/usr/bin/awk "length(\$1)==17{a[\$1]++} END { for (i in a) { if (a[i]<$TH) continue; print \"knetmon,mac=\"i\" pb=2i $DATE\" } }"
} >>$TMP/spam 2>/dev/null &
{
/opt/bin/timeout --foreground $TO2 /usr/sbin/tcpdump -i ethwan -Q in -s 60 -qKnte net 169.254.0.0/16 | \
/usr/bin/awk "length(\$1)==17{a[\$1]=1} END { r=\"\"; for (i in a) print \"knetmon,mac=\"i\" pb=1i $DATE\" }"
} >>$TMP/apipa 2>/dev/null &
{
/opt/bin/timeout --foreground $TO2 /usr/sbin/tcpdump -i ethwan -Q in -s 60 -qKnte net 224.0.0.0/16 | \
/usr/bin/awk "length(\$1)==17{a[\$1]=1} END { r=\"\"; for (i in a) print \"knetmon,mac=\"i\" pb=3i $DATE\" }"
} >>$TMP/mdns 2>/dev/null
wait
cat $TMP/* | /usr/bin/curl -i -XPOST 'URL DE MON INFLUXDB/write?db=MA DB' --data-binary @-
rm -rf $TMP
-
Il y a un centre de supervision h24/7/365 chez K-net ?
-
Super, petite question quand même :
tu lances 2 tcpdump (avec filtres différents) en parallèle pendant T02 secondes (je ne compte pas le 1er qui dure 1 seconde ? tu penses que ça tient la route ?
-
Il y a un centre de supervision h24/7/365 chez K-net ?
Oui, chez moi :P et chez thedark, chez Steph...
Super, petite question quand même :
tu lances 2 tcpdump (avec filtres différents) en parallèle pendant T02 secondes (je ne compte pas le 1er qui dure 1 seconde ? tu penses que ça tient la route ?
Oui, aucun souci :)
-
Mais plus sérieusement, je crois que K-Net et Covage sont fermés le week-end, avec probablement une astreinte pour les très grosses pannes.