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

pju91 · « **Réponse #132 le:** 14 avril 2022 à 16:41:38 »

Citation de: bolemo le 14 avril 2022 à 16:20:53

Quelqu'un veut gagner des millions ici ?

Un certain Franck ?

Citation de: bolemo le 14 avril 2022 à 16:20:53

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

Citation de: bolemo le 14 avril 2022 à 16:20:53

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.

Citation de: bolemo le 14 avril 2022 à 16:20:53

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.

bolemo · « **Réponse #133 le:** 14 avril 2022 à 16:57:39 »

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/

Steph · « **Réponse #134 le:** 14 avril 2022 à 17:08:51 »

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.

pju91 · « **Réponse #135 le:** 14 avril 2022 à 17:10:54 »

Citation de: bolemo le 14 avril 2022 à 16:57:39

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.

bolemo · « **Réponse #136 le:** 14 avril 2022 à 17:12:53 »

Citation de: pju91 le 14 avril 2022 à 17:10:54

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

phenomens · « **Réponse #137 le:** 14 avril 2022 à 17:34:42 »

Citation de: pju91 le 14 avril 2022 à 15:16:22

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 :

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

Citer

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.

Citer

L'interface k-box est revenue.

Et dans mon cas, toujours la même erreur

phenomens · « **Réponse #138 le:** 14 avril 2022 à 17:37:35 »

Je viens d'essayer l'autre commande :

Code: [Sélectionner]

sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
Et voici le résultat :

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

bolemo · « **Réponse #139 le:** 14 avril 2022 à 17:43:15 »

Citation de: phenomens le 14 avril 2022 à 17:37:35

Je viens d'essayer l'autre commande :

Code: [Sélectionner]
sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
Et voici le résultat :

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

pju91 · « **Réponse #140 le:** 14 avril 2022 à 17:55:39 »

Citation de: bolemo le 14 avril 2022 à 17:43:15

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

phenomens · « **Réponse #141 le:** 14 avril 2022 à 18:03:47 »

Ok je vais continuer de checker de temps en temps. En effet c'est l'ip de mon macMini.

bolemo · « **Réponse #142 le:** 14 avril 2022 à 18:08:00 »

Citation de: pju91 le 14 avril 2022 à 17:55:39

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

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.

pju91 · « **Réponse #143 le:** 14 avril 2022 à 19:57:38 »

Citation de: bolemo le 14 avril 2022 à 18:08:00

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.

Citation de: bolemo le 14 avril 2022 à 18:08:00

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.