Le 01/06/2022 à 00:48, David Ponzone a écrit :
Le 31 mai 2022 à 21:55, Raphael Mazelier <r...@futomaki.net> a écrit :
Alors déjà que tu puisse voir le trafic downstream des autres clients c'est
étrange. Mais soit admettons les datas sont la à ta porte donc si le trafic est
en clair et que l'ont se met en mode sniffing (ca doit exister) pourquoi pas.
Mais alors l'upstream alors la je vois même pas comment c'est possible. Si tu
vois l'upstream cela veut dire que tu l'as d'abord reçu pour le renvoyer ?! une
sorte de bounce. Mais ca doit créer un bazar pas possible.
J’arrive plus à reproduire, donc au temps pour moi, je me suis peut-être
planté, je finis par m’embrouiller à force, surtout que certains clients
semblent avoir des VPN IPsec encore 2 opérateurs clients de Kosc.
Je vais chercher encore, mais je préfère autant ça, parce que c’était vraiment
incohérent/impossible.
En tout cas c'est plutôt rigolo et intéressant si tu as le fin mot de
l'histoire. (ça sent quand même la méga mauvaise config coté kosc)
Oui.
Pour ceux qui encore un doute, petit exemple de ce que ça donne sur un client
de Paritel dont je viens de voir le traffic sur le FTTH de mon client.
Ping depuis mon FTTH perso Bouygues à Paris:
% ping 5.134.101.211
PING 5.134.101.211 (5.134.101.211): 56 data bytes
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=20.505 ms
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=26.913 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=33.350 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=36.826 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=36.839 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=37.523 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=41.796 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=43.910 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=48.683 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=235 time=54.345 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=54.361 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=54.812 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=229 time=55.675 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=59.009 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=59.186 ms (DUP!)
> [...]
>
--- 5.134.101.211 ping statistics ---
1 packets transmitted, 1 packets received, +55 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 20.505/83.371/148.402/33.396 ms
Je jure que je n’ai absolument pas altérer le résultat, j’ai juste fait un
ctrl-C pour arrêter les frais :)
Y a des réponses venant de Kertel, de Convergence, d'Alphalink, de Networth,
etc….
Le truc amusant, c’est que si je veux arrêter de recevoir ce traffic parasite
chez mon client, j’ai juste à faire tomber le PPPoE.
Quand il remonte, c’est clean, pendant quelques minutes et après ça revient.
J'ai un lien dans le lot, je confirme, le CPE reçoit des paquets dans la
session PPPoE qui ne sont pas pour lui et le pire c'est qu'il les traite
car ils ont tout l'air d'être correct.
Incroyable ! Quel bug !
Jérôme
--
Jérôme Marteaux
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
