K-Net => Opérateurs grand public alternatifs => Incidents collectifs => Discussion démarrée par: bolemo le 08 avril 2022 à 13:40:19 K-Net => Opérateurs grand public alternatifs => Incidents collectifs => Discussion démarrée par: bolemo le 08 avril 2022 à 13:40:1913:17:45.960458 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)))Alors depuis ce matin 6h, plus de coupures.
J'ai tout de même contacté KNET à 9h pétantes (2ème sur la file d'attente ! Un record, j'ai attendu 5 minutes) qui, ayant placé une sonde ma connexion depuis un moment, ont effectivement constaté les X coupures Samedi et Dimanche.
Ils ont informé COVAGE de cela (ticket quoi) et m'ont annoncé un délai de 72h pour que ce soit mis en œuvre mais m'ont dit que ça semblait d'ores et déjà corrigé car la connexion était stable depuis 6h du matin.
Apparemment, je n'étais pas le seul dans cette situation sur l'Essonne mais les cas semblent aléatoires.
Le moins qu'on puisse dire, c'est qu'il faut avoir le cuir solide avec ce FAI...
Posté hier soir sur Twitter le lien vers le post de Vincent02... et merci à toi bolemo, pour ton analyse factuelle, ton support aux "victimes" et ta mise en relation des différentes parties prenantes.
Ce matin 8h, le problème a été résolu !
Merci VincentO2 pour avoir posté l'information qui a débloquée la situation, merci FB et K-Net d'avoir lu et appliqué la solution, et merci à Covage/Altitude d'avoir suivi tout cela et participé.
... et merci à toi bolemo, pour ton analyse factuelle, ton support aux "victimes" et ta mise en relation des différentes parties prenantes.
Celà dit, on n'est évidemment pas du tout dans un processus de traitement d'incident "normal", ça aussi ça reste inquiétant. Sans même revenir sur la communication inexistante de K-Net.
Je rêve de les voir acquérir une transparence totale (on a assez d'opacité avec les OI et les gros FAI), admettre leurs faiblesses, leurs erreurs (ils sont humains). Cela aiderait énormément les clients à rester fidèles, car beaucoup se sentent délaissés, ignorés, voire snobés, sans importance, résultat malheureux des maladresses de communication quand il y en a.Complètement d'accord avec toi. C'était un des points de mon post ici (https://lafibre.info/k-net-incident/recapitulatif-des-problemes-en-cours-et-non-resolus/msg938221/#msg938221)
En tous cas, pas de spam DHCPv6 en cours, ni plus tôt aujourd'hui. C'est peut-être lié à l'autre problème Icotera, les fuites gpon/lan…Pour coucouyou et les autres concernés, voir ce fil si vous ne l'avez pas encore suivi : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg941688/#msg941688
Merci bolemo pour l'information. C'est en effet revenu vers midi. Bon ca n'était pas un problème de stabilité, il n'y avait plus internet du tout, mais au moins ca n'a duré que la matinée (comme il y a une semaine). Cependant les coupures intempestives sont toujours présentes.
De rien !Est-ce que ton monitoring te permet d'identifier l'adresse MAC de l'équipement qui inonde le GPON?
J'ai installé une alarme qui m'informe quand ça arrive… Et de toute façon j'ai un historique des stats broadcast/multicast de notre GPON ;)
Pour les coupures, c'est une conséquence de l'autre bogue Icotera (duquel Coucouyou est maintenant libéré avec son routeur perso) dont VincentO (ancien employé K-Net) parle ici : https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg944984/#msg944984On a vu que plutôt que de coupure, il faudrait parler de "pollution du LAN" qui provoque des effets de bord, tels que duplication d'adresse IP.
La bonne nouvelle est que sur un très bonne initiative de pju91, lui et moi avons pris contact avec Icotera qui est maintenant en relation avec K-Net sur ces points et ces derniers semblent chercher à résoudre cela…A ce sujet, sais-tu si le firmware des K-Box v2 est le même pour tout le monde ?
$ snmpwalk -Os -c $community -v 2c $ip system|grep Descr
sysDescr.0 = STRING: ICOTERA i4850 4850-1.16.3
... en imaginant que 1.16.3 est une version de firmware, mais je n'en sais rien.1. en prérequis, activer SNMP sur la box (onglet avancé)L'Icotera a son SNMP qui la fait assez régulièrement planter pour cause d'attaque extérieure.
2. récupérer la chaîne "communauté publique" (variable community ci-après)
3. connaître son adresse IP publique (variable ip ci-après)
L'Icotera a son SNMP qui la fait assez régulièrement planter pour cause d'attaque extérieure.De mon côté, je n'ai jamais eu ce souci. J'ai un "polling SNMP" avec Cacti (https://www.cacti.net/) en place pour évaluer le trafic WAN depuis longtemps.
VincentO2 avait mis une ACL sur la mienne et plus de plantage le temps que cela durait.
Est-ce que ton monitoring te permet d'identifier l'adresse MAC de l'équipement qui inonde le GPON?Le monitoring passif non, mais quand un incident est en cours, je peux trouver la MAC en très peu de temps.
Est-ce toujours la même K-Box ?
On a vu que plutôt que de coupure, il faudrait parler de "pollution du LAN" qui provoque des effets de bord, tels que duplication d'adresse IP.
A ce sujet, sais-tu si le firmware des K-Box v2 est le même pour tout le monde ?
De mon côté, je parviens à interroger ma box en SNMP, ça m'interesserait de savoir ce que ça donne ailleurs.
commande ci-dessous avec :
1. en prérequis, activer SNMP sur la box (onglet avancé)
2. récupérer la chaîne "communauté publique" (variable community ci-après)
3. connaître son adresse IP publique (variable ip ci-après)Code: [Sélectionner]$ snmpwalk -Os -c $community -v 2c $ip system|grep Descr... en imaginant que 1.16.3 est une version de firmware, mais je n'en sais rien.
sysDescr.0 = STRING: ICOTERA i4850 4850-1.16.3
Le monitoring passif non, mais quand un incident est en cours, je peux trouver la MAC en très peu de temps.Donc plus d'un client affecté sur la boucle à laquelle tu es connecté :(
Les deux fois où j'ai regardé les paquets (deux incidents différents), la MAC de la K-Box était différente.
Je pourrais faire un script qui fait automatiquement un dump quand il y a une alarme… Et avoir une solution 100% passive de monitoring des incidents DHCPv6.Puisque les incidents de ces derniers jours ont duré peu de temps, est-ce qu'une solution de détection et de correction est maintenant en place côté K-Net ?
Pour la fuite GPON/LAN, ce qu'explique VincentO a beaucoup de sens, car les règles ebtables peuvent filtrer ou laisser passer du traffic entre WAN et LAN. Du coup, cela n'est pas forcément un problème de firmware si ce sont des règles appliquées ou modifiées par les solutions maison K-Net (ce n'est à priori pas un problème low-level).Je n'ai toujours pas compris pourquoi des règles ebtables doivent être installées sur un routeur (à part peut-être pour le port mirroring). Quelle est la raison ?
Pour la boucle DHCPv6 SOLLICIT, c'est bien plus curieux… puisqu'à priori un client DHCPv6 même mal configuré, ne va pas envoyer 4 000 requêtes par secondes…Oui, ça me rappelle l'époque ancienne où je montrais (avec un peu de connaissance sur l'architecture de la machine) comment faire un programme en C qui bouclait de manière infinie, sans boucle explicite dans le programme, mais simplement en écrasant la pile avec la bonne valeur ...
C'est soit une mauvaise conception dans le code du client qui dans certaines conditions revient à une boucle sans fin qui s'est emballée (corruption dans la gestion de la mémoire du processus…). Donc possiblement un problème de firmware, sauf si K-Net a altéré le client ou développé son propre client ou encore modifie un fichier dont dépend le processus (dans /var ou /tmp par exemple)…
On ne peut que spéculer de toute façon, sans avoir le code source, ou un accès root à une K-Box.
On a vu que d'autres opérateurs BYTEL (comme tu l'avais mentionné) on apparemment rencontré des situations similaires, probablement dans des circonstances totalement différentes (les box sont-elles des Icotera ou totalement différentes…), mais qui sait ?J'ai retiré ce message, le diagnostic de l'utilisateur semblait erroné.
Donc plus d'un client affecté sur la boucle à laquelle tu es connecté :(Ma boucle est assez large… C'est tout le 14 + une partie (ou la totalité) du 91 sur l'infra Covage/Altitude.
Puisque les incidents de ces derniers jours ont duré peu de temps, est-ce qu'une solution de détection et de correction est maintenant en place côté K-Net ?Je suppose que oui… La premier incident que j'ai détecté à duré 15 jours malgré le Tweet à Covage, K-Net puis Département…
Si ce n'est pas le cas, conserver les adresses MAC des box concernées peut être utile effectivement.Je verrai à l'occasion. Ce n'est pas très compliqué, mais il me faut un peu de temps… Mon alarme Grafana doit déclencher le script sur mon routeur (qui est le seul à pouvoir écouter le GPON) qui enregistrera un échantillon de tcpdump. J'imagine par un appel à une page HTTP sur le serveur natif du routeur (je le fais déjà pour mon script Aegis).
Je n'ai toujours pas compris pourquoi des règles ebtables doivent être installées sur un routeur (à part peut-être pour le port mirroring). Quelle est la raison ?Elle sont utiles en mode bridge. Probablement pour le mort mirroring aussi.
Oui, ça me rappelle l'époque ancienne où je montrais (avec un peu de connaissance sur l'architecture de la machine) comment faire un programme en C qui bouclait de manière infinie, sans boucle explicite dans le programme, mais simplement en écrasant la pile avec la bonne valeur ...Ça peut être un problème de ce genre… Ou un mauvais design (une boucle explicite qui attend la réponse DHCPv6 du serveur avec le contrôle d'une variable de pause qui foire, ou un timer corrompu…) ; sans accès à la machine défaillante et/ou son code, on restera dans le noir. Ce qui compte, c'est que K-Net semble bien y travailler.
Elle sont utiles en mode bridge. Probablement pour le mort mirroring aussi.La K-Box étant basée apparemment sur un Icotera 4850, les fonctionnalités "bridge" existent dans le produit "usine" mais les clients K-Net peuvent configurer assez peu de choses par le panel, comme le port mirroring, ou le filtrage MAC sur WiFi.
En mode routeur, des règles ebtables permettent d'isoler un réseau wifi guest du LAN par exemple.
Concernant ebtables:La K-Box étant basée apparemment sur un Icotera 4850, les fonctionnalités "bridge" existent dans le produit "usine" mais les clients K-Net peuvent configurer assez peu de choses par le panel, comme le port mirroring, ou le filtrage MAC sur WiFi.
La fonctionnalité "WIFI guest" n'est pas proposée dans l'interface, et on ne peut évidemment pas saisir de règles ebtables.
Maintenant, ce qui est inquiétant, c’est que VincentO2 mentionne un passage physique des K-Box au centre de maintenance pour cela et d’autres procédures qu’il ne précise pas. Ça laisse penser qu’il existe d’autres soucis avec les Icotera, ou que l’origine est peut-être matérielle après tout… Peut-être des problèmes de nvram avec des secteurs défectueux qui apparaissent avec le temps…En regardant dans l'interface de la K-Box, il y a une notion de version. Voir par exemple le screenshot correspondant à l'affichage des modifications de la version 5.5.
probablement la partie or (ether[6:2] == 0x000f and ether[8:1] == 0x15) n'est pas nécessaire (je ne sais pas s'il existe des K-Box avec des MAC en 00:0F:15…)Je pense que tu as raison.
Je pense que tu as raison.
Mais si tu veux être perfectionniste, https://hwaddress.com/company/icotera-as/ liste un 3e OUI pour ICOTERA: 4C-C4-49 (voir aussi dans https://standards-oui.ieee.org/oui/oui.txt).
{ timeout 1 tcpdump -i interface WAN -te "ether[6:2] == 0x001e and ether[8:1] == 0x80 and udp port 547 and multicast"; } | awk 'length($1)==17{a[$1]++} END { for (i in a) { if (a[i]<50) continue; print i } }'Dans un crontab qui vérifiera toutes les minutes par exemple, et fera un log.if (a<50) au lieu de if (a[i]<50) dans ta règle END et ça passe en italiquea[i]Il faut donc vraiment utiliser "code" plutôt que forcer la police en courrier.Chez moi, ta commande s'affichait avecCode: [Sélectionner]if (a<50)au lieu deCode: [Sélectionner]if (a[i]<50)dans ta règle END et ça passe en italique
Du coup, le script me paraissait faux.
En tentant de te répondre en te "citant", ça fait bien apparaître leCode: [Sélectionner]a[i]Il faut donc vraiment utiliser "code" plutôt que forcer la police en courrier.
Dire que je pensais être le dernier à utiliser awk ...
Bon, je pense qu'effectivement ce script peut être utile ... s'il ne charge pas trop ton matériel.
Oui, le i entre crochets a été interprété comme BB Code. C’est corrigé.Merci.
awk… extrêmement utile et puissant, il me sert beaucoup.
Merci.
Je pensais que tout le monde s'était mis à python ou autre, et qu'il ne restait que les vétérans comme moi pour apprécier awk 8)
Du coup, comme tu "pipes" dans awk, tu aurais pu mettre un filtre plus simple sur tcpdump (en ne gardant que udp port 547 and multicast et en filtrant directement dans awk sur l'OUI d'Icotera par /^00:1e:80/, à la place du length. Surtout que la syntaxe pour filtrer les adresses MAC dans tcpdump est un peu laborieuse.
Normalement, tu ne dois pas voir beaucoup d'autres datagrammes DHCP multicast, tant pis s'ils ne sont pas filtrés dès le tcpdump.
Je ne sais pas si ça changerait quelque chose sur les cycles "system" versus "user" de ton système, dont je ne connais pas la puissance.
Spam DHCPv6 en cours !La bonne nouvelle, c'est que tu viens de finir le test de ton script.
La bonne nouvelle, c'est que tu viens de finir le test de ton script.
Moi qui trouvais à la lecture de ton script que ton seuil d'alerte à TH=50 était élevé (j'avais tort).
La mauvaise nouvelle, c'est l'impact sur les performances pour un certain nombre de clients, dont toi.
#!/bin/sh
RS=60
NM='knet-covage-mon'
PID=/var/run/$NM.pid
PP=/opt/bolemo/scripts/$NM-pp.sh
PCAP=/tmp/$NM%H%M%S.pcap
start() {
if [ -e $PID ] && kill -0 "$(cat $PID)" 2>/dev/null; then
echo 'Already started';
exit
else echo 'Starting'
fi
}
stop() {
if [ -e $PID ] && kill -0 "$(cat $PID)" 2>/dev/null; then
kill -15 "$(cat $PID)"
rm /tmp/$NM*.pcap
rm $PID
echo 'Stopped'
else echo 'Already stopped'
fi
}
case "$1" in
start) start;;
stop) stop; exit;;
restart) stop; start;;
*) echo 'Use start|stop|restart'; exit;;
esac
exec >/dev/null 2>&1
/usr/sbin/tcpdump -i ethwan -Q in -s 46 -K -G $RS -w $PCAP -z $PP 'not (ether src MAC DE LA PASSERELLE COVAGE) and (ether dst 01:00:5e:00:00:fb or net 169.254.0.0/16)' &
echo $! >$PID
#!/bin/sh
TMP=/tmp/knet-covage-mon.tmp
LBL='knetmon'
DATE="$(/bin/date +%s)"
{
/usr/sbin/tcpdump -r $1 -s 46 -qKNtnne | \
/usr/bin/awk '$3=="01:00:5e:00:00:fb,"{ a["mac="$1" pb=3i"]++; next } index($0," 169.254."){ a["mac="$1" pb=1i"]++ } END { for (i in a) print "'$LBL',"i",ct="a[i]"i '$DATE'" }'
} >$TMP
# spam DHCPv6
TO=1
TH=50
{
/opt/bin/timeout --foreground $TO /usr/sbin/tcpdump -i ethwan -Q in -s 62 -qKNtnne 'udp port 547 and multicast' | \
/usr/bin/awk "\$1{a[\$1]++} END { for (i in a) { if (a[i]<$TH) continue; print \"$LBL,mac=\"i\" pb=2i $DATE\" } }"
} >> $TMP
echo "$LBL,mac=Moniteur pb=0i $DATE" >>$TMP
cat $TMP | /usr/bin/curl -i -XPOST 'http://MON INFLUXDB/write?db=MA BDD&precision=s' --data-binary @-
rm $TMP
rm $1
Le TH à 50 paquets par secondes, aucun problème quand on sait que le spam est de plus de 3 000 paquets par seconde…oui - effectivement !
J'en ai profité pour améliorer mon script en daemon, qui mesure en continu (sauf le spam DHCPv6) et qui est maintenant en deux parties, et le résultat est impec (la première version n'était pas propre lors d'un spam DHCPv6 avec des pertes sur les autres mesures) :C'est un peu pour ça que je m'étonnais que tu lances les tcpdump en parallèle, sans avoir encore vu la conséquence éventuelle en situation de "spam". Mais j'avais quand même tort dans ce que j'ai écrit là (https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg947239/#msg947239)
J'attends une mise à jour sur le référencement Arcep de mon adresse, et ciao K-Net, pour sûr !C'est quoi le rapport avec la mise à jour sur le référencement Arcep ? Les bases FAI sont mises à jour toutes les semaines.
C'est quoi le rapport avec la mise à jour sur le référencement Arcep ? Les bases FAI sont mises à jour toutes les semaines.
Ras le bol de cet opérateur...
Je suis sur une K-Box et je subi donc complètement le problème actuel des spams, connexion totalement instable, quasiment inaccessible aujourd'hui.
C'est incroyable a quel point K-Net est devenu mauvais ces derniers temps, c'est une honte. Des soucis presque toutes les semaines !
J'attends une mise à jour sur le référencement Arcep de mon adresse, et ciao K-Net, pour sûr !
Concernant le point (1'), j'ai établi un outil de supervision qui est en service, et dont j'ai donné l'accès à Altitude/Covage et au NOC K-Net.
L'outil n'a pas été consulté par eux depuis 4 jours… J'ai tweeté FB et Altitude aujourd'hui, quelques minutes après que ma supervision m'a envoyé une alarme du spam.
Quand j'ai contacter d'autres opérateurs, ils n'ont pas trouver mon adresse sur l'Arcep, le point n'apparaît pas. Ils ne veulent rien savoir et refusent d'ouvrir un dossier tant que le point n'est pas référencé. J'ignore comment ils ont procéder la première fois (Covage/K-Net).La mise a jour ARCEP vient de Covage. Donc si le point n'est pas sur la carte Covage. Tu n'auras pas de point sur ARCEP.
Et quand je vais sur l'Arcep, il est indiqué que les données ne sont mises à jour que tous les 3 mois (la dernière ayant eu lieu le 10 Mars, j'ai le temps d'attendre).
Je me trompe peut-être, je ne m'y connais pas beaucoup. Si jamais je me trompe, je suis preneur de toutes informations (par message privé car il ne faut peut-être pas spammer ce topic destiné à un autre sujet)
C'est quand même incroyable que tu trouves le soucis, que tu leurs donne les outils pour détecter rapidement le problème, et qu'ils mettent autant de temps à agir.
Je suis novice en réseau, mais quand ils savent d'où le problème vient, et que ce dernier est aussi récurrent, tu te demandes où est le service "professionnel" que l'on paye...
C'est incroyable a quel point K-Net est devenu mauvais ces derniers temps, c'est une honte. Des soucis presque toutes les semaines !Tout est une question de point de vue je pense. Moi à part la coupure de quelques heures en janvier et la téléphonie en rade jusqu'au mois dernier, ça tourne comme une horloge et je suis très content. Aucun problème pour joindre le service client, débit impeccable, pas de déco. À tel point que je viens de souscrire sur une adresse supplémentaire. Pour moi la possibilité d'utiliser ce que je veux pour me connecter à l'ONT (et la téléphonie accessible en SIP natif) est un énorme plus, pour lequel je suis prêt à faire des compromis. Comme quoi, on voit midi à sa porte. 😅
Tout est une question de point de vue je pense. Moi à part la coupure de quelques heures en janvier et la téléphonie en rade jusqu'au mois dernier, ça tourne comme une horloge et je suis très content. Aucun problème pour joindre le service client, débit impeccable, pas de déco. À tel point que je viens de souscrire sur une adresse supplémentaire. Pour moi la possibilité d'utiliser ce que je veux pour me connecter à l'ONT (et la téléphonie accessible en SIP natif) est un énorme plus, pour lequel je suis prêt à faire des compromis. Comme quoi, on voit midi à sa porte. 😅
(si j'en crois ce que je vois sur ce forum, j'ai l'impression que l'essentiel des problèmes est plus ou moins directement lié à Covage, et je me demande si on ne se trompe pas de cible en tapant sur K-net, mais bon, je n'ai pas le plaisir d'être raccordé sur cet OI et je ne m'en plains pas :) )
Ceci est sans aucun effet dans les collectes OI qui isolent les clients (la plupart des collectes en fait, y compris Covage), mais la collecte Covage ex-Tutor 14 & 91 n'isole pas les clients des paquets broadcast et multicast,
J'ai envie de dire que là est le problème. Un OI qui n'isole pas les clients, ne serait-ce que d'un point de vue privacy, c'est franchement pas un modèle à suivre. Je me demande même d'ailleurs si l'ARCEP n'y trouverait pas à redire :PA ce propos @bolemo, ton tracert de passerelle 10.2.0.211 passe par K-net 10.2.0.5 ou pas?
traceroute to 10.2.0.178 (10.2.0.178) from 185.x.x.x hops max, 38 byte packets
1 10.2.0.178 (10.2.0.178) 2.000 ms 1.000 ms 1.000 ms
2 * * *
3 10.2.0.5 (10.2.0.5) 11.000 ms 11.000 ms 11.000 ms
4 10.2.0.4 (10.2.0.4) 11.000 ms 11.000 ms 11.000 ms
5 10.2.0.178 (10.2.0.178) 11.000 ms 11.000 ms 11.000 ms
J'ai envie de dire que là est le problème. Un OI qui n'isole pas les clients, ne serait-ce que d'un point de vue privacy, c'est franchement pas un modèle à suivre. Je me demande même d'ailleurs si l'ARCEP n'y trouverait pas à redire :P
Mes 2 sioux.
A ce propos @bolemo, ton tracert de passerelle 10.2.0.211 passe par K-net 10.2.0.5 ou pas?
Tracert sur ma passerelle :Code: [Sélectionner]traceroute to 10.2.0.178 (10.2.0.178) from 185.x.x.x hops max, 38 byte packets
1 10.2.0.178 (10.2.0.178) 2.000 ms 1.000 ms 1.000 ms
2 * * *
3 10.2.0.5 (10.2.0.5) 11.000 ms 11.000 ms 11.000 ms
4 10.2.0.4 (10.2.0.4) 11.000 ms 11.000 ms 11.000 ms
5 10.2.0.178 (10.2.0.178) 11.000 ms 11.000 ms 11.000 ms
Dans l'ordre :Et tu as le même ping pong que sur Covage74 ou pas, quand tu tracert 211 depuis ta connexion K-net?
Chez moi -> 10.2.0.211 (collecte 14 - chez Covage) -> 10.2.0.4 (collecte globale - chez Covage) -> 10.2.0.5 (collecte chez K-Net)
Et tu as le même ping pong que sur Covage74 ou pas, quand tu tracert 211 depuis ta connexion K-net?
root@HERMES:~$ traceroute 10.2.0.211
traceroute to 10.2.0.211 (10.2.0.211), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.531 ms 2.468 ms 2.406 ms
2 * * *
3 10.2.0.5 (10.2.0.5) 6.935 ms 6.748 ms 6.810 ms
4 10.2.0.4 (10.2.0.4) 6.967 ms 6.967 ms 6.935 ms
5 10.2.0.211 (10.2.0.211) 6.935 ms 7.123 ms 6.966 ms$ mtr -n -c 1 -r 10.2.0.143
Start: 2022-05-04T14:33:47+0200
HOST: fedora Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 1 3.5 3.5 3.5 3.5 0.0
2.|-- 10.2.0.143 0.0% 1 5.3 5.3 5.3 5.3 0.0
$ sudo tcpdump -nvvv icmp or host 10.2.0.143
dropped privs to tcpdump
tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:33:47.652580 IP (tos 0x0, ttl 1, id 30834, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33000, length 44
14:33:47.655963 IP (tos 0xc0, ttl 64, id 2865, offset 0, flags [none], proto ICMP (1), length 92)
192.168.1.1 > 192.168.1.50: ICMP time exceeded in-transit, length 72
IP (tos 0x0, ttl 1, id 30834, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33000, length 44
14:33:47.752624 IP (tos 0x0, ttl 2, id 30845, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33001, length 44
14:33:47.757803 IP (tos 0x0, ttl 63, id 39970, offset 0, flags [none], proto ICMP (1), length 92)
10.2.0.143 > 192.168.1.50: ICMP time exceeded in-transit, length 72
IP (tos 0x0, ttl 1, id 30845, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33001, length 44
14:33:47.852736 IP (tos 0x0, ttl 3, id 30873, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33002, length 44
$ sudo traceroute -I -q1 -n 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 60 byte packets
1 192.168.1.1 5.307 ms
2 10.2.0.143 7.865 ms
3 *
4 10.2.0.5 7.849 ms
5 10.2.0.4 7.842 ms
6 10.2.0.143 7.834 ms
14:35:38.706967 IP (tos 0x0, ttl 1, id 13905, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 1, length 40
14:35:38.707001 IP (tos 0x0, ttl 2, id 13906, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 2, length 40
14:35:38.707008 IP (tos 0x0, ttl 3, id 13907, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 3, length 40
14:35:38.707016 IP (tos 0x0, ttl 4, id 13908, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 4, length 40
14:35:38.707024 IP (tos 0x0, ttl 5, id 13909, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 5, length 40
14:35:38.707033 IP (tos 0x0, ttl 6, id 13910, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 6, length 40
14:35:38.707042 IP (tos 0x0, ttl 7, id 13911, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 7, length 40
14:35:38.707050 IP (tos 0x0, ttl 8, id 13912, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 8, length 40
14:35:38.707058 IP (tos 0x0, ttl 9, id 13913, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 9, length 40
14:35:38.707066 IP (tos 0x0, ttl 10, id 13914, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 10, length 40
14:35:38.707073 IP (tos 0x0, ttl 11, id 13915, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 11, length 40
14:35:38.707082 IP (tos 0x0, ttl 12, id 13916, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 12, length 40
14:35:38.707090 IP (tos 0x0, ttl 13, id 13917, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 13, length 40
14:35:38.707099 IP (tos 0x0, ttl 14, id 13918, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 14, length 40
14:35:38.707107 IP (tos 0x0, ttl 15, id 13919, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 15, length 40
14:35:38.707115 IP (tos 0x0, ttl 16, id 13920, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 16, length 40
14:35:38.712237 IP (tos 0xc0, ttl 64, id 2866, offset 0, flags [none], proto ICMP (1), length 88)
192.168.1.1 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13905, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 1, length 40
14:35:38.712328 IP (tos 0x0, ttl 17, id 13921, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 17, length 40
14:35:38.714863 IP (tos 0x0, ttl 62, id 660, offset 0, flags [none], proto ICMP (1), length 88)
10.2.0.4 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13909, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 5, length 40
14:35:38.714863 IP (tos 0xc0, ttl 61, id 42690, offset 0, flags [none], proto ICMP (1), length 88)
10.2.0.5 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13908, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 4, length 40
14:35:38.714863 IP (tos 0x0, ttl 63, id 41579, offset 0, flags [none], proto ICMP (1), length 88)
10.2.0.143 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13906, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 2, length 40
14:35:38.714864 IP (tos 0x0, ttl 63, id 13910, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 6, length 40
14:35:38.714865 IP (tos 0x0, ttl 63, id 13911, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 7, length 40
14:35:38.714866 IP (tos 0x0, ttl 63, id 13912, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 8, length 40
14:35:38.714867 IP (tos 0x0, ttl 63, id 13913, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 9, length 40
14:35:38.716644 IP (tos 0x0, ttl 63, id 13914, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 10, length 40
14:35:38.716646 IP (tos 0x0, ttl 63, id 13915, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 11, length 40
14:35:38.716647 IP (tos 0x0, ttl 63, id 13916, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 12, length 40
14:35:38.716648 IP (tos 0x0, ttl 63, id 13917, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 13, length 40
14:35:38.716648 IP (tos 0x0, ttl 63, id 13918, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 14, length 40
14:35:38.716649 IP (tos 0x0, ttl 63, id 13919, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 15, length 40
14:35:38.716650 IP (tos 0x0, ttl 63, id 13920, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 16, length 40
14:35:38.716651 IP (tos 0x0, ttl 63, id 13921, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 17, length 40
Pour une fois, je crois que je ne vais pas être d'accord avec vous :P
Steph m'avait suggéré il y a quelques jours de faire le même test avec la 1e passerelle derrière ma box, en l'occurence 10.2.0.143.
J'ai sorti l'analyseur de réseau, et voici ce que j'observe :
le traceroute balance des paquets ICMP avec des TTL croissants, sans attendre le 1er retour ICMP TTL Exceeded.
En revance, mtr est plus civilisé.
Si mon tcpdump ne s'emmêle pas les pinceaux dans les horodatages et l'ordre de réception des paquets, je pense donc que le "ping pong" observé est plutôt lié à un effet de bord du fonctionnement de traceroute.
J'ai concaténé les 2 fenêtres terminal pour montrer la trace correspondant à chaque commande :Code: [Sélectionner]$ mtr -n -c 1 -r 10.2.0.143
Start: 2022-05-04T14:33:47+0200
HOST: fedora Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 1 3.5 3.5 3.5 3.5 0.0
2.|-- 10.2.0.143 0.0% 1 5.3 5.3 5.3 5.3 0.0
$ sudo tcpdump -nvvv icmp or host 10.2.0.143
dropped privs to tcpdump
tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:33:47.652580 IP (tos 0x0, ttl 1, id 30834, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33000, length 44
14:33:47.655963 IP (tos 0xc0, ttl 64, id 2865, offset 0, flags [none], proto ICMP (1), length 92)
192.168.1.1 > 192.168.1.50: ICMP time exceeded in-transit, length 72
IP (tos 0x0, ttl 1, id 30834, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33000, length 44
14:33:47.752624 IP (tos 0x0, ttl 2, id 30845, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33001, length 44
14:33:47.757803 IP (tos 0x0, ttl 63, id 39970, offset 0, flags [none], proto ICMP (1), length 92)
10.2.0.143 > 192.168.1.50: ICMP time exceeded in-transit, length 72
IP (tos 0x0, ttl 1, id 30845, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33001, length 44
14:33:47.852736 IP (tos 0x0, ttl 3, id 30873, offset 0, flags [none], proto ICMP (1), length 64)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33002, length 44
$ sudo traceroute -I -q1 -n 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 60 byte packets
1 192.168.1.1 5.307 ms
2 10.2.0.143 7.865 ms
3 *
4 10.2.0.5 7.849 ms
5 10.2.0.4 7.842 ms
6 10.2.0.143 7.834 ms
14:35:38.706967 IP (tos 0x0, ttl 1, id 13905, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 1, length 40
14:35:38.707001 IP (tos 0x0, ttl 2, id 13906, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 2, length 40
14:35:38.707008 IP (tos 0x0, ttl 3, id 13907, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 3, length 40
14:35:38.707016 IP (tos 0x0, ttl 4, id 13908, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 4, length 40
14:35:38.707024 IP (tos 0x0, ttl 5, id 13909, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 5, length 40
14:35:38.707033 IP (tos 0x0, ttl 6, id 13910, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 6, length 40
14:35:38.707042 IP (tos 0x0, ttl 7, id 13911, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 7, length 40
14:35:38.707050 IP (tos 0x0, ttl 8, id 13912, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 8, length 40
14:35:38.707058 IP (tos 0x0, ttl 9, id 13913, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 9, length 40
14:35:38.707066 IP (tos 0x0, ttl 10, id 13914, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 10, length 40
14:35:38.707073 IP (tos 0x0, ttl 11, id 13915, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 11, length 40
14:35:38.707082 IP (tos 0x0, ttl 12, id 13916, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 12, length 40
14:35:38.707090 IP (tos 0x0, ttl 13, id 13917, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 13, length 40
14:35:38.707099 IP (tos 0x0, ttl 14, id 13918, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 14, length 40
14:35:38.707107 IP (tos 0x0, ttl 15, id 13919, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 15, length 40
14:35:38.707115 IP (tos 0x0, ttl 16, id 13920, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 16, length 40
14:35:38.712237 IP (tos 0xc0, ttl 64, id 2866, offset 0, flags [none], proto ICMP (1), length 88)
192.168.1.1 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13905, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 1, length 40
14:35:38.712328 IP (tos 0x0, ttl 17, id 13921, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 17, length 40
14:35:38.714863 IP (tos 0x0, ttl 62, id 660, offset 0, flags [none], proto ICMP (1), length 88)
10.2.0.4 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13909, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 5, length 40
14:35:38.714863 IP (tos 0xc0, ttl 61, id 42690, offset 0, flags [none], proto ICMP (1), length 88)
10.2.0.5 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13908, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 4, length 40
14:35:38.714863 IP (tos 0x0, ttl 63, id 41579, offset 0, flags [none], proto ICMP (1), length 88)
10.2.0.143 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13906, offset 0, flags [none], proto ICMP (1), length 60)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 2, length 40
14:35:38.714864 IP (tos 0x0, ttl 63, id 13910, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 6, length 40
14:35:38.714865 IP (tos 0x0, ttl 63, id 13911, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 7, length 40
14:35:38.714866 IP (tos 0x0, ttl 63, id 13912, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 8, length 40
14:35:38.714867 IP (tos 0x0, ttl 63, id 13913, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 9, length 40
14:35:38.716644 IP (tos 0x0, ttl 63, id 13914, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 10, length 40
14:35:38.716646 IP (tos 0x0, ttl 63, id 13915, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 11, length 40
14:35:38.716647 IP (tos 0x0, ttl 63, id 13916, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 12, length 40
14:35:38.716648 IP (tos 0x0, ttl 63, id 13917, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 13, length 40
14:35:38.716648 IP (tos 0x0, ttl 63, id 13918, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 14, length 40
14:35:38.716649 IP (tos 0x0, ttl 63, id 13919, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 15, length 40
14:35:38.716650 IP (tos 0x0, ttl 63, id 13920, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 16, length 40
14:35:38.716651 IP (tos 0x0, ttl 63, id 13921, offset 0, flags [none], proto ICMP (1), length 60)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 17, length 40
Le ping pong du traceroute est parfaitement normal.Mon point est justement que mtr ne provoque pas cet effet de "ping pong" apparent par rapport à traceroute car, de ce que j'ai pu en voir, il fonctionne en mode "synchrone" (attente de la réponse avant d'envoyer un datagramme avec un TTL incrémenté).
...
Après, les différentes implémentations de traceroute, tracert, mdr et autres n'attendent pas forcément chaque réponse avant de poser la question suivante ; certains le font en parallèle, etc…
Le traceroute passe bien deux fois par 10.2.0.211, car 10.2.0.211 ne répond pas quand il est sollicité par un client ; ça doit venir de 10.2.0.4 (et pour qu'il route la demande vers 10.2.0.211, ça doit venir de 10.2.0.5)…
Le première est le ICMP Time Exceeded Message qui indique la vrai distance.
La seconde est le ICMP final, après avoir traversé la table de routage officielle vers 10.2.0.211 (qui passe par 10.2.0.5 et est équivalent au ping)
Mon point est justement que mtr ne provoque pas cet effet de "ping pong" apparent par rapport à traceroute car, de ce que j'ai pu en voir, il fonctionne en mode "synchrone" (attente de la réponse avant d'envoyer un datagramme avec un TTL incrémenté).
Et donc je ne suis pas d'accord avec ça (ou je n'ai pas compris ce que tu as voulu exprimer) :
mtr interprète les résultats différemment, là ou traceroute n'interprète pas vraiment.Dans ce cas, explique moi le ttl à 63 dans le paquet retour :
mtr considère le ICMP time exceeded de 10.2.0.143 comme suffisante et ne va pas plus loin.
traceroute attend la réponse ICMP echo reply officielle.
Les paquets pour un ping (ICMP echo request) vers 10.2.0.143 depuis chez toi passent deux fois par 10.2.0.143, car 10.2.0.143 n'est pas autorisé à te répondre directement* (dans la collecte) ; il ne peut répondre qu'à ce qui est passé par 10.2.0.5 (après la collecte donc qui retourne vers 10.2.0.143 par une route autorisée).
* par contre 10.2.0.143 peut retourner directement un ICMP time exceeded.
$ ping -c 1 10.2.0.143
PING 10.2.0.143 (10.2.0.143) 56(84) bytes of data.
64 bytes from 10.2.0.143: icmp_seq=1 ttl=63 time=6.22 ms
--- 10.2.0.143 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.224/6.224/6.224/0.000 ms
$ sudo tcpdump -nvvv icmp or host 10.2.0.143
dropped privs to tcpdump
tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:12:11.829480 IP (tos 0x0, ttl 64, id 5661, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 3, seq 1, length 64
16:12:11.835664 IP (tos 0x0, ttl 63, id 5661, offset 0, flags [DF], proto ICMP (1), length 84)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 3, seq 1, length 64
Concernant les équipements non K-Box, il y a un peu de bazar :Je serais un des heureux possesseurs d'un équipement en 00:11:32, je m'inquiéterais un peu, cet OUI appartient à Synology.
mtr interprète les résultats différemment, là ou traceroute n'interprète pas vraiment.C'est ce qui m'avait bien perturbé.
mtr considère le ICMP time exceeded de 10.2.0.143 comme suffisante et ne va pas plus loin.
traceroute attend la réponse ICMP echo reply officielle.
Les paquets pour un ping (ICMP echo request) vers 10.2.0.143 depuis chez toi passent deux fois par 10.2.0.143, car 10.2.0.143 n'est pas autorisé à te répondre directement* (dans la collecte) ; il ne peut répondre qu'à ce qui est passé par 10.2.0.5 (après la collecte donc qui retourne vers 10.2.0.143 par une route autorisée).
* par contre 10.2.0.143 peut retourner directement un ICMP time exceeded.
Dans ce cas, explique moi le ttl à 63 dans le paquet retour :Code: [Sélectionner]$ ping -c 1 10.2.0.143
PING 10.2.0.143 (10.2.0.143) 56(84) bytes of data.
64 bytes from 10.2.0.143: icmp_seq=1 ttl=63 time=6.22 ms
--- 10.2.0.143 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.224/6.224/6.224/0.000 ms
$ sudo tcpdump -nvvv icmp or host 10.2.0.143
dropped privs to tcpdump
tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:12:11.829480 IP (tos 0x0, ttl 64, id 5661, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.50 > 10.2.0.143: ICMP echo request, id 3, seq 1, length 64
16:12:11.835664 IP (tos 0x0, ttl 63, id 5661, offset 0, flags [DF], proto ICMP (1), length 84)
10.2.0.143 > 192.168.1.50: ICMP echo reply, id 3, seq 1, length 64
root@HERMES:~$ ping -c 1 10.2.0.211
PING 10.2.0.211 (10.2.0.211): 56 data bytes
64 bytes from 10.2.0.211: seq=0 ttl=64 time=7.217 ms
Observe bien la latence d'environ 7 msroot@HERMES:~$ traceroute 10.2.0.211
traceroute to 10.2.0.211 (10.2.0.211), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.500 ms 2.625 ms 2.405 ms
2 * * *
3 10.2.0.5 (10.2.0.5) 7.186 ms 6.842 ms 6.842 ms
4 10.2.0.4 (10.2.0.4) 6.967 ms 6.967 ms 6.841 ms
5 10.2.0.211 (10.2.0.211) 6.904 ms 6.966 ms 7.091 ms
Observe bien la latence d'environ 2.5 ms pour le premier hop (mesure ICMP time exceeded).Merci bolemo pour le détail du traceroute.
Ton explication met bien en évidence le ping-pong.
T'as oublié d'incrémenté le dernier TTL 4->5 . J'ai compris quand même. :-)
C'est ce qui m'avait bien perturbé.
143 "ment" quand il s'agit de lui et transmet normalement quand il s'agit des autres.
C'est quand même sioux à comprendre.
Cela veut simplement dire que ping s'autorise un maximum de 63 hops (il n'en a besoin que de 6, donc avec 63 ça fonctionne).Oui, ça bloque.
Tu peux le limiter à 6 ainsi : ping -c 1 -t 6 10.2.0.143
Et si tu fais ping -c 1 -t 4 10.2.0.143, ça devrait bloquer (même si 10.2.0.143 est à seulement 2 hops, il t'en faut 6 pour la route officielle via 10.2.0.5)
mais les paquets provenant de 10.2.0.143 vers moi reviennent directement sans repasser par 10.2.0.4 et 10.2.0.5 compte tenu de ce que laisse penser le TTL.
En fait, (un peu simplifié, mais ça en donne l'idée) aucun appareil dans la collecte (chez Covage) avant 10.2.0.5 (qui est chez K-Net) n'est autorisé à interpréter ou répondre à des sollicitations (à part DHCP, ARP et quelques autres trucs), ils ne doivent que faire suivre vers le point de collecte suivant jusqu'à 10.2.0.5 qui est le seul à décider quoi faire de ces paquets ; quand ce dernier voit que c'est 10.2.0.143, il renvoie les paquets vers ce dernier par un chemin qui autorise les interprétations et réponses.
Je serais un des heureux possesseurs d'un équipement en 00:11:32, je m'inquiéterais un peu, cet OUI appartient à Synology.
Bon, tant qu'il y a cette situation de "spam", il peut y avoir quelques "effets de bord" ... mais ce n'est pas rassurant.
Oui, ça bloque.
Mais mon point sur le TTL à 63 dans le "pong" retour de ping, c'était pour dire que le paquet pong n'avait traversé qu'un routeur (ma box), s'il était parti de la cible avec le TTL par défaut à 64.
mais les paquets provenant de 10.2.0.143 vers moi reviennent directement sans repasser par 10.2.0.4 et 10.2.0.5 compte tenu de ce que laisse penser le TTL.
2 10.2.0.143 7.865 ms
3 *
4 10.2.0.5 7.849 ms
5 10.2.0.4 7.842 ms
6 10.2.0.143 7.834 msCar ton premier (après chez toi) et dernier hop sont identiques (et assez élevés d'ailleurs pour un premier hop…)root@HERMES:~$ traceroute -l -q 1 -m 1 10.2.0.211
traceroute to 10.2.0.211 (10.2.0.211), 1 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.374 ms
ping -n 1 -i 1 10.2.0.178 // la collecte locale
Réponse de 192.168.1.1 : Durée de vie TTL expirée lors du transit.
ping -n 1 -i 2 10.2.0.178
Réponse de 10.2.0.178 : Durée de vie TTL expirée lors du transit.
Répond en mentant...
ping -n 1 -i 3 10.2.0.178
Délai d’attente de la demande dépassé.
10.2.0.4 ne répond pas
ping -n 1 -i 4 10.2.0.178
Réponse de 10.2.0.5 : Durée de vie TTL expirée lors du transit.
ping -n 1 -i 5 10.2.0.178
Réponse de 10.2.0.4 : Durée de vie TTL expirée lors du transit.
Répond à 10.2.0.5
ping -n 1 -i 6 10.2.0.178
Réponse de 10.2.0.178 : octets=32 temps=15 ms TTL=63root@HERMES:~$ traceroute -q1 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.656 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.904 ms
4 10.2.0.4 (10.2.0.4) 6.935 ms
5 10.2.0.143 (10.2.0.143) 8.404 ms
root@HERMES:~$ traceroute -q1 10.2.0.178
traceroute to 10.2.0.178 (10.2.0.178), 30 hops max, 38 byte packets
1 *
2 *
3 10.2.0.5 (10.2.0.5) 6.779 ms
4 10.2.0.4 (10.2.0.4) 7.092 ms
5 10.2.0.178 (10.2.0.178) 16.120 ms
@Steph : oui, c'est cohérent.Je continue à penser que l'explication est beaucoup plus simple (mais je ne peux pas le "démontrer"):
Pour le ttl, j'ai aussi 64 depuis mon routeur vers 10.2.0.211… ???
Et 63 pour 10.2.0.4 et 62 pour 10.2.0.5
Si je me ping moi-même, j'ai 64 (comme pour 10.2.0.211)
Il faut en conclure que le TTL est calculé différemment, et ne reflète pas le nombre de hops empruntés, mais la distance en hops depuis l'hôte (peut être mesuré en inverse au moment du retour des paquets).
$ for ttl in {2..6}; do sudo nping -c 1 --icmp --ttl $ttl 10.2.0.143; done
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0155s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=63024 seq=1] IP [ttl=2 id=63423 iplen=28 ]
RCVD (0.0199s) ICMP [10.2.0.143 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=37165 iplen=56 ]
Max rtt: 4.278ms | Min rtt: 4.278ms | Avg rtt: 4.278ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.04 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0182s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=62061 seq=1] IP [ttl=3 id=6029 iplen=28 ]
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (28B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.04 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0178s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=47221 seq=1] IP [ttl=4 id=43852 iplen=28 ]
RCVD (0.0235s) ICMP [10.2.0.5 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=61 id=18562 iplen=56 ]
Max rtt: 5.649ms | Min rtt: 5.649ms | Avg rtt: 5.649ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0130s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=22923 seq=1] IP [ttl=5 id=12429 iplen=28 ]
RCVD (0.0194s) ICMP [10.2.0.4 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=40365 iplen=56 ]
Max rtt: 6.319ms | Min rtt: 6.319ms | Avg rtt: 6.319ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0153s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=7713 seq=1] IP [ttl=6 id=58688 iplen=28 ]
RCVD (0.0209s) ICMP [10.2.0.143 > 192.168.1.50 Echo reply (type=0/code=0) id=7713 seq=1] IP [ttl=63 id=58688 iplen=28 ]
Max rtt: 5.562ms | Min rtt: 5.562ms | Avg rtt: 5.562ms
Raw packets sent: 1 (28B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds
Je continue à penser que l'explication est beaucoup plus simple (mais je ne peux pas le "démontrer"):
les paquets retour en provenance du routeur (10.2.0.143 dans mon cas) sont générés avec un TTL à 64 et reviennent directement à notre LAN, traversant notre routeur personnel (box dans mon cas), d'où un TTL à 63 à l'arrivée.
Sur l'exemple ci-dessous, on observe le même TTL dans le paquet en provenance de 10.2.0.143, lorsque le paquet aller a un TTL de 2 (TTL Exceeded in transit) et un TTL de 6 (Echo Reply).
En revanche, les ping avec TTL croissants de Steph (ou ici) le montrent, la route aller passe par .5 et .4Code: [Sélectionner]$ for ttl in {2..6}; do sudo nping -c 1 --icmp --ttl $ttl 10.2.0.143; done
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0155s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=63024 seq=1] IP [ttl=2 id=63423 iplen=28 ]
RCVD (0.0199s) ICMP [10.2.0.143 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=37165 iplen=56 ]
Max rtt: 4.278ms | Min rtt: 4.278ms | Avg rtt: 4.278ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.04 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0182s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=62061 seq=1] IP [ttl=3 id=6029 iplen=28 ]
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (28B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.04 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0178s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=47221 seq=1] IP [ttl=4 id=43852 iplen=28 ]
RCVD (0.0235s) ICMP [10.2.0.5 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=61 id=18562 iplen=56 ]
Max rtt: 5.649ms | Min rtt: 5.649ms | Avg rtt: 5.649ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0130s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=22923 seq=1] IP [ttl=5 id=12429 iplen=28 ]
RCVD (0.0194s) ICMP [10.2.0.4 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=40365 iplen=56 ]
Max rtt: 6.319ms | Min rtt: 6.319ms | Avg rtt: 6.319ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds
Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0153s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=7713 seq=1] IP [ttl=6 id=58688 iplen=28 ]
RCVD (0.0209s) ICMP [10.2.0.143 > 192.168.1.50 Echo reply (type=0/code=0) id=7713 seq=1] IP [ttl=63 id=58688 iplen=28 ]
Max rtt: 5.562ms | Min rtt: 5.562ms | Avg rtt: 5.562ms
Raw packets sent: 1 (28B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds
C'est presque ça ...
MAIS : ma boucle sur les TTL croissants est entre 2 et 6.
Car, avec un TTL à 1, ça s'arrête à ma box, puisque j'ai lancé à partir d'un PC derrière la box, pas à partir de la box.
Le paquet avec TTL 1 expire donc sur ma box, ça n'avait pas d'intérêt de le montrer.
Je te laisse "éditer" ton message pour la postérité
Voilà donc l'explication tenant compte de la remarque de pju91 :
En supposant que le demandeur est directement derrière l'ONT (depuis le routeur ou un PC sur l'ONT)
Depuis un autre appareil sur le LAN après la Box ou le routeur, le TTL doit donc être de +1 pour passer la Box ou le routeur qui mange un hop
> Demandeur envoie un ICMP echo request vers 10.2.0.143 avec un TTL 1
>< 10.2.0.143 TTL=0 veut faire suivre d'office l'ICMP echo request à 10.2.0.4 mais le TTL l'en empêche et retourne un ICMP time exceeded
< Demandeur reçoit l'ICMP time exceeded
> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 2
> 10.2.0.143 TTL=1 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=0 veut faire suivre d'office l'ICMP echo request à 10.2.0.5 mais le TTL l'en empêche. Il ne retourne rien (ou retourne peut-être un ICMP time exceeded vers 10.2.0.143, mais en ce cas, ce dernier ne transmet pas au Demandeur)
* Demandeur ne reçoit rien
> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 3
> 10.2.0.143 TTL=2 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=1 fait suivre d'office l'ICMP echo request à 10.2.0.5
>< 10.2.0.5 TTL=0 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et veut le faire suivre, mais le TTL l'en empêche et retourne un ICMP time exceeded
< 10.2.0.4 fait suivre le ICMP time exceeded vers 10.2.0.143
< 10.2.0.143 fait suivre le ICMP time exceeded vers le demandeur
< Demandeur reçoit le ICMP time exceeded
> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 4
> 10.2.0.143 TTL=3 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=2 fait suivre d'office l'ICMP echo request à 10.2.0.5
> 10.2.0.5 TTL=1 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et le fait donc suivre
>< 10.2.0.4 TTL=0 reçoit l'ICMP echo request et veut le faire suivre à 10.2.0.143 mais le TTL l'en empêche et retourne un ICMP time exceeded
< 10.2.0.143 fait suivre l'ICMP time exceeded vers le demandeur
< Demandeur reçoit le ICMP time exceeded
> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 5
> 10.2.0.143 TTL=4 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=3 fait suivre d'office l'ICMP echo request à 10.2.0.5
> 10.2.0.5 TTL=2 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et le fait donc suivre
> 10.2.0.4 TTL=1 reçoit l'ICMP echo request et le fait suivre vers 10.2.0.143 qu'il connaît
>< 10.2.0.143 reçoit l'ICMP echo request et répond en retournant un ICMP echo reply au demandeur
< Demandeur reçoit le ICMP echo reply
root@HERMES:~$ traceroute -q1 10.2.0.211
traceroute to 10.2.0.211 (10.2.0.211), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.468 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.810 ms
4 10.2.0.4 (10.2.0.4) 6.935 ms
5 10.2.0.211 (10.2.0.211) 6.966 ms$ traceroute -q1 -n 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 60 byte packets
1 192.168.1.1 8.663 ms
2 10.2.0.143 8.599 ms
3 *
4 10.2.0.5 8.529 ms
5 10.2.0.4 8.520 ms
6 10.2.0.143 8.504 ms
root@HERMES:~$ traceroute -q1 10.2.0.4
traceroute to 10.2.0.4 (10.2.0.4), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.312 ms
2 10.2.0.4 (10.2.0.4) 7.029 ms
root@HERMES:~$ traceroute -q1 10.2.0.5
traceroute to 10.2.0.5 (10.2.0.5), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.624 ms
2 10.2.0.4 (10.2.0.4) 6.935 ms
3 10.2.0.5 (10.2.0.5) 7.029 ms
root@HERMES:~$ traceroute -q1 10.2.0.211
traceroute to 10.2.0.211 (10.2.0.211), 30 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.499 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.779 ms
4 10.2.0.4 (10.2.0.4) 6.904 ms
5 10.2.0.211 (10.2.0.211) 6.967 msroot@HERMES:~$ traceroute -q1 -m1 10.2.0.5
traceroute to 10.2.0.5 (10.2.0.5), 1 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.280 ms@pju91 : la latence de ton premier hop est étonnante… C'est assez élevé entre ton PC et la box ???C'est la K-Box, elle doit prendre son temps pour répondre ...
$ traceroute -n -q1 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 60 byte packets
1 192.168.1.1 5.669 ms
2 10.2.0.143 4.897 ms
3 *
4 10.2.0.5 4.933 ms
5 10.2.0.4 4.959 ms
6 10.2.0.143 4.994 ms
Sur ce vieux PC (2012 je crois), pas mis à jour très souvent $ neofetch|egrep "OS|Host|Kernel|CPU|Memory"
OS: Fedora Linux 35 (Workstation Edition) x86_64
Host: HP ENVY TS Sleekbook 4 088E120000305900000320100
Kernel: 5.16.16-200.fc35.x86_64
CPU: Intel i5-3337U (4) @ 2.700GHz
Memory: 2068MiB / 3808MiB
le débit Internet me suffit : $ speedtest|egrep "Hosted by|Download|Upload"
Hosted by Hivane NetWork Cubic (Ivry-sur-Seine) [21.02 km]: 5.33 ms
Download: 420.86 Mbit/s
Upload: 474.06 Mbit/s
C'est la K-Box, elle doit prendre son temps pour répondre ...
Voici un autre traceroute, lancé à partir de mon seul (vieux) PC en Ethernet (le reste chez moi est en WiFi et mon PC principal est assez loin de la box).
C'est encore plus fort : les équipements sur le WAN répondent plus vite que la box.Code: [Sélectionner]$ traceroute -n -q1 10.2.0.143Sur ce vieux PC (2012 je crois), pas mis à jour très souvent
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 60 byte packets
1 192.168.1.1 5.669 ms
2 10.2.0.143 4.897 ms
3 *
4 10.2.0.5 4.933 ms
5 10.2.0.4 4.959 ms
6 10.2.0.143 4.994 msCode: [Sélectionner]$ neofetch|egrep "OS|Host|Kernel|CPU|Memory"le débit Internet me suffit :
OS: Fedora Linux 35 (Workstation Edition) x86_64
Host: HP ENVY TS Sleekbook 4 088E120000305900000320100
Kernel: 5.16.16-200.fc35.x86_64
CPU: Intel i5-3337U (4) @ 2.700GHz
Memory: 2068MiB / 3808MiBCode: [Sélectionner]$ speedtest|egrep "Hosted by|Download|Upload"
Hosted by Hivane NetWork Cubic (Ivry-sur-Seine) [21.02 km]: 5.33 ms
Download: 420.86 Mbit/s
Upload: 474.06 Mbit/s
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.2.0.211 0.0% 24 2.6 2.6 2.4 2.8 0.1
2. (waiting for reply)
3. 10.2.0.5 0.0% 23 6.9 6.9 6.7 7.1 0.1
4. 10.2.0.4 0.0% 23 7.0 7.1 6.9 7.7 0.1
5. 10.2.0.143 0.0% 23 8.5 8.6 8.4 9.0 0.2
6. pju91 0.0% 23 10.2 10.1 9.1 10.4 0.3
Bah pour la plupart des activités de base, c'est largement suffisant… :)Voilà dans l'autre sens si tu veux comparer :
La K-Box est un peu lente en effet ;D
Ce qui est curieux, c'est que quand je mtr vers chez toi, 10.2.0.143 est plus loin que 10.2.0.4 d'1,5 ms, or de chez toi, entre ton premier hop sur 10.2.0.143 et celui sur 10.2.0.4, il n'y a pas de différence notable. Peut-être la box fausse-t'elle un peu le calcul, je ne sais pas.Code: [Sélectionner]Host Loss% Snt Last Avg Best Wrst StDev
1. 10.2.0.211 0.0% 24 2.6 2.6 2.4 2.8 0.1
2. (waiting for reply)
3. 10.2.0.5 0.0% 23 6.9 6.9 6.7 7.1 0.1
4. 10.2.0.4 0.0% 23 7.0 7.1 6.9 7.7 0.1
5. 10.2.0.143 0.0% 23 8.5 8.6 8.4 9.0 0.2
6. pju91 0.0% 23 10.2 10.1 9.1 10.4 0.3
$ mtr -c4 -r $bolemo|sed "s/- .*ftth.cust.kw/- bolemo\t\t\t/"
Start: 2022-05-05T21:56:31+0200
HOST: fedora Loss% Snt Last Avg Best Wrst StDev
1.|-- box 0.0% 4 3.3 3.4 3.3 3.5 0.1
2.|-- 10.2.0.143 0.0% 4 4.9 5.0 4.8 5.2 0.2
3.|-- ??? 100.0 4 0.0 0.0 0.0 0.0 0.0
4.|-- 10.2.0.5 0.0% 4 5.6 6.0 5.6 6.3 0.3
5.|-- 10.2.0.4 0.0% 4 6.0 6.2 6.0 6.5 0.2
6.|-- 10.2.0.211 0.0% 4 11.0 10.9 10.8 11.0 0.1
7.|-- bolemo 0.0% 4 13.0 13.0 12.7 13.3 0.2
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.2.0.211 0.0% 24 2.6 2.6 2.4 2.8 0.1
2. (waiting for reply)
3. 10.2.0.5 0.0% 23 6.9 6.9 6.7 7.1 0.1
4. 10.2.0.4 0.0% 23 7.0 7.1 6.9 7.7 0.1
5. 10.2.0.143 0.0% 23 8.5 8.6 8.4 9.0 0.2
6. pju91 0.0% 23 10.2 10.1 9.1 10.4 0.3
HOST: fedora Loss% Snt Last Avg Best Wrst StDev
1.|-- box 0.0% 4 3.3 3.4 3.3 3.5 0.1
2.|-- 10.2.0.143 0.0% 4 4.9 5.0 4.8 5.2 0.2
3.|-- ??? 100.0 4 0.0 0.0 0.0 0.0 0.0
4.|-- 10.2.0.5 0.0% 4 5.6 6.0 5.6 6.3 0.3
5.|-- 10.2.0.4 0.0% 4 6.0 6.2 6.0 6.5 0.2
6.|-- 10.2.0.211 0.0% 4 11.0 10.9 10.8 11.0 0.1
7.|-- bolemo 0.0% 4 13.0 13.0 12.7 13.3 0.2| Différence avg entre | depuis bolemo | depuis pju91 (box) |
| bolemo et 10.2.0.211 : | 2.4 ms | 2.1 ms |
| 10.2.0.211 et 10.2.0.4 : | * | 4.7 ms |
| 10.2.0.211 et 10.2.0.5 : | 4.3 ms | 4.9 ms |
| 10.2.0.4 et 10.2.0.5 : | 0.2 ms | 0.2 ms |
| 10.2.0.5 et 10.2.0.143 : | 1.7 ms | 1.0 ms |
| 10.2.0.4 et 10.2.0.143 : | 1.5 ms | * |
| 10.2.0.143 et pju91 (box) : | 1.7 ms | 1.6 ms |
C'est cohérent, et on peut établir grossièrement les distances (latences) entre les routeurs :J'aime bien ton analyse, qui montre effectivement une bonne "cohérence" ...
Différence avg entre depuis bolemo depuis pju91 (box) bolemo et 10.2.0.211 : 2.4 ms 2.1 ms 10.2.0.211 et 10.2.0.4 : * 4.7 ms 10.2.0.211 et 10.2.0.5 : 4.3 ms 4.9 ms 10.2.0.4 et 10.2.0.5 : 0.2 ms 0.2 ms 10.2.0.5 et 10.2.0.143 : 1.7 ms 1.0 ms 10.2.0.4 et 10.2.0.143 : 1.5 ms * 10.2.0.143 et pju91 (box) : 1.7 ms 1.6 ms
Sinon, un peu avant 9h ce matin, les deux Freebox ont cessé de fuir. À suivre…C'était quand même très fort, ça ... je n'ai franchement pas d'explication à ce que tu as observé. Je ne pense pas que Free soit sur une "offre activée" dans ta région.
S'agit-il de clients ayant quitté K-Net et ayant déjà branché leurs Freebox sans attendre le raccordement au PM ?Ou de clients ayant un double WAN K-net (fibre) et Free (failover ADSL) avec fuite LAN vers WAN de la K-box qui expose donc la FreeBox?
Ou de clients ayant un double WAN K-net (fibre) et Free (failover ADSL) avec fuite LAN vers WAN de la K-box qui expose donc la FreeBox?Oui, évidemment, tu dois avoir raison. Vu le débit lamentable que j'avais en ADSL, je me suis dépêché de résilier lorsque j'ai été éligible à la fibre. Il ne me serait pas venu à l'idée de garder 2 abonnements puisque comme tout le monde, j'imaginais que la disponibilité en FTTH serait excellente.
Les geek aiment bien le NAS et les fonctionnalités (VPN) de la Free Box et Free tarde à venir sur les RIP.
Et vu l'état du réseau fibre, c'est prudent de garder un ADSL.
Ou de clients ayant un double WAN K-net (fibre) et Free (failover ADSL) avec fuite LAN vers WAN de la K-box qui expose donc la FreeBox?
Les geek aiment bien le NAS et les fonctionnalités (VPN) de la Free Box et Free tarde à venir sur les RIP.
Et vu l'état du réseau fibre, c'est prudent de garder un ADSL.
Intéressant de remarquer qu'hier, lorsque l'incident de spam DHCPv6 a cessé, toutes les fuites APIPA (K-Box et autres) ont également cessées, sauf le Siemens.Coupure générale de courant? :P
(https://i.ibb.co/qCHs4NZ/Capture-d-cran-2022-05-16-14-39-17.png)
Niveau fuites K-Box, on a principalement une seule fuite de type mDNS.
Alors arrêt des fuites ? Meilleure isolation ou filtrage entre sous-collectes ?
Coupure générale de courant? :P
ça colle pour l'heure.
https://www.tf1info.fr/meteo/video-intemperies-incendies-inondations-coupures-d-electricite-grele-foudre-les-degats-des-violents-orages-du-15-mai-normandie-mayenne-eure-calvados-2219880.html
Dans mon coin du 14, aucune coupure. J'ai vu dans l'autre post que pour toi, ça a duré un petit moment… Ton internet (LOS rouge) est revenu ?Non. ça clignote toujours. J'ai le courant mais toujours pas le net, hormis un filet de 3G (entre 0 et 1 barre) quand je suis dans les combles (comme maintenant :P). J'ai appelé le service technique, ils sont au courant il y a un ticket chez Axione.
C'est quand même dommage que malgré tes efforts et notre contact direct avec Icotera, K-Net reste muet sur ce sujet et totalement incapable de résoudre le problème.
Vous pensez vraiment que K-Net a la tréso pour changer tout le parc de box là ?Mettant de côté les questions de trésorerie, c'est un exercice logistique que K-Net n'a pas les moyens de mener à bien, je l'ai déjà sous-entendu ici (https://lafibre.info/k-net-incident/communication-k-net-pannes/msg949546/#msg949546).
Rappelons aussi qu'il y'a plusieurs milliers de kbox v2 en stock de clients qui ont résilié.Plusieurs milliers ... je ne sais pas. Beaucoup, certainement.
Vous pensez vraiment que K-Net a la tréso pour changer tout le parc de box là ?Il y a longtemps qu'elles sont amorties. Ensuite voir le prix de revient pour eux d'une box neuve, ça doit pas chercher bien loin.
Rappelons aussi qu'il y'a plusieurs milliers de kbox v2 en stock de clients qui ont résilié.
Et ils peuvent les remplacer petit à petit…Si j'étais K-Net, je ne lancerais pas un tel chantier (pourtant assez "modeste" comparé à un remplacement total du parc) avant d'avoir complètement stabilisé les processus (notamment support), l'infrastructure, le système d'information, les outils de supervision et de gestion à distance des K-Box actuelles.
Par exemple, toutes celles qui fuient ou ont des problèmes -> échange vers v3
Nouveaux clients -> v3
Et pour ceux qui n'ont pas de problèmes, remplacement petit à petit.
Si j'étais K-Net, je ne lancerais pas un tel chantier (pourtant assez "modeste" comparé à un remplacement total du parc) avant d'avoir complètement stabilisé les processus (notamment support), l'infrastructure, le système d'information, les outils de supervision et de gestion à distance des K-Box actuelles.
C'est peut-être le cas… On a aucune annonce officielle, aucune timeline.Quel crédit accorder aux messages twitter de FB?
On ne sait pas vraiment ce qui se trame. On déduit d'après les tweets de FB qu'il va y avoir un changement depuis Icotera vers Huawei, mais c'est sujet à interprétation et interpolation des tweets… Donc il ne va peut-être rien se passer, ou c'est pour quelque chose de totalement différent (équipement interne)…
Si j'étais K-Net et que je passais à une autre box, j'intègrerais dedans quelques outils de supervision… Au moins pour pouvoir écouter les boucles de collecte et avoir un retour de ce qui s'y passe… Car actuellement, les FAI en offre active n'ont pas de vision sur les collectes.... Et je demanderais à l'OI de faire le nécessaire pour "cloisonner" et/ou filtrer les équipements qui se comportent mal ! C'est beaucoup plus facile à faire côté OI que OC.
Pouvoir faire des tcpdump (de la boucle) à distance…
Et aussi avoir des box qui se comportent bien dans les boucles ouvertes aux broadcasts et aux fuites…
Quel crédit accorder aux messages twitter de FB?... Et je demanderais à l'OI de faire le nécessaire pour "cloisonner" et/ou filtrer les équipements qui se comportent mal ! C'est beaucoup plus facile à faire côté OI que OC.
Mon voisin direct, qui utilise toujours sa Kbox v2, subit déco sur déco. Il est au bout du rouleau.Ce qui est curieux est que tu n'avais jamais eu d'ennui avant avec ces décos.
Mon voisin direct, qui utilise toujours sa Kbox v2, subit déco sur déco. Il est au bout du rouleau.Tu peux peut-être lui sous-louer ta connexion (en tirant un câble Ethernet jusque chez lui) ? ;D
Je lui ai conseillé de passer sur un routeur perso (comme je l'ai été ici) car depuis que j'ai fait cela, je n'ai plus aucun problème de connexion.Tant mieux ... et tu confirmes les arguments donnés par bolemo en faveur du routeur perso. En ce qui me concerne, le réseau Covage sur lequel je suis étant "sain", je garde ma K-Box.
Et vu que tout pointe la Kbox v2 du doigt et que la situation semble rentrer dans des tractations entre le fabricant du routeur et le FAI, je ne pense malheureusement pas que le souci soit résolu rapidement... (d’où le routeur perso, solution certes plus onéreuse mais radicale et très rapide à mettre en place).Le problème est uniquement chez K-Net a priori, Icotera estimant que leurs produits (dans les dernières versions de firmware) ne sont pas affectés.
Entre les tests officiels à effectuer coté Knet et Icotera, les "désossage" de Kbox à envisager, les renvois de box "cassées" à Icotera pour étude, la reconnaissance officielle du problème, le développement d'un patch ou d'une "solution" qu'elle quelle soit, l'éventuel l'accord financier / commercial à trouver entre les 2 parties, etc. ça sent quand même le bourbier administratif pour Knet ce truc.
Et comme dit plus haut, je ne suis pas certain qu'ils aient une tréso monstrueuse cette année avec tous les problèmes et les départs de clients / employés qu'ils ont eu. Sans faire le devin de comptoir, je ne suis pas certain que ce soit résolu cette année.Les comptes 2021 (exercice terminé fin décembre) de K-Net devraient être déposés avant fin juin ... mais ils ne montreront pas la catastrophe du début d'année 2022.
Bref, bon courage aux téméraires qui conserveront leur box "fuyante"...merci (pour eux).
Ce qui est curieux est que tu n'avais jamais eu d'ennui avant avec ces décos.
C'est bien que l'outil qui était utilisé avant par K-net fonctionnait et que désormais il ne fonctionne plus!
Tu ne peux pas filtrer que sur une adresse MAC ?
Merci au fait sur ta vidéo de plombier. J'ai passé bien 30min à faire de la plomberie virtuelle sur Youtube après :D
Voilà, j'ai maintenant un cache de 24h de tous les paquets de type fuite APIPA et mDNS (128 premiers octets).Très bien, mais rien ne prouve que ce soit ce type de paquets qui provoque le déclenchement ou l'arrêt des "fuites". La seule certitude à mon avis, c'est qu'il s'agit de broadcast ou de multicast.
Cela ne prendra pas plus de 30 Mo, et me donnera la possibilité d'analyser les paquets intéressants après-coup ;)
Très bien, mais rien ne prouve que ce soit ce type de paquets qui provoque le déclenchement ou l'arrêt des "fuites". La seule certitude à mon avis, c'est qu'il s'agit de broadcast ou de multicast.
Je ne cherchais pas particulièrement de signaux « stop » et ne pensais même pas qu'il y en avait (on pensait qu'il fallait nécessairement faire un reset ou avoir un accès SSH pour arrêter), mais le signal APIPA envoyé par 00:26:86:00:00:00 semble être ce qui a arrêté simultanément la fuite de deux K-Box (pas la troisième cependant), ce qui laisse supposer qu'il est possible de stopper les fuites avec un signal APIPA spécifique.Bizarre quand même, je pensais que ce qui pouvait déclencher les bugs K-Box était plutôt lié aux vulnérabilités des SoC Realtek. Ca paraît surprenant qu'un paquet type APIPA puisse remettre en place une situation anormale.
Bizarre quand même, je pensais que ce qui pouvait déclencher les bugs K-Box était plutôt lié aux vulnérabilités des SoC Realtek. Ca paraît surprenant qu'un paquet type APIPA puisse remettre en place une situation anormale.
Bon, à voir si tu parviens à capturer des paquets "utiles", puis à les balancer sur le réseau ensuite.
1) L'Icotera a un problème de fuite (SoC Realtek),Pas sûr que l'Icotera s'exprime avec des adresses MAC hors de leur OUI affecté.
2) La partie Wifi 5G de l'Icotera (SoC Quantenna) serait à l'origine des paquets APIPA (qui devraient être interne à l'Icotera qui a deux OS).
$ nmcli dev wifi |awk '$1 ~ "[0-9]+:*" {print $1};$2 ~ "[0-9]+:*" {print $2}'|sed "s/$bt5/XX/"
00:1E:80:74:XX:14
00:1E:80:74:XX:18
Ca correspond à mes 2 SSID en 2.4 GHz et 5 GHz.Bon, ben j'ai pu fabriquer et envoyer un ARP Reply… Résultat, ça a re-déclenché les 2 fuites APIPA qui étaient arrêtées… Et 00:26:86:00:00:00 répond à chaque fois avec un ARP Request…Heuu tu envoies un ARP reply en broadcast? Sinon, vers quelle MAC ? avec quelles IP ?
La bonne nouvelle, est que j'arrive à envoyer des paquets que les K-Box reçoivent et que j'obtiens des réactions (pas encore celles voulues).bon courage.
Reste à trouver le bon paquet à envoyer pour stopper les fuites APIPA.
Au passage, 00:26:86:00:00:00 c'est une MAC Quantenna !Ca peut être quoi ce device ? Je ne pense pas que ce soit une K-Box, voir mon post précédent.
Heuu tu envoies un ARP reply en broadcast? Sinon, vers quelle MAC ? avec quelles IP ?
bon courage.Ca peut être quoi ce device ? Je ne pense pas que ce soit une K-Box, voir mon post précédent.
J'ai essayé, et je peux stopper ces fuites APIPA (enfin ⅔) en envoyant cette trame :)
Désolé mais là, tu m'as troué le cul.
Bravo !
00:11:33:55:77:bb
[...]
un appareil Siemens
Nope.
* * * * * /opt/bolemo/scripts/sendrawpacket.py ethwan /mnt/optware/apipa-fix-packet2.datEt un petit crontab qui va bien devrait protéger notre collecte :)Je viens de regarder ton grafana, ça a l'air de bien fonctionner ... Merci pour ceux concernés !Code: [Sélectionner]* * * * * /opt/bolemo/scripts/sendrawpacket.py ethwan /mnt/optware/apipa-fix-packet2.dat
J'envoie le paquet « stop » toutes les minutes, en prévention.
Je viens de regarder ton grafana, ça a l'air de bien fonctionner ... Merci pour ceux concernés !Je pense vraiment que ce paquet « stop » empêche l'émission des paquets APIPA à leur source, mais ne résout pas le problème de fuite que je pense plus large qu'il paraît…
root@HERMES:~$ tcpdump -i ethwan -Q in -Aq ether src 00:11:33:55:77:cc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
13:50:24.725477 IP 169.254.1.2.52310 > 169.254.1.1.2325: UDP, bad length 1817 > 1472
E...G. .@............V ..!l.....wlan0...........~.................... Statistics...
up_time: 11136740s
ch_utilization: 0
tx_time: 0
rx_time: 0
tx_packets: 2763785
tx_bytes: 3864269157
tx_mgnt_pkts: 2594160
tx_ucast_pkts: 5345192
tx_mcast_pkts: 6717
tx_bcast_pkts: 6036
tx_retrys: 255743
tx_fails: 8416
tx_drops: 9443
tx_dma_err: 0
rx_dma_err: 0
tx_dma_status: 0
rx_dma_status: 0
rx_packets: 589139
rx_bytes: 118714590
rx_mgnt_pkts: 28221815
rx_ucast_pkts: 569188
rx_mcast_pkts: 21693
rx_bcast_pkts: 28220073
rx_retrys: 37815
rx_crc_errors: 0
rx_errors: 0
rx_data_drops: 72
rx_mc_pn_drops: 0
rx_decache: 14444
rx_fifoO: 0
rx_rdu: 6
rx_reuse: 3252069
beacon_ok: 108749418
beacon_er: 358
beacon_dma_err:0
freeskb_err: 0
dz_queue_len: 0
check_cnt_tx: 0
check_cnt_adaptivity: 0
check_cnt_fw: 0
check_cnt_rx: 0
cnt_sta1_only: 0
cnt_sta2_only: 0
cnt_sta1_sta2: 0
cnt_mu_swqoverflow: 137523
cnt_mu_swqtimeout: 11704
VO drop: 0
VI drop: 0
BE drop: 0
BK drop: 0
reused_skb: 0
skb_free_num: 31
rx_enqueue_cnt: 0
rx_rdu_dis_int: 0
tx_avarage: 0
rx_avarage: 0
cur_tx_rate: 1
swq enable: 1
swq hw timer: 1
use hal: 1
use outsrc: 1
rf_lock:
13:50:24.725508 IP 169.254.1.2 > 169.254.1.1: udp
E..mG...@........... false
IQK total count: 15
Check IQK: 0
check spur: 0
adaptivity_enable: 0
amsdu_to_pkt: 0
amsdu_check_pkt: 0
swq_enque_pkt: 2732977
swq_xmit_out_pkt: 2732977
swq_real_enque_pkt: 1983846
swq_real_deque_pkt: 1983846
swq_residual_drop_pkt: 0
swq_overflow_drop_pkt: 0
...
Mac de la K-Box qui spamme : 00:1e:80:21:6c:85 (4,3 kilo paquets par seconde)Il te reste à faire comme pour les fuites APIPA :
Il te reste à faire comme pour les fuites APIPA :
Répondre au solicit DHCP v6 (en te faisant passer pour un serveur DHCP v6 avec un Advertise), et échanger en Request / Reply pour faire taire la box.
Je plaisante ... ça me paraît un peu "chaud" quand même de jouer à ce petit jeu.
J'ai déjà essayé ça !Je m'étonne que "l'heureux" abonné qui dispose de cette box ne se rende pas compte de problèmes de performances et n'ait pas l'idée de redémarrer sa box qui doit être bien poussive. Bon, peut-être qu'il essaie d'appeler le support K-Net, sans succès.
Sans succès, je crois que la box quand elle s'emballe n'écoute pas. Ce qui semble logique car la fréquence de 4 300 requêtes par seconde est totalement anormale.
Bolemo postule comme PDG adjoint chez K-Net ;)
Ca doit être pour ca que ma box a la led rouge depuis deux jours encore :(
J'ai cru lire sur ce forum qu'utiliser un routeur perso bien dimensionné avec quelques règles firewall pouvait aider?
Si c'est le cas, je vais probablement essayer d'en acheter un vite fait.
Si j'habitais dans l'Ain proche du QG de K-Net, je me serais proposé pour aller leur donner un coup de main sur place…
Mais sinon oui, on ferait une belle équipe, avec pju91, thedark, Steph et tout ceux qui ont aidé à diagnostiquer, tester, rechercher…
Ça me fait penser à une pub qui tourne ces dernières années : un FAI qui appartient à ses clients, ça change tout ;D
un FAI qui appartient à ses clients, ça change tout ;D
un FAI qui appartient à ses clients, ça change tout ;DC'est marrant, c'est justement une idée qui me trotte dans la tête :)
C'est marrant, c'est justement une idée qui me trotte dans la tête :)Ma banque m'appartient (CASDEN), mon assurance aussi (MAIF), ma mutuelle encore un peu (MGEN), je veux bien posséder aussi mon FAI! :-*
Ma banque m'appartient (CASDEN), mon assurance aussi (MAIF), ma mutuelle encore un peu (MGEN), je veux bien posséder aussi mon FAI! :-*Steph, n'entrons pas dans le débat public (qui t'emploie apparemment) / privé (qui m'emploie) ici STP :D
Steph, n'entrons pas dans le débat public (qui t'emploie apparemment) / privé (qui m'emploie) ici STP :DTu pourrais très bien travailler dans le privé et être sociétaire de tes banque, assurance, mutuelle, etc... Cela n'a rien à voir.
Tu sais où me trouver :P
Ça serait bien si les investisseurs chez K-Net (clients à vie) avaient un droit de regard…
Et un OI qui appartient à ses… heu !Pas complètement, les collectivités n'ont pas financé l'intégralité des investissements faits par les OI ... loin de là.
Les RIP nous appartiennent déjà… Curieux comment Covage est si opaque alors que d'un côté il exploite le réseau en notre nom ! et que de l'autre côté, nous sommes les utilisateurs/clients finaux de l'infrastructure.
Ça serait bien si les contribuables pouvaient avoir un droit de regard sur ce qu'il se passe, les décisions, les problèmes, le détail des infrastructures…C'est le rôle des élus (communautaires, départementaux, ou autres) et de leurs services
C'est le rôle des élus (communautaires, départementaux, ou autres) et de leurs services
C'est à eux de se plaindre ...
Pas complètement, les collectivités n'ont pas financé l'intégralité des investissements faits par les OI ... loin de là.
En revanche, elles conservent des "biens de retour" à la fin de la durée contractuelle de la concession.C'est le rôle des élus (communautaires, départementaux, ou autres) et de leurs services
C'est à eux de se plaindre ... ce qu'ils font de manière plus ou moins bruyante selon les RIP.
Et les clients malheureux des OI que nous sommes doivent se plaindre auprès des élus ...
Ça serait bien si les investisseurs chez K-Net (clients à vie) avaient un droit de regard…Un investisseur actionnaire il a un droit de regard dans la boite. Mais j'ai cru comprendre que "l'abonné à vie" chez K-net n'est pas un actionnaire, ceci explique peut-être cela? :P
Donc oui, pour cela et d'autre bénéfices, je recommande un routeur perso.Je ne peux que souscrire sans réserve. Sur mes 2 (et bientôt 3 - en attente d'activation) abos K-net, je suis en routeur perso: ça tourne comme une horloge suisse, vraiment pas à me plaindre. Après je suis pas sur une collecte ghetto-syle non plus (Axione partout), ça peut aider :)
Tu pourrais très bien travailler dans le privé et être sociétaire de tes banque, assurance, mutuelle, etc... Cela n'a rien à voir.
Et dire que l'Europe cherche à couler ces organismes aux noms de la concurrence libre et non faussée... :'(
Merci pour ton retour de spécialiste :)Voir pour ce qui te concerne par exemple : https://fibre.guide/deploiement/rip/fibre-calvados-normandie. On y lit :
Les investissements représentent 170 millions d’euros, dont 96 millions d’euros de participation publique (Département, Région, État et Union européenne).C'était vrai à la date de rédaction, je ne sais pas de quand date cette page, les montants ont pu évoluer.
ff ff ff ff ff ff
00 26 86 00 00 00
08 06
00 01 08 00 06 04
00 01
00 26 86 00 00 00
A9 FE 01 03
00 00 00 00 00 00
A9 FE 01 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Alors le paquet magique (envoyé toutes les 3 minutes) semble bien fonctionner…Tant mieux !
À part quelques brèves émissions APIPA irrégulières pendant l'incident DHCPv6, je ne vois plus de fuites de type APIPA venant de K-Box.
Maintenant, pourquoi le fait d'envoyer un ARP Request en broadcast vers 00:26:86:00:00:00 résout ce problème ? C'est un mystère…Heuu pour moi c'est depuis 00:26:86:00:00:00
Je soupçonne que cela provoque une réponse locale au sein de la K-Box depuis le SoC Quantenna (réponse qui elle ne fuit pas mais remet des choses en place). C'est comme si les K-Box envoyaient les ARP Request au mauvais endroit ou de mauvaises requêtes, et que celui que j'envoie arrive lui au bon endroit.difficile à dire effectivement
Cela règle-t'il la fuite en soi ou simplement l'émission de paquets APIPA… je ne sais pas.
Ce paquet ne fait rien par rapport aux fuites mDNS que je vois : je vois toujours les fuites mDNS de clients avec K-Box (des fuites venant de leur LAN, les mêmes que celles reportées il y a quelques mois…)Ces paquets MDNS "fuyards" présentent moins de risques d'affecter le bon fonctionnement des clients de K-Net.
Ici, K-Box qui fuie ou LAN mal conçu ? Pareil, je ne sais pas…
Après cela, hors K-Box, il y a quand même :Tu ne peux rien faire, et les propriétaires de ces équipements ne lisent certainement pas ce forum.
– 5 appareils Synology qui fuient en mDNS sur le WAN :-[ (à priori des routeurs…)
– Un appareil Niko NV (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjmnuuwxvr3AhXuQvEDHWkeDIYQFnoECAsQAQ&url=https%3A%2F%2Fwww.niko.eu%2Fen&usg=AOvVaw2_-NPsXOrSaTszT34qbk_I) qui n'est à priori pas un routeur, donc ça vient soit d'un LAN mal conçu ou qui fuit (K-Box fuyant ?)
– Un appareil Asus
– Un appareil Belkin avec une importante fuite permanente mDNS (1,7 paquets par seconde)
– et ce mystérieux appareil 00:11:33:55:77:cc (et :bb)
Tant mieux !
En espérant que ça arrête aussi les paquets avec des adresses LAN "régulières" en 192.168/16.Heuu pour moi c'est depuis 00:26:86:00:00:00
- source Ethernet dans l'entête Ethernet
- sender MAC address dans la requête ARP.difficile à dire effectivementCes paquets MDNS "fuyards" présentent moins de risques d'affecter le bon fonctionnement des clients de K-Net.Tu ne peux rien faire, et les propriétaires de ces équipements ne lisent certainement pas ce forum.
Sinon, pour les paquets avec les adresses régulières 192.168… ils sont toujours là, c'est justement les fuites mDNS passant par la K-Box 00:1e:80:9b:2f:90…Tu as déjà vu autre chose que du mDNS, par exemple lors des analyses faites sur l'incident de superpicsou :
Tu as déjà vu autre chose que du mDNS, par exemple lors des analyses faites sur l'incident de superpicsou :
https://lafibre.info/k-net-internet/perte-de-la-resolution-des-dns-mac-ocs/msg943522/#msg943522
root@HERMES:~$ tcpdump -i ethwan -Q in -vvvt 'not (ip6 or arp) and not (ether src 20:e0:9c:53:7a:09 or net 224.0.0.0/16 or net 169.254.0.0/16)'
tcpdump: listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
IP (tos 0x0, ttl 64, id 16806, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 55174, offset 0, flags [DF], proto UDP (17), length 78)
2.59.236.229.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 55183, offset 0, flags [DF], proto UDP (17), length 78)
2.59.236.229.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 55184, offset 0, flags [DF], proto UDP (17), length 78)
2.59.236.229.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 55289, offset 0, flags [DF], proto UDP (17), length 78)
2.59.236.229.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 55290, offset 0, flags [DF], proto UDP (17), length 211)
2.59.236.229.netbios-dgm > 2.59.239.255.netbios-dgm: [udp sum ok] UDP, length 183
IP (tos 0x0, ttl 64, id 46991, offset 0, flags [DF], proto UDP (17), length 78)
128-239-59-2.ftth.cust.kwaoo.net.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 17500, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 47090, offset 0, flags [DF], proto UDP (17), length 78)
128-239-59-2.ftth.cust.kwaoo.net.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 47091, offset 0, flags [DF], proto UDP (17), length 78)
128-239-59-2.ftth.cust.kwaoo.net.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 47188, offset 0, flags [DF], proto UDP (17), length 78)
128-239-59-2.ftth.cust.kwaoo.net.netbios-ns > 2.59.239.255.netbios-ns: [udp sum ok] UDP, length 50
IP (tos 0x0, ttl 64, id 47189, offset 0, flags [DF], proto UDP (17), length 211)
128-239-59-2.ftth.cust.kwaoo.net.netbios-dgm > 2.59.239.255.netbios-dgm: [udp sum ok] UDP, length 183
IP (tos 0x0, ttl 64, id 18111, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 18684, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 55796, offset 0, flags [DF], proto UDP (17), length 229)
2.59.236.229.netbios-dgm > 2.59.239.255.netbios-dgm: [udp sum ok] UDP, length 201
IP (tos 0x0, ttl 64, id 19219, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
PPPoE PADI [Service-Name] [Host-Uniq 0x00]
IP (tos 0x0, ttl 64, id 50061, offset 0, flags [DF], proto UDP (17), length 229)
2.59.238.177.netbios-dgm > 2.59.239.255.netbios-dgm: [udp sum ok] UDP, length 201
IP (tos 0x0, ttl 64, id 19662, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 20474, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 20708, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 21495, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
IP (tos 0x0, ttl 64, id 22443, offset 0, flags [DF], proto UDP (17), length 48)
124-236-59-2.ftth.cust.kwaoo.net.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
^C
23 packets captured
1034 packets received by filter
0 packets dropped by kernel
C'est des IP K-net?
Transmets les IP à K-net. Ça occupera le support qui s'ennuie un peu en ce moment! ;)
S'ils peuvent faire cesser ce souk, cela remettrait d'aplomb le 14 pour les microcoupures.
Du coup, il faudrait faire tourner ton outil sur le 91 pour traquer les fuites!?
J'ai du bol sur mon réseau ex-tutor : Je n'ai jamais vu de paquets zarbi sur le WAN.
Un appareil Technicolor Delivery Technologies Belgium NV (https://hwaddress.com/company/technicolor-delivery-technologies-belgium-nv/) à priori…Ils se disent pourtant "World leader in xDSL gateways" : https://www.technicolor-edegem.be/en/what-we-do
Un des Syno qui fuit semble appartenir à un universitaire en informatique… J'ai envoyé un petit mail l'université pour contacter la personne et l'informer de la fuite mDNS et NetBIOS…Respecte quand même l'article 8. UTILISATION DES SERVICES des CGV (https://www.k-net.fr/wp-content/uploads/2021/07/CGV_K-NET.pdf).
En revanche, il n'a pas de ports non sécurisés ouverts (ou visibles), seulement un site web public en http et https, donc normal d'y avoir accès.
Mais d'autres en revanche… Des cibles faciles :-[
Respecte quand même l'article 8. UTILISATION DES SERVICES des CGV (https://www.k-net.fr/wp-content/uploads/2021/07/CGV_K-NET.pdf).
Au sujet des CGV, l'article 9.2 NON-RESPECT DE LA DISPONIBILITÉ DES SERVICES devrait intéresser beaucoup de clients en souffrance ...
J'ai retrouvé une personne qui fuit et j'ai pu la contacter. C'est un routeur perso avec clonage MAC, et la config physique est bonne WAN -> routeur -> SWITCH/LAN.Quel détective, bravo.
Je vois avec elle pourquoi ça fuit et comment résoudre cela :)
Quel détective, bravo.
Si tu as le fin mot de cette histoire, raconte nous ça ici. Jusqu'à présent, on pensait que les routeurs perso étaient plus "civilisés" que les K-Box.
Rien de choquant, c'est simplement de l'unknown unicast, c'est le fonctionnement classique d'un réseau Ethernet quand une MAC n'est pas peuplée en FDB -> Flood sur tous les portsJe ne crois pas qu'on soit dans ce cas de figure. La MAC cible et l'IP cible du traffic que j'ai reçu correspondent bien à un autre client (dixit le service technique que je viens d'appeler).
Oui, genre un client qui aurait éteint sa box ? Du coup plus de résolution MAC et donc unknown unicast.Euh what? Les MAC des boxs sont pas en static? Donc il suffit d'éteindre sa box pour que les voisins récupèrent le traffic? Et si un des voisins spoofe la MAC, il se passe quoi? c'est pas un peu problématique?
Et non, on ne désactive pas l'unknown unicast, a moins d'être en ip statique, le flooding des paquets pour learn c'est le principe de base de tous les réseaux ethernet depuis que ça existe, même si il existe des mécanismes pour ne plus avoir à le faire en partie (notamment en EVPN)Ah ouais je suis confusé, je raisonnais L2/L3 (ARP), mais évidemment ça ne concerne pas les switchs. Néanmoins, je pensais que côté infra les MAC étaient en dur, pour éviter le flood et pour "sécuriser"?
Euh what? Les MAC des boxs sont pas en static? Donc il suffit d'éteindre sa box pour que les voisins récupèrent le traffic? Et si un des voisins spoofe la MAC, il se passe quoi? c'est pas un peu problématique?Non, tu as des mécanismes qui permettent d'éviter ça (MFF peuplé par DHCP Snooping) mais ça ne filtre que le trafic sortant des ONT, pas le trafic entrant
Petite précision: le traffic reçu entre 23h40 (plausible) et 4h55 (ça fait très matinal pour "rallumer" sa box quand même non? ;) )En tout cas elle était injoignable, pour quelle raison, ça c'est une autre histoire :)
Ah ouais je suis confusé, je raisonnais L2/L3 (ARP), mais évidemment ça ne concerne pas les switchs. Néanmoins, je pensais que côté infra les MAC étaient en dur, pour éviter le flood et pour "sécuriser"?
Non, tu as des mécanismes qui permettent d'éviter ça (MFF peuplé par DHCP Snooping) mais ça ne filtre que le trafic sortant des ONT, pas le trafic entrantOK donc pour prendre un exemple, si un abonné centralise chez lui des flux (e.g un monitoring, disons collectd par exemple qui passe tout en clair, mais ça pourrait être de la télésurveillance aussi) de plusieurs sites distants, et que pour une raison ou pour une autre, son routeur se déconnecte, tous ses voisins peuvent "écouter" les flux en question? Je suis surleculfié :) (et ça me renforce dans ma tendance paranoïaque à chiffrer au maximum mon trafic)
Non c'est impossible de maintenir une DB de plusieurs milliers de MAC sur chaque équipement traversant, on fait du DHCP Snooping pour n'autoriser dans le L2 que les MAC qui ont un lease DHCP valide, ça suffit pour faire le ménage
Pour compléter, si le mec :C'est plus clair, merci pour les détails :)
- force une IP statique : sa MAC n'est pas apprise via le LAN avec ARP mais via le DHCP snooping qui peuple la table au moment du lease. Donc le mec n'aura aucun trafic dans la tronche. Niqué.
- se met en DHCP avec une MAC spoofé du voisin : il n'aura aucun lease, car le DHCP snooping communique aussi le "circuit-id", càd l'interface concernée (l'arbre pon concerné et l'id de l'ONU/ONT). Et forcément j'attends une MAC très précise pour TON port et pas une autre, donc niqué.
Perso, on whiteliste seulement la mac déclarée dans le dossier client, comme ça que je me protège des techs qui inversent des boxs et des LAN abonnés qui fuient :)
OK donc pour prendre un exemple, si un abonné centralise chez lui des flux (e.g un monitoring, disons collectd par exemple qui passe tout en clair, mais ça pourrait être de la télésurveillance aussi) de plusieurs sites distants, et que pour une raison ou pour une autre, son routeur se déconnecte, tous ses voisins peuvent "écouter" les flux en question? Je suis surleculfié :) (et ça me renforce dans ma tendance paranoïaque à chiffrer au maximum mon trafic)
Bah si tu envoies bêtement de l'UDP, oui (enfin je doute qu'Axione n'ait pas mis de limite a quelques dixièmes de % des interfaces pour l'UU.Thanks. Je me coucherai moins bête ce soir ;)
Si c'est du TCP non, la session ne s'établira pas.
Sachant que normalement tu as un timeout sur ARP, typiquement chez nous c'est 5 minutes, mais je sais que K-Net avait déjà trafiqué ça par le passé
Du coup j'ai pris la tête à "Mikaël" pour rien ;D
Après, il faut garder du recul et la tête froide. Ce ne sont pas ces problèmes qui sont dommageables à KNet car c'est un FAI qui marchait très bien avant, même avec ces écueilles. Comment font les autres FAI en collecte activée ? Ils semblent ne pas avoir ces soucis que vous mettez pourtant en avant chez knet.Je suis parfaitement d'accord, et c'est pour ça que j'ai exprimé un regret. Néanmoins, dans la mesure où j'ai été fibré le 13 et (soit-disant) "activé" le 16, et qu'on est le 28 et que ça ne fonctionne toujours pas, j'essaye par mes modestes moyens d'aider à la résolution d'un problème qui ne "devrait pas exister" (sur mes autres abos K-net/Axione j'ai toujours été activé en 48h max). Si ça marchait, je ne me serais jamais penché sur ce sujet. J'ajoute qu'à chaque fois que j'appelle c'est "oui oui on remonte l'info aux ingés réseaux mais ils ne regarderont pas avant la semaine prochaine". De semaine en semaine le temps passe, et ça c'est moyen.
Vous ne vous en rendez pas compte, mais en rentrant trop dans les détails et en faisant monter la mayonnaise sur ça (chaque jour je vois des topics sur knet ultra spécifiques remonter, que google apprécie), vous risquez d'obtenir l'effet inverse à celui recherché et de les plomber encore plus.
Après, il faut garder du recul et la tête froide. Ce ne sont pas ces problèmes qui sont dommageables à KNet car c'est un FAI qui marchait très bien avant, même avec ces écueilles. Comment font les autres FAI en collecte activée ? Ils semblent ne pas avoir ces soucis que vous mettez pourtant en avant chez knet.Et que fait donc le nouveau directeur kom? ::)
Vous ne vous en rendez pas compte, mais en rentrant trop dans les détails et en faisant monter la mayonnaise sur ça (chaque jour je vois des topics sur knet ultra spécifiques remonter, que google apprécie), vous risquez d'obtenir l'effet inverse à celui recherché et de les plomber encore plus.
Et que fait donc le nouveau directeur kom? ::)
Là est le tout le problème : même le patron vaque à d'autres occupations (notamment politique, il est candidat aux prochaines élections). Sauf que c'est maintenant que ça se passe. Je sais pas pour vous, mais quand c'était la merde chez nous, j'avais les boss sur le dos tout le temps, ils sont là, présents, et je dois rendre compte.
Tout le monde peste contre le serveur vocal et son raccrochage après 1h... franchement refaire un SVI en une journée c'est torché. Sur les RS, la dernière publication c'est la promo de Noel. Pareil pour les nouvelles offres qui devaient sortir : pourquoi ne pas les sortir maintenant ? Car payer un supplément pour appeler des mobiles en 2022...
Idem en TV, pourquoi Knet ne s'est postionné pour la reprise de FranceTV Sport 4K ? Le montant des droits TV est très accessible pour un petit opérateur. Ca aurait apporté un gros plus par rapport aux gros opérateurs.
Ce sont ces problèmes qu'il faut régler et ces opportunités qu'il faut saisir. Toutes les broutilles techniques style box qui fuit, honnêtement on s'en fout, c'était le cas avant ,ça tournait, et ça tournera aussi après. Si ça peut vous rassurer, je suis pas parfait, j'ai aussi des fuites, et pourtant, on est en croissance.
Ce qui compte maintenant c'est développer les services, recruter des prospects, fidéliser les abonnés actuels. C'est ça qui fait tourner une boite et je ne peux que souhaiter que knet se resaisisse vite.
Le 14 est stable, en tous cas pour les routeurs perso. Pour les K-Box par contre, c'est une collecte à risque… Après, je ne sais pas ce qu'il en est ; on voit peu de calvadosiens se plaindre en ce moment.
Ce sont ces problèmes qu'il faut régler et ces opportunités qu'il faut saisir. Toutes les broutilles techniques style box qui fuit, honnêtement on s'en fout, c'était le cas avant ,ça tournait, et ça tournera aussi après. Si ça peut vous rassurer, je suis pas parfait, j'ai aussi des fuites, et pourtant, on est en croissance.Je me permets de commenter juste sur ce point : non, on ne s'en moque pas car :
Là est le tout le problème : même le patron vaque à d'autres occupations (notamment politique, il est candidat aux prochaines élections). Sauf que c'est maintenant que ça se passe. Je sais pas pour vous, mais quand c'était la merde chez nous, j'avais les boss sur le dos tout le temps, ils sont là, présents, et je dois rendre compte.Oui clairement on se demande si la plante n'est pas en train de pourrir par la tête. Perso j'ai l'impression qu'on pourrait écrire un bouquin de management "comment planter une boîte en 10 leçons, par fbknet". C'est pas top :P
Tout le monde peste contre le serveur vocal et son raccrochage après 1h...Parfois il plante et raccroche plus vite que ça: semaine dernière, en position 5 après 20mn, pouf "tous nos opérateurs sont OQP". Illico je rappelle et je me trouve en 1 ;D
Petit bilan (collecte 14) :Vive OpenWRT (ok je sors ;P)
L'une est une MAC clonée (pas une K-Box), et le client travaille activement sur ce problème ; apparemment, le routeur perso (TP-Link) répond à des requêtes mDNS (normales) qu'il reçoit depuis le LAN, mais au lieu de répondre vers le LAN, il le fait vers le WAN… Problème apparemment existant dans des firmwares officiels TP-Link ; aucun contrôle sur l'interface du routeur.
L'autre, je la soupçonne aussi d'être une MAC clonée et probablement un routeur Synology (même comportement mDNS et NetBIOS).
Pour mDNS de mes recherches vite fait en mettant << mDNS tp link to Wan >> c'est apparemment des ChromeCast, Airplay et autres systèmes multimédia tel des Android TV et autres OS Tv qui polluent le réseau à faire des requêtes continues.Je viens de regarder les multicasts d'un Chromecast chez moi. L'adresse multicast utilisée pour mdns est bien 224.0.0.251, qui est dans le bloc "local subnetwork". Ca n'a donc pas à traverser un routeur.
Demande à ceux qui fuient de débrancher leur matos NAS/Plex/Tv connectée et autre Cast pour voir ;)
Je viens de regarder les multicasts d'un Chromecast chez moi. L'adresse multicast utilisée pour mdns est bien 224.0.0.251, qui est dans le bloc "local subnetwork". Ca n'a donc pas à traverser un routeur.
Celà dit, contrairement à certains équipements qui envoient ce genre de paquets avec un TTL à 1, Chromecast utilise un TTL à 255.
Là est le tout le problème : même le patron vaque à d'autres occupations (notamment politique, il est candidat aux prochaines élections).
Sérieux il s'est réellement présenté ?Sérieux: https://www.ouest-france.fr/elections/resultats/ain/3eme-circonscription/
Sérieux il s'est réellement présenté ?
C'est très bien de s'engager.J'ai déjà donné mon avis sur ses chances de succès ici (https://lafibre.info/k-net-internet/plus-de-connexion-mais-voyants-verts/msg951927/#msg951927)
J'espère juste qu'il n'a pas laisser la direction complète au fameux CTO!
Je n'ai toujours pas de téléphone...
Sur Covage 74 (ex tutor), j'ai la chance de ne voir aucun paquet qui ne m'est pas destiné!
0 ARP
0 DHCP4
0 en broadcast.
J'en suis presque à me demander si je regarde comme il faut avec Wireshark et le port mirroring!
Je pense que ta collecte est propre… Comme celle de pju91 et une majorité de collectes en fait.Ou bien ton port mirroring n'a pas fonctionné. En ce qui me concerne, je n'avais pas réussi sur ma K-Box (OK dans le panel, mais rien sur le port LAN supposé miroir du port WAN). J'avais dû brancher l'analyseur directement sur l'ONT pour vérifier que c'était "propre".
Dans le 14, je vois certains ARP, mais pas tous, je vois des Reply mais pas les Request, ou l'inverse…La logique voudrait que tu voies tous les ARP requests (en broadcast) mais que tu ne voies pas les replies (en unicast), sauf les "gratuitous ARP" (en broadcast), facilement reconnaissables (même IP source et dest).
Le problème est que Covage et K-Net sont tous deux fautifs (K-Net portant la responsabilité des Icotera défectueuses, et Covage portant la responsabilité du manque d'étanchéité de la collecte).L'absence de réaction de Covage est assez incompréhensible, d'autant plus qu'ils font maintenant l'objet d'une plainte (http://=https://www.universfreebox.com/article/526946/malfacons-dans-la-fibre-pour-la-premiere-fois-une-collectivite-traine-les-operateurs-en-justice) par Paris-Saclay.
Résultat, pendant longtemps (et encore aujourd'hui), ils se rejettent la balle, disant que si l'autre résout sa part du problème, alors la totalité du problème est résolue (si K-Net n'a plus de problème de K-Box, alors plus de problème [visible] pour les clients ; si Covage résout son manque d'étanchéité, alors peu importe si les K-Box fuient, cela n'aura plus de conséquence…).
Mais en réalité, les deux doivent arranger leur part du problème !C'est en priorité le problème de la collecte qu'il faudrait régler, puisque tu constates que des équipements autres que K-Box se comportent mal.
Une box qui a ces problèmes n'est pas une bonne chose, et une collecte qui n'est pas étanche n'en est pas une non plus (même en mettant de côté les K-Box, je vois plein de paquets mDNS, NetBIOS et autres venant de routeurs perso, etc…)
K-Net va à priori remplacer les K-Box petit à petit (rien de clair ni d'officiel cependant).Mouais ... Si c'est uniquement source = FB, ça reste à voir.
La logique voudrait que tu voies tous les ARP requests (en broadcast) mais que tu ne voies pas les replies (en unicast), sauf les "gratuitous ARP" (en broadcast), facilement reconnaissables (même IP source et dest).Oui et non…
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnnevvv -r merged.pcap not broadcast | sort | uniq
reading from file merged.pcap, link-type EN10MB (Ethernet)
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 46Cela signifie que tous les autres paquets ARP (Request and Reply) que j'ai vu sont en broadcast.root@HERMES:/tmp/mnt/sda1$ tcpdump -tnnevvv -r merged.pcap arp[6:2] == 2 | sort | uniq
reading from file merged.pcap, link-type EN10MB (Ethernet)
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
00:90:7f:a6:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 185.4.76.xx is-at 00:90:7f:a6:xx:xx, length 46
04:d5:90:49:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 2.59.237.xx is-at 04:d5:90:49:xx:xx, length 46
90:6c:ac:84:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 2.59.238.xx is-at 90:6c:ac:84:xx:xx, length 46
e0:23:ff:6d:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 185.238.4.xx is-at e0:23:ff:6d:xx:xx, length 46
e8:1c:ba:36:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 2.59.238.xx is-at e8:1c:ba:36:xx:xx, length 46
e8:ed:d6:3b:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 45.83.230.xx is-at e8:ed:d6:3b:xx:xx, length 46Donc peut-être des clients assez proches physiquement (sur un même switch au NRO par exemple), ou simplement peu de Reply gratuitous en broadcast si ce que je vois en sont.root@HERMES:/tmp/mnt/sda1$ tcpdump -tnneq -r merged.pcap arp[6:2] == 1 | sort | uniq | wc -l
reading from file merged.pcap, link-type EN10MB (Ethernet)
143
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnneq -r merged.pcap | sort | uniq | wc -l
reading from file merged.pcap, link-type EN10MB (Ethernet)
150root@HERMES:/tmp/mnt/sda1$ tcpdump -tnneq -r merged.pcap | wc -l
reading from file merged.pcap, link-type EN10MB (Ethernet)
59132L'absence de réaction de Covage est assez incompréhensible, d'autant plus qu'ils font maintenant l'objet d'une plainte (http://=https://www.universfreebox.com/article/526946/malfacons-dans-la-fibre-pour-la-premiere-fois-une-collectivite-traine-les-operateurs-en-justice) par Paris-Saclay.C'est en priorité le problème de la collecte qu'il faudrait régler, puisque tu constates que des équipements autres que K-Box se comportent mal.
Je suis toujours affecté par cette panne désormais récurrente, bientôt ce sera 2 jours de coupure par semaine, pour une fibre pro c'est le top franchement ... Avec bien évidemment aucun suivi, aucune communication ni rien !
Personnellement, je les supporte jusqu'à début Juillet car pas d'autre choix suite à un soucis d'adresses, mais après la résolution du soucis d'adresse, c'est ciao !
Et oui du coup Bolemo tu disais qu'il y avait moins de plaintes dans le 14, je pense juste que les gens sont fatigués de la situation tout comme moi..
En revanche, merci pour ton suivi des incidents a chaque fois c'est vraiment gentil de nous tenir informer !
Oui aussi, parce que si je vois des Request sans forcément voir les Reply, et des reply sans forcément voir les Request, ça peut s'expliquer sur les Reply son spontanés (gratuitous) sans répondre à un Request.Les ARP replies en broadcast qualifiés de "gratuits" (non sollicités) sont a priori utilisés pour la prévention de la duplication d'adresse IP, voir RFC 5227 (https://datatracker.ietf.org/doc/html/rfc5227). Ils doivent avoir la même IP en source et en destination, ce qu'on ne peut pas voir sur ton tcpdump.
Les ARP replies en broadcast qualifiés de "gratuits" (non sollicités) sont a priori utilisés pour la prévention de la duplication d'adresse IP, voir RFC 5227 (https://datatracker.ietf.org/doc/html/rfc5227). Ils doivent avoir la même IP en source et en destination, ce qu'on ne peut pas voir sur ton tcpdump.
De même les "requests" que tu vois sont peut-être des "ARP announcements", plutôt que des vraies "requests". Dans ce cas, ils doivent également avoir la même adresse IP source et destination.
En ce cas, je ne vois pas de paquets gratuitous Reply.En soi, ça n'est pas surprenant, c'est plutôt sur LAN que ça peut se trouver. Mais avec les fuites ...
Et je vois bien quelques announcements who-has AA:BB:CC:DD tell AA:BB:CC:DD, mais c'est une minorité, la plupart sont des Request.Les "announcements" comme les "requests" sont du même type de paquet ARP ( opcode=1).
En soi, ça n'est pas surprenant, c'est plutôt sur LAN que ça peut se trouver. Mais avec les fuites ...Les "announcements" comme les "requests" sont du même type de paquet ARP ( opcode=1).
Ou bien ton port mirroring n'a pas fonctionné. En ce qui me concerne, je n'avais pas réussi sur ma K-Box (OK dans le panel, mais rien sur le port LAN supposé miroir du port WAN). J'avais dû brancher l'analyseur directement sur l'ONT pour vérifier que c'était "propre".A priori, le port mirroring marche avec mon switch.
A priori, le port mirroring marche avec mon switch.
Je vois bien les paquets wan qui vienne de la passerelle Covage-K-net destiné à mon IP publique (et en sens inverse).
Par contre 0 ARP (sauf mon IP et la passerelle Covage), DHCP discover, broadcast en général.
Toujours là… FB ne doit pas trop avoir le temps de faire du service avec sa campagne électorale…
Mail envoyé au NOC, on verra bien.
<noc@kwaoo.net>: host 178.250.209.46[178.250.209.46] said: 550 5.1.1
<noc@kwaoo.net> User doesn't exist: noc@kwaoo.net (in reply to RCPT TO
command)
Mail NOC KO :o :C'est d'autant plus fâcheux que c'est l'adresse email de contact qui ressort dans whois ou les informations de peering. >:(
C'est d'autant plus fâcheux que c'est l'adresse email de contact qui ressort dans whois ou les informations de peering. >:(
Oui, et je crains que cela signifie que personne chez K-Net n'est au courant du problème de spam (toujours) en cours.:(
Avant, un tweet à FB et ça bougeait au plus tard le lendemain. Dans les cas les plus graves, un mail au NOC, et même sens réponse, ça bougeait…
Mais là, plus personne que je peux contacter directement… Et je n'ai pas forcément envie d'attendre une heure au tel. pour expliquer ma supervision à l'opérateur téléphonique.
Bref, la communication ne s'améliore pas, ça empire.
Bref, la communication ne s'améliore pas, ça empire.Je crois malheureusement qu'il n'y a pas que la communication. Mon nouveau raccordement (13 mai) n'est toujours pas actif (bien qu'il ait été activé par Axione le 16). Pas de réponse du DHCP. J'appelle tous les jours, ça n'avance pas. Je sens que je vais finalement baisser les bras moi aussi.
Je crois malheureusement qu'il n'y a pas que la communication. Mon nouveau raccordement (13 mai) n'est toujours pas actif (bien qu'il ait été activé par Axione le 16). Pas de réponse du DHCP. J'appelle tous les jours, ça n'avance pas. Je sens que je vais finalement baisser les bras moi aussi.
Je n'y suis pas encore, mais je vois se rapprocher ma limite de tolérance aussi.Comme disait un célèbre commentateur foot :
On arrive à un moment critique… Je donne une chance à K-Net, mais jusqu'à un certain point.Ils m'ont finalement rappelé cette aprèm, une IP m'a enfin été attribuée (ils me l'ont communiquée)! Pratiquement 3 semaines après le raccordement et alors que je leur ai dit tous les jours le symptôme exact (pas de bail DHCP donc IP probablement pas attribuée). Et la cerise, il faut que je reboote l'ONT pour que ça marche, le seul truc que je ne peux pas faire à distance :P (le raccordement en question n'est pas chez moi)
FB n'a clairement plus la tête dans K-Net, ni la motivation / force motrice des débuts ; ça peut se comprendre, mais il était le seul à communiquer un peu…
L'infra de K-Net s'améliore (très) doucement, mais la communication déjà très endommagés s'effrite… l'opacité devient un trait de caractère, et je n'aime pas ça du tout (c'est même triste) ; K-Net devient une boîte noire.
Je n'y suis pas encore, mais je vois se rapprocher ma limite de tolérance aussi.
@blarglibloup : ils doivent réaliser, s'ils lisent ce forum, que les plus fidèles et défenseurs de K-Net ont une patience et tolérance très élevées, mais pas infinies.Je sais pas encore si c'est vraiment résolu: faut que j'attende de faire clic-clac sur l'ONT d'abord ;P
Qu'elle qu'en soit la raison, bonne nouvelle qu'ils t'aient finalement contacté et résolu ton problème :)
Je sais pas encore si c'est vraiment résolu: faut que j'attende de faire clic-clac sur l'ONT d'abord ;P
Altitude doit avoir un ACL basé sur le numéro de série de l'ONT pour nécessiter un reboot après un changement d'IP.C'est Axione. J'imagine qu'une maj de la conf de l'ONT est nécessaire, mais je ne sais pas exactement pourquoi. Un des experts locaux pourra peut-être nous éclairer ;)
C'est Axione. J'imagine qu'une maj de la conf de l'ONT est nécessaire, mais je ne sais pas exactement pourquoi. Un des experts locaux pourra peut-être nous éclairer ;)
C'est clairement une honte, c'est inadmissible au prix qu'on paye ! Je perds réellement patience face à des incapables de leur genre !
Il n'y a aucun moyen de les attaquer ou les poursuivre de manière judiciaire ?
Car si il y a des ficelles à tirer pour le faire, je vais clairement le faire.
Faisons pression sur le département du Calvados !N'hesite pas à poster ici
Plus on sera nombreux, mieux ce sera…
Et le Département peux faire pression sur Altitude Infra.
Si vous êtes pour, signalez-vous ici.
N'hesite pas à poster ici
https://www.facebook.com/groups/354338762057554
https://www.facebook.com/groups/227909849109397
Tu auras surement beaucoup de monde.
Le problème est que Covage et K-Net sont tous deux fautifs (K-Net portant la responsabilité des Icotera défectueuses, et Covage portant la responsabilité du manque d'étanchéité de la collecte).
tracert voisin
Détermination de l’itinéraire vers voisin
avec un maximum de 30 sauts :
1 1 ms 1 ms 4 ms k-box.home [192.168.1.1]
2 2 ms 2 ms 2 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 11 ms 12 ms 11 ms k-net.covage [10.2.0.5]
5 11 ms 11 ms 11 ms collecte.covage [10.2.0.4]
6 22 ms 23 ms 22 ms labalme.covage [10.2.0.178]
7 22 ms 22 ms 22 ms voisin
Itinéraire déterminé.
Pour ksys, je ne sais pas.
Pour knet, tout paquet est forwardé à Paris, même si sur le même sous réseau.Code: [Sélectionner]tracert voisin
Détermination de l’itinéraire vers voisin
avec un maximum de 30 sauts :
1 1 ms 1 ms 4 ms k-box.home [192.168.1.1]
2 2 ms 2 ms 2 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 11 ms 12 ms 11 ms k-net.covage [10.2.0.5]
5 11 ms 11 ms 11 ms collecte.covage [10.2.0.4]
6 22 ms 23 ms 22 ms labalme.covage [10.2.0.178]
7 22 ms 22 ms 22 ms voisin
Itinéraire déterminé.
L'OI en offre active n'est censé que collecter les paquets et les transmettre (et inversement) au routeur de collecte du FAI (10.2.0.5 dans notre cas) qui lui décide quoi faire.Du coup, je voulais vérifier qu'en région parisienne, c'était pareil, mais j'ai une petite bizarrerie :
Exception pour l'ACL DHCP v4 et v6 qui se fait avec un relais chez l'OI (pour les ACL), le serveur étant chez le FAI.
En aucun cas, les clients ne sont censé se voir avant le routeur du FAI.
La bonne pratique : une collecte totalement étanche entre clients.
$ ping -c 1 185.251.161.$oc4
PING 185.251.161.93 (185.251.161.93) 56(84) bytes of data.
64 bytes from 185.251.161.93: icmp_seq=1 ttl=56 time=9.88 ms
--- 185.251.161.93 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.879/9.879/9.879/0.000 ms
$ traceroute -q 1 185.251.161.$oc4|sed "s/$oc4/XX/g"
traceroute to 185.251.161.XX (185.251.161.XX), 30 hops max, 60 byte packets
1 box (192.168.1.1) 11.220 ms
2 10.2.0.143 (10.2.0.143) 11.139 ms
3 *
4 10.2.0.5 (10.2.0.5) 11.0XX ms
5 10.2.0.4 (10.2.0.4) 11.063 ms
6 122.138.24.109.rev.sfr.net (109.24.138.122) 11.031 ms
7 123.138.24.109.rev.sfr.net (109.24.138.123) 11.024 ms
8 10.2.0.174 (10.2.0.174) 13.036 ms
9 *
10 XX-161-251-185.ftth.cust.kwaoo.net (185.251.161.XX) 15.923 ms
C'est quoi ce passage chez SFR ?$ whois 185.251.160.0|grep -E "route|descr|origin|role"
descr: Knet FAI Range
role: K-NET NOC
route: 185.251.160.0/22
descr: K-NET
origin: AS24904
$ whois 109.24.138.122|grep -E "route|descr|origin|role"
descr: Infra misc.
role: SFR Legal Contact
role: SFR Tech Contact (formerly Neuf Cegetel / LDCOM Networks)
route: 109.0.0.0/11
descr: LDCOM-NET
origin: AS15557
Du coup, je voulais vérifier qu'en région parisienne, c'était pareil, mais j'ai une petite bizarrerie :
Après un "ping sweep", je localise une IP sur le même segment 185.251.160/22 que moi que je peux pinger. J'ai un comportement similaire avec une autre adresse du même bloc /22.Code: [Sélectionner]$ ping -c 1 185.251.161.$oc4C'est quoi ce passage chez SFR ?
PING 185.251.161.93 (185.251.161.93) 56(84) bytes of data.
64 bytes from 185.251.161.93: icmp_seq=1 ttl=56 time=9.88 ms
--- 185.251.161.93 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.879/9.879/9.879/0.000 ms
$ traceroute -q 1 185.251.161.$oc4|sed "s/$oc4/XX/g"
traceroute to 185.251.161.XX (185.251.161.XX), 30 hops max, 60 byte packets
1 box (192.168.1.1) 11.220 ms
2 10.2.0.143 (10.2.0.143) 11.139 ms
3 *
4 10.2.0.5 (10.2.0.5) 11.0XX ms
5 10.2.0.4 (10.2.0.4) 11.063 ms
6 122.138.24.109.rev.sfr.net (109.24.138.122) 11.031 ms
7 123.138.24.109.rev.sfr.net (109.24.138.123) 11.024 ms
8 10.2.0.174 (10.2.0.174) 13.036 ms
9 *
10 XX-161-251-185.ftth.cust.kwaoo.net (185.251.161.XX) 15.923 ms
???Code: [Sélectionner]$ whois 185.251.160.0|grep -E "route|descr|origin|role"
descr: Knet FAI Range
role: K-NET NOC
route: 185.251.160.0/22
descr: K-NET
origin: AS24904
$ whois 109.24.138.122|grep -E "route|descr|origin|role"
descr: Infra misc.
role: SFR Legal Contact
role: SFR Tech Contact (formerly Neuf Cegetel / LDCOM Networks)
route: 109.0.0.0/11
descr: LDCOM-NET
origin: AS15557
Tu passes bien par la collecte K-Net (hop 4), puis tu retournes vers le client, en passant par Covage (hop 5) puis des routeurs XP-Fibre (hop 6 à 9), appartenant à SFR comme le rappel Steph.Ce qui me surprend c'est que :
Covage a été racheté par sfr OI, d’où des passages par le réseau SFR.Oui et Non. La marque Covage appartient à Altitude. Mais certains réseaux sont aller chez SFR au lieu de Covage.
Ce qui me surprend c'est que :Pas d'XP fibre dans mon coin. Sur Paris, si, mais ne me demande pas où ! ;)
- Steph n'observe pas ça
- le réseau de l'OI dans mon coin existait avant le rachat de Covage par SFR, je pensais avoir une route plus "directe"
J'ai visité le POP de Meythet d'ailleurs, et ben c'est un miracle que ce réseau fonctionne, croyez moi, c'est vraiment la septième compagnie...Pics! ;D
Je ne pense pas avoir le droit de les poster, mais disons que ça ressemble à ça :
(https://pix.milkywan.fr/w9t5M2N0.jpg)
C'est quoi la colle rouge sur le dessus des fibres?Du lubrifiant :D
Bon il faut faire quoi pour que les incompétents de chez K-Net se réveillent et n'empêchent pas des gens de travailler dans des conditions normales ?Si tu lis (bon courage, c'est long) l'intégralité des échanges de ce sujet (https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg942102/#msg942102), tu constateras qu'avec bolemo et d'autres, on a effectivement tenté par de nombreux moyens de faire avancer les choses, notamment :
Il faut aller manifester directement devant le siège ou c'est possible d'avoir un services client normal...
Côté K-Net, on a utilisé plus ou moins toutes nos cartouches… On offre des solutions, on facilite, mais c'est totalement ignoré… Je suis à court d'idées (et de solutions de mon côté)
Côté OI, je vais contacter le Département (quand ça sera plus calme, période chargé pour moi avec le D-Day ici…)
Tu es encore chez K-Net?? tu es bien courageux moi j'ai lâché l'affaire depuis mars..
Sinon tu peux aussi changer pour un vrai FAI qui fait du v6 de la téléphonie de la TV le tout sans coupures ...... j'en compte déjà 4 mini vu d'ici.
... Oui, pour moi, tout fonctionne nickel… Pas de coupures, débits max, téléphone ok, TV ok je pense (je n'utilise pas le flux K-Net de toute façon, mais quand je test, ça fonctionne) ...Pareil pour moi. Je profite de ma dernière semaine de K-Net avant déménagement et avant de passer en ADSL avec un débit ridiculement bas.
Ils m'ont finalement rappelé cette aprèm, une IP m'a enfin été attribuée (ils me l'ont communiquée)! Pratiquement 3 semaines après le raccordement et alors que je leur ai dit tous les jours le symptôme exact (pas de bail DHCP donc IP probablement pas attribuée). Et la cerise, il faut que je reboote l'ONT pour que ça marche, le seul truc que je ne peux pas faire à distance :P (le raccordement en question n'est pas chez moi)Donc je me réponds à moi-même, évidemment le reboot de l'ONT n'a rien changé. Donc je crois que là on va passer à l'étape suivante.
Donc je me réponds à moi-même, évidemment le reboot de l'ONT n'a rien changé. Donc je crois que là on va passer à l'étape suivante.
En attendant je reçois toujours de l'UU
Edit: le SAV m'a rappelé, ouverture d'un ticket auprès de l'OI pour reconfig de l'ONT. Apparemment le problème touche plusieurs régions et je ne suis pas le seul.
(…)
J’accuse bonne réception de votre message et vous en remercie.
En effet, Altitude Infra Calvados est en train de mener les actions permettant de solutionner la problématique que vous nous remontez.
Au courant du mois de juillet 2022, l’ensemble des actions auront été menées et vous ne rencontrerez plus ce problème.
N’hésitez pas à revenir vers moi si ce n’était pas le cas.
(…)
Ah d'ailleurs faut que je réponde à ton dernier mail.. je fais ça asap :)
Edit: le SAV m'a rappelé, ouverture d'un ticket auprès de l'OI pour reconfig de l'ONT. Apparemment le problème touche plusieurs régions et je ne suis pas le seul.Juste pour rire: ça fait maintenant 1 mois et 1 jour que j'ai été fibré, et ça ne fonctionne toujours pas. Un tel niveau d'efficacité, ça mérite une médaille :P
Par ailleurs, message reçu il y a 30 minutes (tombé dans mes indésirables que je vérifie, heureusement) de la part d'Altitude Infra :
Extrait :
Donc les fuites, ça va être résolu :)
Joli ! Ils ont pris des switchs Pampers ?
De mon point de vue, je vois un avion sans capitaine, qui vole encore à peu près correctement, avec encore un équipage qui colmate les dégâts, mais dont la radio est silencieuse, ne répond plus aux appels radio, ne communique plus de plan de vol…
Par contre, il y a un truc qui me sidère : même investisseur, aucune communication ? C'est juste fou. Donc tu n'as aucune idée de la perte d'abonné, à part ici ?
Ouais, et en plus du merci, bravo et respect, même si je ne suis absolument pas concerné. C'est juste hallucinant de voir le temps que tu as pris pour debug cette histoire, et le silence de l'autre côté.
Bah y a plus aucune communication, c'est tout.
J'ai été à St-Genis plusieurs fois, ils étaient contents de me voir parce que j'étais le seul client qui ne venait pas pour râler mais pour les encourager, je leur ai dit ce que j'ai aussi écrit sur ce forum : putain, *communiquez* !
Au fil des semaines, j'ai compris qu'il y avait de la désillusion même chez le personnel de l'agence.
Je ne devrais peut être pas le dire ici, mais quand j'ai résilié, j'ai laissé à Saint-Genis une lettre personnelle pour Frank Bisetti ; ce qui m'a été répondu : "bah alors on va la déposer chez lui, on n'est pas certains qu'il sache encore où est l'agence".
C'est con et dommage, et moi aussi j'ai du mal à reconnaître le mec dynamique rencontré dans un forum, qui lançait K-Sys il y a 10(?) ans.
Sérieux il s'est réellement présenté ?Bon, il faut dire que son résultat a été à la mesure du dynamisme de sa campagne.
Mais nannnn, dites-moi que je rêve ;D ;D ;D
Tu sais quelestétait son prgramme, au moins ? Parce que "la piraterie n'est jamais finie", ça veut juste rien dire ???
Enfin, on n'est pas là pour causer politique, mais c'est pas comme si les tous les autres avaient un programme particulièrement lisible cette année, que ce soit en avril ou maintenant...
En tout cas, on ne pourra jamais t'enlever ta patience et ta persévérance dans tout ce que tu as fait jusque là. Même si tu n'as aucun merci de leur part, tu l'as du mien : merci !
Par contre, il y a un truc qui me sidère : même investisseur, aucune communication ? C'est juste fou. Donc tu n'as aucune idée de la perte d'abonné, à part ici ?
Qu'est ce qui a été signé à la base ? Car si c'est juste un contrat qui dit "5k€ contre un service gratuit", effectivement ça ne te donne aucun droit de regard à priori et là tu as peut-être manqué de vigilence.
C'est aussi là le revers du "être indépendant" : il n'y a personne pour dire au capitaine "euh, tiens là tu fais de la merde, corrige stp".
En gros, c'est un prêt que ce type de clients font à K-Net, et les intérêts sont payés sous forme de gratuité de l'abonnement. La combien (assez intelligente je trouve ; j'aimais cette créativité chez K-Net) revient à un équivalent profit de presque 9% net pour le client (très exactement 8,89% dans mon cas : il faudrait que je place la somme à 8,89% net pour que les intérêts payent exactement mon abonnement).FB affiche sur son profil twitter : emprunte à 8% pour rester indépendant
Je ne cherchais pas non plus à avoir un droit de regard ; c'était pour moi une forme de placement originale.
FB affiche sur son profil twitter : emprunte à 8% pour rester indépendant
C'est le mécanisme que tu décris.
Non, il n'y a aucune base contractuelle pour qu'officiellement K-Net me fournisse la moindre info.Hmm, j'aurais été très curieux de voir les termes exacts du contrat parce qu'il y a pas mal de choses qui m'étonnent, pour dire le moins.
C'est FB qui utilise la mention de « client investisseur » qui n'est pas la plus appropriée je pense, et je suis fautif de l'avoir employé.
Le contrat est simple : on dépose chez K-Net une somme dont 8% représentent le coût d'un abonnement annuel (calcul tenant compte de la TVA et autres ajustements). Tant que l'on y laisse cet argent, on ne paye pas d'abonnement (mais les frais téléphoniques si appels spéciaux etc… sont bien sûr chargés). On peut retirer cet argent dans sa totalité (sans intérêts ni pertes) à tout moment, et repasser donc en abonnement classique.
En gros, c'est un prêt que ce type de clients font à K-Net, et les intérêts sont payés sous forme de gratuité de l'abonnement. La combien (assez intelligente je trouve ; j'aimais cette créativité chez K-Net) revient à un équivalent profit de presque 9% net pour le client (très exactement 8,89% dans mon cas : il faudrait que je place la somme à 8,89% net pour que les intérêts payent exactement mon abonnement).
Hmm, j'aurais été très curieux de voir les termes exacts du contrat parce qu'il y a pas mal de choses qui m'étonnent, pour dire le moins.
Je passe sur l'inclusion très discutable de la TVA dans le calcul, mais si je comprends bien il s'agit d'une sorte d'obligation (titre de dette) dont le coupon est payé en nature (abonnement gratuit). Fiscalement, c'est un truc amusant, pour lequel j'imagine que tu n'as jamais rien déclaré au fisc, ce qui pourrait un jour poser problème. Premier point.
2è point, sur un placement financier qui sert 8% d'intérêts, on considère souvent que les intérêts sont "réinvestis" et font donc eux-même des petits (principe des intérêts composés), ce qui n'est évidemment pas le cas ici; et donc le résultat au bout d'une période X n'est pas le même.
3è point, quand FB prétend qu'il se finance à 8%, c'est un très gros abus de langage qui ne reflette pas du tout la réalité du montage (comptablement je me demande comment ils traitent ça d'ailleurs). Ne serait-ce que parce que K-net ne "paye pas" la TVA, donc la dépense réelle pour eux est déjà moindre, ou le fait que in fine, ça ne "coûte" à la société que le coût marginal du raccordement, qui est bien entendu bien moindre que le coût facturé audit client: l'entreprise dégage une marge. Suivant les termes du contrat, il n'est même pas sûr qu'il s'agisse vraiment d'un emprunt.
Enfin le terme de "client investisseur" me semble assez galvaudé: un investisseur a certains droits (notamment l'accès aux éléments financiers et comptables de la société, une hiérarchie dans la liste des créanciers servis en cas de mise en liquidation, etc), et certains types d'investissements sont réservés à des "investisseurs professionnels" (c.f. réglementation MIFID - pas sûr que la capacité du client investisseur à "investir" ses 4800 balles ait été évaluée?).
Tout cela est peut-être "créatif" mais semble surtout très baroque et sujet à une certaine circonspection.
Mes 2 sioux
Je pense que ça a été bien ficelé, puisque c'est un système mise en place dès le début qui a du être bien étudié, et qui a surtout été populaire (enfin relativement, je pense qu'il n'y a jamais eu beaucoup de clients à vie) au début aussi.Mouais, ton exemple n'a rien à voir. En l'absence des éléments concrets pour me prononcer, je réserve mon jugement. Je te signale juste qu'un "placement" qui rapporte 8%, en numéraire ou en nature, est imposable :)
C'est comme l'installation à domicile, qui permet de bénéficier du crédit d'impôt d'aide à domicile via le réseau Stella et au final que ça ne coûte rien au client tout en soutenant des emplois.
Pour moi, le technicien n'est même pas entré chez moi. Je lui ai dit que tout était déjà fonctionnel depuis longtemps, que j'avais monté mes câbles fibre et ethernet au domicile, et avait mon LAN tout en place. J'ai signé le formulaire d'intervention à la portière de sa voiture, et il est reparti après avoir fait une courte causette. Je n'en avais pas besoin (mais il devait se présenter absolument pour respecter la loi), mais c'est un système sympa pour ceux qui ont besoin d'assistance à l'installation.
Ce sont des démarches créatives mais légales. J'aimais cette différence chez K-Net, qui cherchait des solutions originales, principalement en jouant sur des leviers fiscaux.
Mouais, ton exemple n'a rien à voir. En l'absence des éléments concrets pour me prononcer, je réserve mon jugement. Je te signale juste qu'un "placement" qui rapporte 8%, en numéraire ou en nature, est imposable :)
Je t'ai envoyé le contrat en MP.J'ai vu: c'est un bête contrat de vente. Tu n'es ni investisseur, ni prêteur (tu n'as aucun des droits qui s'y rattachent) et la société n'emprunte rien (et n'a aucune des obligations liées à un emprunt, et ne t'offre aucune des garanties habituelles, notamment celle d'être remboursé). Libre à chacun d'en tirer les conclusions sur la comm de FB, j'ai les miennes ;)
Ce n'est ni un prêt, ni un investissement, ni un placement, donc non imposable.
Tu verras.
J'ai vu: c'est un bête contrat de vente. Tu n'es ni investisseur, ni prêteur (tu n'as aucun des droits qui s'y rattachent) et la société n'emprunte rien (et n'a aucune des obligations liées à un emprunt, et ne t'offre aucune des garanties habituelles, notamment celle d'être remboursé). Libre à chacun d'en tirer les conclusions sur la comm de FB, j'ai les miennes ;)Tu comprends mieux le pourquoi du "Parti Pirate"? :)
Tu comprends mieux le pourquoi du "Parti Pirate"? :)
La mention "emprunte à 8% pour rester indépendant" sur son Twitter ne correspond pas à "l'abonnement à vie", mais à un prêt participatif sur 3 ans (je ne sais pas si c'est toujours d'actualité), qui est bien déclaré au fisc.
Tout cela est peut-être "créatif" mais semble surtout très baroque et sujet à une certaine circonspection.Je ne suis pas fiscaliste, juriste ou quoi que ce soit, mais je pense que ce n'est pas le seul modèle financier un peu baroque, comme tu dis, dans le monde des telecoms.
Je ne suis pas fiscaliste, juriste ou quoi que ce soit, mais je pense que ce n'est pas le seul modèle financier un peu baroque, comme tu dis, dans le monde des telecoms.
Le smartphone "offert" avec un abonnement de téléphone majoré, c'est aussi pas clair si c'est de la vente ou de l'abonnement.
La TV imposée sur un contrat de FAI, pour celui qui ne la regarde pas où qui aimerait la prendre ailleurs, c'est de la vente liée.
Même la "recharge" de crédit sur un téléphone portable à carte prépayé, qui "expire" après 15 jours, pour moi c'est de l'abonnement déguisé.
Ceci dit, le modèle d'"abonnement à vie" de K-Net me tentait bien à l'époque, et je pense que tout le monde y est gagnant...
Au final, c'est simple : le moteur de K-Net, c'était FB.
Bah oui, j'aurai été 20 mois en abonnement à vie : 800 euros d'abonnement « économisés » ainsi.
Pour avoir le même résultat, il aurait fallu que je place à presque 9% net et les intérêts auraient payé l'abonnement mensuel (intérêts non réinvestis, donc identique).
9% dans cette période, c'est dur à trouver ! Seuls les obligations et minibons de crowdfunding immobilier offrent ces taux, mais ils sont brut et avec risque de perte en capital (tout comme l'abonnement à vie d'ailleurs si K-Net fait faillite…).
Bref, je trouve que cela était astucieux et simple… Un moyen pour le client d'économiser et pour K-Net de se financer ou d'avoir une trésorerie.
mais qui avec le recul devient clair.
Les moteurs c'étaient plutôt Damien, GregoryLH, Jack et j'en oublie mais ceux-ci sont partis et force est de constater que le(s) remplaçant(s) ne sont pas à la hauteur.
En même temps, le remplaçant a déjà coulé une boite donc il a l'habitude ::)
edit
Ce n'est pas faute d'avoir prévenu et lancé l'alerte en décembre 2021 voire déjà avant. Mais peu de gens voulaient voir les choses en face.
Oui.
Ce que je voulais dire c'est que l'impulsion, le capitaine de K-Net, c'était FB (il tient la barre et la manette de commande du moteur).
Je pense que Damien, GregoryLH, Jack, VincentO2… ont du sentir qu'il n'y avait plus de vision (de capitaine), plus de direction, plus d'impulsion… Et ils sont parti pour cela (à quoi sert un moteur performant s'il n'est pas utilisé…)
Enfin, ils pourront confirmer ou non bien sûr, je ne parle évidemment pas en leur nom.
Bien sûr, ils étaient la force et l'efficacité du moteur, et leur travail et empreinte qu'ils ont donné à K-Net a été remarquable.
C'est assez intéressant Bolemo que tu dise que sa campagne aux législatives a été la goutte d'eau.
Sa vie privée a tjs été un problème pour K-Net dans le sens où il s'éparpillait trop et ne comprenait pas que ça pouvait nuire à l'image qu'il donnait sur son implication.
J'espère qu'il te lira et qu'il comprendra que sa stratégie à faire genre qu'il est ultra impliqué dans pleins de choses est contre productif.
C'est assez intéressant Bolemo que tu dise que sa campagne aux législatives a été la goutte d'eau.
Sa vie privée a tjs été un problème pour K-Net dans le sens où il s'éparpillait trop et ne comprenait pas que ça pouvait nuire à l'image qu'il donnait sur son implication.
J'espère qu'il te lira et qu'il comprendra que sa stratégie à faire genre qu'il est ultra impliqué dans pleins de choses est contre productif.
J'ai toujours aimé comprendre les choses, surtout avant de prendre une décision (j'aime prendre des décisions solides et ne pas être une girouette).Moi de même ...
Quand les problèmes sont devenus visibles (par le grand public) fin 2021, je ne suivais pas particulièrement l'activité sur le forum K-Net ou autre…
J'ai voulu me connecter sur le forum pour prendre des nouvelles de la communauté, et j'ai remarqué qu'il était en maintenance… Je suis donc venu voir ici et j'ai découvert les problèmes rencontrés par les autres clients (et les alertes de certains comme Optix).
Non seulement FB ne semble plus être intéressé par K-Net (consciemment ou non), mais son entourage ne provoque aucune émulation, et n'a absolument aucun réel intérêt pour K-Net. Tout repose sur FB, et il a abandonné.C'est triste à constater ; j'ai retrouvé nos échanges de mars, où tu avais encore de l'espoir et où je listais quelques urgences, dont aucune n'a été traitée :
C'est clairement voué à l'échec à moins d'un changement, ce que j'espérais encore il y a peu (et ça peut encore arriver), mais ça devient vraiment une histoire de foi ou de pari, et je ne suis pas là pour jouer, mais pour avoir un FAI original, solide, réactif et transparent… Comme Optix l'a dit, personne ne peut me reprocher de leur avoir laissé une chance, d'avoir essayé, d'avoir été fidèle.Je te comprends :'(
Et aujourd'hui, je n'ai pas de rancune envers FB ou K-Net ; je suis simplement triste de voir un FAI qui a encore des atouts se diriger dans une zone avec des iceberg, et un capitaine distrait, absent… Et un équipage qui ne prend (et ne peut pour un grand nombre) absolument aucune initiative. Bref, d'être témoin d'un gâchis qui pourrait être évité.J'ai eu des échanges téléphoniques plutôt agréables avec 2 personnes de K-Net cette semaine (au support technique et à l'administratif). J'ai senti de l'écoute, de la bienveillance, bien loin du sentiment de "panique à bord" qu'on pourrait imaginer. Je peux me tromper évidemment.
J'ai aussi beaucoup de sympathie pour les employés, qui doivent d'un côté gérer les clients frustrés et mécontents, et d'un autre voir leur compagnie prendre l'eau, sans pouvoir rien y faire. Comme l'équipage du Titanic quoi…
prélèvement autoTu peux le faire sur n'importe quelle banque pas besoins d'avoir Milkywan ;)
Perso la goutte d'eau ça pourrait bien être ce raccordement toujours pas opérationnel depuis le 13 mai.
Si MW arrive à mettre en place le prélèvement auto, je pourrais bien franchir le pas plus tôt que prévu :P
Ta banque sait pas programmer un versement ? Vu qu'il y a aucun coût variable lié au phone....J'ai pas qu'un seul abonnement concerné, plusieurs banques, donc un bordel à suivre. Si changement de tarif (par ces temps d'inflation) faut tout reprendre, risque d'incident de paiement etc. Le prélèvement auto c'est bien plus confortable. Rien à gérer.
C'est la course entre la venue de MW sur les RIP (et c'est pas simple vue les restructurations des OI) et les réparations de K-net qui trainent.C'est même plus simple d'arriver après que les autres aient essuyé les plâtres, que d'être le premier. Fable de la torture & cie. ;D
Et t'as changé d'IP?
NopeSteph, j'ai vu la coupure de bolemo et sa remontée (sur la même adresse) ce matin :
Ma faute, l'horloge de mon mini PC était à l'ouest.
Le status Monitoring est éteint en même temps que les fuites. C'est curieux non?
Je remarque aussi que l'adresse MAC de la passerelle infra a changé…Difficile de dire ce qui a changé sur l'infra AI. Tu vois qu'ils ont mis une autre passerelle, ça n'est donc pas qu'une question de reconfiguration des équipements pré-existants.
Difficile de dire ce qui a changé sur l'infra AI. Tu vois qu'ils ont mis une autre passerelle, ça n'est donc pas qu'une question de reconfiguration des équipements pré-existants.
Il faudrait, pour satisfaire notre curiosité intellectuelle et comprendre pourquoi ça a amélioré la situation sur ton réseau de collecte, que tu leur demandes en quoi a consisté cette intervention du 4 juillet au matin.
Ma longue coupure était du au fait que je n'autorise que la connexion vers le switch OI, et comme ils l'ont changé, j'interdisait le nouveau switch. J'ai du redémarrer hier mon routeur pour que mon script détecte la nouvelle adresse MAC.Aucun intérêt. Par définition il n'y a que ce switch qui te parle. Tu fatigues ton routeur avec des checks inutiles et tu te retrouveras à nouveau coupé au prochain changement de l'OI.
Aucun intérêt. Par définition il n'y a que ce switch qui te parle. Tu fatigues ton routeur avec des checks inutiles et tu te retrouveras à nouveau coupé au prochain changement de l'OI.
Vu le bazar qu'il y'avait sur la collecte je ne lui jetterai pas la pierre ^^Certes :)
J'avais mis cela en place, car ça me bloquait bien des trucs justement (les fuites dont la MAC source n'était pas celle de la passerelle). Peut-être inutile maintenant mais ça ne ralentit en rien mon routeur (simple règle ebtables) et sa charge CPU avec toutes mes règles (ebtables, iptables…), supervision… reste en dessous de 4%, et c'est aussi une sécurité de plus en cas de MitM (très peu probable on est d'accord).4% à plein débit? C'est quoi ton routeur? :)
Difficile de dire ce qui a changé sur l'infra AI. Tu vois qu'ils ont mis une autre passerelle, ça n'est donc pas qu'une question de reconfiguration des équipements pré-existants.
Il faudrait, pour satisfaire notre curiosité intellectuelle et comprendre pourquoi ça a amélioré la situation sur ton réseau de collecte, que tu leur demandes en quoi a consisté cette intervention du 4 juillet au matin.
J'avais mis cela en place, car ça me bloquait bien des trucs justement (les fuites dont la MAC source n'était pas celle de la passerelle). Peut-être inutile maintenant mais ça ne ralentit en rien mon routeur (simple règle ebtables) et sa charge CPU avec toutes mes règles (ebtables, iptables…), supervision… reste en dessous de 4%, et c'est aussi une sécurité de plus en cas de MitM (très peu probable on est d'accord).
(sur le câble y avait des crétins qui fouttaient du 220V sur le coax... je ne doute plus de rien sur la connerie dès qu'un truc est possible)Oui quand les voisins t'emmerdent avec la télé trop fort c'est une solution qui a fait ses preuves ;D
Pour ma règles ebtables (et plein d’autres iptables), ça ne me pose pas de problème, dès que j’ai réalisé que j’avais perdu la connexion, je suis allé sur le routeur en ssh, et j’ai identifié le problème de suite. Un redémarrage du routeur et voilà (mon script trouve tout seul la MAC au lancement).Reboot routeur à la mano possible uniquement quand tu es chez toi. Quant au script qui "trouve tout seul la MAC", il est encore plus inutile en cas de MitM :)
Je pourrais faire un check toutes les minutes par crontab et changer dynamiquement, mais le changement de la MAC de la passerelle,c’est rare quand même.
Et mon routeur, c’est un Netgear R7800, une bête en ce qui concerne le routage car j’utilise l’accélération matérielle. Je peux avoir plusieurs speedtest en parallèle depuis le LAN et le CPU ne bouge quasiment pas. En revanche, un speedtest depuis le routeur lui-même sature le CPU, car on ne passe plus par l’accélération CPU.Je comprends mieux. Tu ne gères donc pas la latence ("bufferbloat") côté routeur. Perso une bonne gestion de la latence me paraît bien plus importante que d'assurer un débit collé au plafond. Chacun ses prios :)
Reboot routeur à la mano possible uniquement quand tu es chez toi. Quant au script qui "trouve tout seul la MAC", il est encore plus inutile en cas de MitM :)
Je comprends mieux. Tu ne gères donc pas la latence ("bufferbloat") côté routeur. Perso une bonne gestion de la latence me paraît bien plus importante que d'assurer un débit collé au plafond. Chacun ses prios :)
GW_IP="$(ip route show 0.0.0.0/0 dev brwan | cut -d\ -f3)"
GW_MAC="$(/usr/bin/arping -f -i brwan $GW_IP | /usr/bin/awk '$1=="Unicast"{print substr($5,2,length($5)-2);exit}')"Le but à l’époque était d’éliminer le bruit venant des fuites.Je ne rencontre pas de problème de latence ; j’ai choisi l’algorithme de congestion qui me va le mieux, et j’ai passé du temps à optimiser les règles, scripts du routeur, éléments sysctl, etc.Pour moi le sujet est très simple: zone blanche, donc tous les mobiles sont en VoWiFi. Plus les Zoom/Skype/Teams pour le TT. Résultat, pas question d'avoir le ping qui passe à 250ms ou plus dès que quelqu'un lance une vidéo sur YT ou qu'une mise à jour est téléchargée. Donc CAKE.
Ça marche pour moi et mon utilisation, probablement pas pour d’autres.
Certes, le script capte tout seul la MAC de La passerelle ainsi :Oulà, awk, tout de suite les grands moyens. Pourquoi pas perl carrément? ;)Code: [Sélectionner]GW_IP="$(ip route show 0.0.0.0/0 dev brwan | cut -d\ -f3)"
GW_MAC="$(/usr/bin/arping -f -i brwan $GW_IP | /usr/bin/awk '$1=="Unicast"{print substr($5,2,length($5)-2);exit}')"
ip neigh show to 171.22/16 dev eth0 | cut -d' ' -f3
:)
Pour moi le sujet est très simple: zone blanche, donc tous les mobiles sont en VoWiFi. Plus les Zoom/Skype/Teams pour le TT. Résultat, pas question d'avoir le ping qui passe à 250ms ou plus dès que quelqu'un lance une vidéo sur YT ou qu'une mise à jour est téléchargée. Donc CAKE.Je suis étonné de ta valeur de 250 ms.
Oulà, awk, tout de suite les grands moyens. Pourquoi pas perl carrément? ;)Pour les vieux dont je fais partie, awk est très bien ... perl n'existait même pas quand j'ai commencé à utiliser des systèmes Unix ;)
Perso si je veux la MAC de ma gw en 2 commandes (et en sachant que je suis dans le réseau 171.22 et que mon interface wan est eth0), j'utiliserais par exemple:TMTOWTDI (https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it)Code: [Sélectionner]ip neigh show to 171.22/16 dev eth0 | cut -d' ' -f3:)
Je suis étonné de ta valeur de 250 ms.Valeur d'illustration prise au hasard mais pas déconnante par rapport à ce qui peut se passer dans la vraie vie (j'ai même déjà vu encore pire)
En ce qui me concerne, en TT presque intégral, et beaucoup en réunions Teams (avec des consommateurs de video YT ou de streaming à la maison), je n'ai jamais souffert de la latence en FTTH.Certains opérateurs ont implémenté ce qu'il faut dans leurs box et leurs infras (Free notamment, mais je doute que K-net ait fait l'effort).
J'utilise une K-Box et n'ai donc rien configuré pour éviter le bufferbloat.
Certains opérateurs ont implémenté ce qu'il faut dans leurs box et leurs infras (Free notamment, mais je doute que K-net ait fait l'effort).K-Net avec Icotera : ça m'étonnerait également.
Fais un test avec https://www.dslreports.com/speedtest ou (moins complet) sur fast.com en cliquant sur "plus d'info" -> latence -> chargé.
K-Net avec Icotera : ça m'étonnerait également.Ah oui je savais qu'il y en avait un 3è et j'avais oublié: waveform!
https://www.waveform.com/tools/bufferbloat me classe en A ou B. Là, je viens de faire le test, çà me sort B, alors que je suis en réunion Teams, sans problème audio/video perceptible.
root@hestia:~# sh betterspeedtest.sh -4 -H netperf-eu.bufferbloat.net -p 10.2.0.5
2022-07-06 12:52:03 Testing against netperf-eu.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging 10.2.0.5 (60 seconds in each direction)
.............................................................
Download: 893.29 Mbps
Latency: (in msec, 61 pings, 0.00% packet loss)
Min: 6.970
10pct: 7.120
Median: 8.070
Avg: 9.597
90pct: 14.000
Max: 19.900
.............................................................
Upload: 924.79 Mbps
Latency: (in msec, 61 pings, 0.00% packet loss)
Min: 7.530
10pct: 8.120
Median: 10.200
Avg: 10.245
90pct: 11.000
Max: 14.100
En utilisant https://github.com/richb-hanover/OpenWrtScripts/blob/main/betterspeedtest.shroot@hestia:~# sh betterspeedtest.sh -4 -H netperf-eu.bufferbloat.net -p 10.2.0.5
2022-07-06 13:20:40 Testing against netperf-eu.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging 10.2.0.5 (60 seconds in each direction)
.............................................................
Download: 449.70 Mbps
Latency: (in msec, 61 pings, 0.00% packet loss)
Min: 6.690
10pct: 6.690
Median: 8.540
Avg: 9.521
90pct: 12.400
Max: 17.800
..............................................................
Upload: 461.11 Mbps
Latency: (in msec, 62 pings, 0.00% packet loss)
Min: 7.110
10pct: 7.460
Median: 9.840
Avg: 9.965
90pct: 11.400
Max: 13.600Etroot@Mnemosyne:~# betterspeedtest.sh -4 -H netperf-eu.bufferbloat.net -p 10.2.0.5
2022-07-06 13:20:40 Testing against netperf-eu.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging 10.2.0.5 (60 seconds in each direction)
.............................................................
Download: 453.76 Mbps
Latency: (in msec, 61 pings, 0.00% packet loss)
Min: 6.100
10pct: 6.820
Median: 7.780
Avg: 9.580
90pct: 13.900
Max: 22.100
.............................................................
Upload: 455.34 Mbps
Latency: (in msec, 61 pings, 0.00% packet loss)
Min: 11.500
10pct: 11.600
Median: 12.700
Avg: 12.726
90pct: 13.400
Max: 15.100
Élégant le ip neigh…ce qui fonctionne chez moi (bash Linux), c'est plutôt :
Donc pour épurer, ça peut donner cela (une méthode parmi d'autres comme le précise pju91) : IF='brwan'; ip n s t "$(ip -4 r s 0/0 d $IF | cut -d\ -f3)" d $IF | cut -d\ -f3
$ IF=wlp1s0|ip n s `ip -4 r s 0/0 dev $IF|cut -d\ -f3`|cut -d\ -f5
Sinon, awk est un outil très puissant à ne pas négliger…oui, tu sais déjà que j'ai le même avis ...
ce qui fonctionne chez moi (bash Linux), c'est plutôt :Code: [Sélectionner]$ IF=wlp1s0|ip n s `ip -4 r s 0/0 dev $IF|cut -d\ -f3`|cut -d\ -f5
Ça fonctionne aussi en POSIX sh, mais avec un ; :oui bien sûr, je voulais mettre un ; (ou rien du tout d'ailleurs). Mais ça n'est pas exactement ce que tu avais écrit qui me donne :
IF=IFACE;ip n s `ip -4 r s 0/0 d $IF|cut -d\ -f3`|cut -d\ -f5
$ IF='wlp1s0'; ip n s t "$(ip -4 r s 0/0 d $IF | cut -d\ -f3)" d $IF | cut -d\ -f3
Error: argument "wlp1s0" is wrong: TOS value is invalid
Error: any valid prefix is expected rather than "t".
oui bien sûr, je voulais mettre un ; (ou rien du tout d'ailleurs). Mais ça n'est pas exactement ce que tu avais écrit qui me donne :Code: [Sélectionner]$ IF='wlp1s0'; ip n s t "$(ip -4 r s 0/0 d $IF | cut -d\ -f3)" d $IF | cut -d\ -f3
Error: argument "wlp1s0" is wrong: TOS value is invalid
Error: any valid prefix is expected rather than "t".
root@HERMES:~$ IF='brwan'; ip n s t "$(ip -4 r s 0/0 d $IF | cut -d\ -f3)" d $IF | cut -d\ -f3
20:e0:9c:XX:XX:XXroot@HERMES:~$ ip -V
BusyBox v1.35.0 (2022-04-15 09:32:59 UTC) multi-call binary.root@hestia:~# IF='eth0'; ip n s t "$(ip -4 r s 0/0 d $IF | cut -d\ -f3)" d $IF | cut -d\ -f3
Error: argument "eth0" is wrong: TOS value is invalid
Error: any valid prefix is expected rather than "t".root@hestia:~# ip -V
ip utility, iproute2-ss200127Sinon, pour le bufferfloat :betterspeedtest est pratique mais n'est absolument pas adapté pour tester le bufferbloat. Surtout quand tu target la passerelle pour le ping :P
En utilisant https://github.com/richb-hanover/OpenWrtScripts/blob/main/betterspeedtest.sh
betterspeedtest est pratique mais n'est absolument pas adapté pour tester le bufferbloat.
Un outil en ligne de commande pour le tester ?Flent. Assez chiant à utiliser.
Quoi qu'il en soit, et c'est ce qui compte au final, ici on a jamais eu de problèmes de latence : Skype/Signal/FaceTime/Zoom…Pourvu que ça dure :)
Tiens, un tech d'Altitude qui arrive un peu sur le tard : https://twitter.com/Chahreddine27/status/1554433204693630977Ca montre en tout cas qu'ils continuent à être préoccupés de cette situation (même si ton tweet a plus de 3 mois). C'est bon signe.
Dommage qu'Altitude ait étanchéifié la collecte, je ne peux plus leur offrir de soutien technique… ;D