Auteur Sujet: [Demi-Résolu] Icotera - Déconnexion / Micro-coupures - Problème LAN/WAN (Lu 33046 fois)

phenomens · « **Réponse #144 le:** 14 avril 2022 à 21:53:37 »

Manifestement pas tout à fait résolu, cela fait 30 minutes que j’ai une coupure toutes les 5 minutes.

bolemo · « **Réponse #145 le:** 14 avril 2022 à 21:57:48 »

Citation de: phenomens le 14 avril 2022 à 21:53:37

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…

bolemo · « **Réponse #146 le:** 15 avril 2022 à 00:18:07 »

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…

pju91 · « **Réponse #147 le:** 15 avril 2022 à 08:58:54 »

Citation de: bolemo le 15 avril 2022 à 00:18:07

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 (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 ?

Superpicsou · « **Réponse #148 le:** 15 avril 2022 à 11:51:50 »

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

Code: [Sélectionner]

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.

Code: [Sélectionner]

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

Code: [Sélectionner]

tcpdump -ne ether broadcast or ether multicast ça donne quoi ?

bolemo · « **Réponse #149 le:** 15 avril 2022 à 12:04:39 »

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…

pju91 · « **Réponse #150 le:** 15 avril 2022 à 12:05:49 »

Citation de: Superpicsou le 15 avril 2022 à 11:51:50

De mon côté toujours aucune coupure depuis mon changement d'ip local mercredi soir.

Content pour toi

Citation de: Superpicsou le 15 avril 2022 à 11:51:50

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.

Citation de: Superpicsou le 15 avril 2022 à 11:51:50

Donc pour ceux qui ont les mêmes symptômes foncez !

Penomens, j'ai essayé la commande de pju91
Code: [Sélectionner]
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 ...

Citation de: Superpicsou le 15 avril 2022 à 11:51:50

et juste
Code: [Sélectionner]
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

bolemo · « **Réponse #151 le:** 15 avril 2022 à 12:17:03 »

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

Superpicsou · « **Réponse #152 le:** 15 avril 2022 à 12:28:11 »

Citation de: bolemo le 15 avril 2022 à 12:17:03

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

bolemo · « **Réponse #153 le:** 15 avril 2022 à 12:30:37 »

Citation de: Superpicsou le 15 avril 2022 à 12:28:11

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.

bolemo · « **Réponse #154 le:** 15 avril 2022 à 12:31:50 »

Citation de: Superpicsou le 15 avril 2022 à 12:28:11

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

Fibre78 · « **Réponse #155 le:** 15 avril 2022 à 12:32:11 »

Citation de: bolemo le 15 avril 2022 à 12:30:37

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