Journal Bug réseau chez Free

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
21
8
déc.
2018

Quelque chose déconne chez Free, et La Voix du Nord a publié un article aujourd'hui: Que se passe-t-il chez Free ? Des dizaines d’abonnés Nordistes appellent à l’aide

Pour moi, ça a commencé mardi, vers midi. J'ai un serveur chez moi qui interroge toutes les 10 minutes plusieurs autres serveurs (mais tous dans un même AS) et c'est depuis ce moment là qu'il me rapporte des problèmes de connexions. Au départ, je pensais que le problème était plus distant mais mercredi soir, j'ai analysé le trafic sur un routeur intermédiaire et j'ai pu voir que le problème était plus proche de mon accès ADSL. Juste après, mon père m'appelle, se demandant pourquoi Internet déconne depuis 2 jours. C'est sur le forum d'Univers Freebox que j'ai trouvé les premiers témoignages: (V6) VDSL2: soucis d'accès aux sites depuis le 4 décembre

Donc le problème semble être chez Free et si j'écris ce journal, c'est surtout parce que ça pue le DPI, qui en l'occurrence serait buggé.

Ce mercredi soir, avec tcpdump, j'ai pu capturer 2 paquets consécutifs d'une liaison TCP (IPv6), depuis un serveur distant (xxxx:65ee) vers chez moi (yyyy:af00):

# tcpdump -r cap -v -v -n
reading from file cap, link-type EN10MB (Ethernet)
22:03:07.597983 IP6 (flowlabel 0x03a28, hlim 61, next-header TCP (6) payload length: 1335) xxxx:65ee.2050 > yyyy:af00.53374: Flags [.], cksum 0xeaeb (correct), seq 296607965:296609268, ack 3505069365, win 212, options [nop,nop,TS val 959749664 ecr 113961383], length 1303
22:03:35.202397 IP6 (flowlabel 0x03a28, hlim 61, next-header TCP (6) payload length: 32) xxxx:65ee.2050 > yyyy:af00.53374: Flags [.], cksum 0xd496 (correct), seq 1886, ack 1, win 212, options [nop,nop,TS val 959756565 ecr 113961383], length 0

Seul le 2è paquet est arrivé à destination. Si je rejoue ces 2 paquets, le 1er est systématiquement perdu:

# tcpreplay -i eth0 -t cap 
sending out eth0 
processing file: cap
Actual: 2 packets (1475 bytes) sent in 0.09 seconds.            Rated: 16388.9 bps, 0.13 Mbps, 22.22 pps
Statistics for network device: eth0
        Attempted packets:         2
        Successful packets:        2
        Failed packets:            0
        Retried packets (ENOBUFS): 0
        Retried packets (EAGAIN):  0

# tcpdump -i lan -n -vv ip6 net xxxx/48
...
21:56:44.914869 IP6 (flowlabel 0x03a28, hlim 53, next-header TCP (6) payload length: 32) xxxx:65ee.2050 > yyyy:af00.53374: Flags [.], cksum 0xd496 (correct), seq 296609851, ack 3505069365, win 212, options [nop,nop,TS val 959756565 ecr 113961383], length 0
... (je ne montre pas le paquet RST renvoyé par mon serveur)

Si je change le port, l'IP source, voire les 2 de telle sorte que le checksum ne change pas, le paquet n'est pas filtré. Exemple:

# tcpreplay-edit -i eth0 -t -C -S '[xxxx:65ee]:[xxxx:65ef]' -r 53374:53373  cap

# tcpdump -i lan -n -vv ip6 net xxxx/48
...
21:59:47.255457 IP6 (flowlabel 0x03a28, hlim 53, next-header TCP (6) payload length: 1335) xxxx:65ef.2050 > yyyy:af00.53373: Flags [.], cksum 0xeaeb (correct), seq 296607965:296609268, ack 3505069365, win 212, options [nop,nop,TS val 959749664 ecr 113961383], length 1303
...
21:59:47.255495 IP6 (flowlabel 0x03a28, hlim 53, next-header TCP (6) payload length: 32) xxxx:65ef.2050 > yyyy:af00.53373: Flags [.], cksum 0xd496 (correct), seq 1886, ack 1, win 212, options [nop,nop,TS val 959756565 ecr 113961383], length 0
... (ni les paquets 'destination unreachable' en réponse aux RST vers un IP qui n'existe pas)

J'ai aussi essayé de rejouer ces paquets depuis une machine d'un autre AS (la commande tcpreplay-edit est peu plus compliquée parce qu'il faut changer les adresses MAC en plus de l'IP source), et aussi vers une autre IP (chez mon père). Pas de filtrage.

Par contre, le paquet est perdu si je change seulement le Hop Limit ou le Flow Label (en-tête IPv6).

Quant au payload TCP, le paquet est filtré si je change le dernier bit, mais il ne l'est pas si je le remplis de 0x00.

Ca semble aussi affecter seulement les premiers paquets d'une liaison TCP. Si un téléchargement a pu démarrer, aucun problème pour aller jusqu'au bout.

Bref, il ne s'agit ni d'un problème physique, de débit, de latence. C'est en apparence aléatoire, mais reproductible. Si vous naviguez et que ça bloque, inutile d'attendre: le serveur distant aura beau renvoyer le paquet (comme le prévoit TCP), vous ne le recevrez pas. La seule solution est de se reconnecter.

Un FAI n'est pas censé regarder au-delà de la couche 3 (réseau). Est-ce donc bien du DPI ? J'ai pourtant du mal à voir comment ça pourrait bugger de la sorte. Peut-être y a-t-il une IA, ces bêtes là étant des boîtes noires.

Ca me rappelle un incident similaire, cette fois-ci chez Orange. C'était en 2013 mais c'est peut-être encore le cas. J'avais pu capturer un paquet UDP de 1539 octets (IPv4). Le bug n'affectait que les paquets fragmentés. Modifier les données dans le premier fragment ne changeait rien, alors qu'il n'était plus filtré si je changeais le deuxième fragment.

  • # La couche 3 ? Tu n'as pas tout compris !

    Posté par  . Évalué à 6.

    Un FAI n'est pas censé regarder au-delà de la couche 3 (réseau). Est-ce donc bien du DPI ? J'ai pourtant du mal à voir comment ça pourrait bugger de la sorte.

    Hum, cherchons "bridage p2p free.fr condamnation" sur google… ah, il y a bien un FAI qui sabotait les applications de ses clients (ça touchait aussi ssh et d'autres protocoles).

    La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4. Dernière modification le 09 décembre 2018 à 09:25.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: La couche 3 ? Tu n'as pas tout compris !

        Posté par  . Évalué à 5. Dernière modification le 09 décembre 2018 à 10:07.

        Ne me fais pas dire ce que je n'ai pas dit, s'il te plaît. Je fais juste remarquer à l'auteur que son affirmation "Un FAI n'est pas censé regarder au-delà de la couche 3 (réseau)." est pour le moins naïve.

        Cela dit, on trouve par exemple un article du canard enchaîné (https://lafibre.info/free-les-news/les-bidouillages-de-free-rani-assaf-et-son-appli-par-le-canard-enchaine/msg567201/?PHPSESSID=q4df9tbotpgr22kkqngpn8aph6#msg567201) dans lequel on apprend que free est accusé (non seulement par un de ses concurrents, mais aussi par des clients), de dégrader le service au client pour faire des économies. Et pas en 2006.

        La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

        • [^] # Re: La couche 3 ? Tu n'as pas tout compris !

          Posté par  . Évalué à 2. Dernière modification le 09 décembre 2018 à 14:49.

          Je fais juste remarquer à l'auteur que son affirmation "Un FAI n'est pas censé regarder au-delà de la couche 3 (réseau)." est pour le moins naïve.

          Je n'ai juste pas développé ce point. Ce n'est pas pour rien que je chiffre toutes mes communications, y compris en ayant installé stubby (DNS-over-TLS) sur mon serveur, auquel j'accède depuis n'importe où par un VPN.

          Bien sûr, Free est maître de son réseau et peut faire ce qu'il veut. Pas vu, pas pris. Les services secrets peuvent aussi certainement s'incruster. Mais il y a toujours une différence entre supposer et avoir une preuve.

          Ce je rapporte n'est pas non plus une preuve irréfutable de quelque chose que Free n'est pas censé faire. Mais même si un bug peut prendre des formes étonnantes, j'ai du mal à imaginer ce qui pourrait merder ici sans qu'il n'y ait à la base du code analysant la trame TCP.

  • # DPI légal

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Le DPI est officiellement interdit mais en pratique il y a des obligations a mettre des boîtes noires sous contrôle de l'état et bien d'autres obligations de surveillance automatique. Donc ce n'est pas si étonnant.

    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

  • # DPI ?

    Posté par  . Évalué à 6.

    J'ai un peu de mal à comprendre ce qui t'amène à parler de DPI. D'après le symptôme cela pourrait aussi être un load balancing pourri, avec une des routes en carafe. Non ?

    • [^] # Re: DPI ?

      Posté par  . Évalué à -3.

      c'est arrivé près de chez une copine, je lui ai demandé si il y avait des travaux dans le coin, et effectivement il refaisait une route pour le passage de l'A380.

      du coup je lui ai dit de patienté un peu (5jours), il n'y a rien à faire.Oui mais parfois ca marche ! et oui c'est la vie, parfois des electrons passe dans le fossé et reprenne la gaine, mais cela ne va pas durer, ils n'aiment pas le froid.

      bon bref c’était il y a 3 mois, et je n'ai pas alerté le web pour cela, pourtant presque la moité du gers était : sans téléphone, sans internet, et le réseau GSM seule la 2G fonctionnait.

      le truc étrange c'est dans un village seule une personne avait encore internet, j'imaginais que ce devais être la seule pair qui tenait encore. La pelleteuse ayant du s’arrêtait juste a temps !

      tss tss les jeune n'ont plus de patience …

      • [^] # Sauf que

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 10 décembre 2018 à 08:28.

        Sans être un ponte en réseaux, l'auteur du journal semble bien préciser que les paquets passent ou pas de manière tout à fait systématique en fonction de leur contenu (changer les ports, octets…). Donc à moins que les pairs de cuivre utilisées varient en fonction de ces critères l'explication que vous évoquez semble peu crédible. Non ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Sauf que

          Posté par  . Évalué à 1.

          il y a plein d'autre pb qui peuvent arriver hein ! c’était un exemple de personne s’inquiétant de ce genre de pb et qui ne comprenait pas pourquoi cela ne fonctionne pas.

          c'est la vie, c'est avec le genre de raisonnement du journal que l'on se retrouve avec un accident nucléaire ! (three miles island)

  • # Impact sur les libs // Apprentissage

    Posté par  (site web personnel) . Évalué à 4.

    Je suis aussi un abonné Free du Nord de la France et j'ai aussi eu le problème à partir du mardi 4 vers midi. Cela s'est finalement résolu le dimanche en milieu d'après midi (selon le monitoring).

    J'ai reporté le problème à Free le mercredi et aucune réponse ….

    Je stocke les données de température et autres capteurs dans une base sqlite locale (pas de problème) et aussi dans Firebase (et là problème).

    J'ai fait à peu prêt les mêmes tests que toi mais en poussant un peu moins (car moins de compétences en tcpdump / tcpreplay)

    Les leçons que je retire de cet événement :
    * Ca a été un bon moyen de tester mon monitoring des différents services qui tourne sur mes petits serveurs à la maison. A final j'ai vite été prévenu des problèmes et j'ai pu mettre en place des automatismes pour relancer les services faisant des accès réseaux quand ils tombaient.
    * La plupart de mes programmes sont écrits en Python3 et les accès HTTPS utilisent la bibliothèque requests. Cette bibliothèque (de haut niveau) ne supporte absolument pas ce genre d'erreur TCP. A chaque erreur TCP mon programme ne plantait pas mais il restait bloqué (aucune exception lancée donc rien à catcher).

    Au final j'ai pu apprendre à aller au delà des Thread (qu'on ne peux pas tuer) et utiliser des Process :
    * à créer une Queue (multiprocessing.Queue) de données à envoyer
    * à mettre tous les appels à Firebase dans un process à part (multiprocessing.Process)
    * créer mon propre watchdog qui vérifie que si la Queue ne fait qu'augmenter de taille alors le process d'envoi à Firebase est bloqué et donc il faut le tuer (terminate) et en relancer un autre.

    Désolé de raconter ma vie mais il y a au moins un point positif à cela ;)

  • # Quelle daube

    Posté par  . Évalué à 4. Dernière modification le 11 décembre 2018 à 15:47.

    Ça sent effectivement assez mauvais ton truc. Pas dans le sens « on nous espionne », qui est peut-être une hypothèse un peu osée, mais dans le genre ya encore des neuneus qui font de l'inspection stateful et pètent le réseau sans se rendre compte de la merde qu'ils font.

    Car quand tu dis « DPI », moi je vois seulement l'aspect aller tracker une connexion et de filtrer sur des critères à la con, en cassant bien sûr au passage TCP. Que ça soit à des buts d'espionnage, ou « seulement » d'un truc à la con genre protection anti-DDOS, etc. Mais oui, ils s'occupent de trucs qui ne les concerne pas (et ta modification du flow label montre bien qu'ils veulent vraiment tout casser et n'ont rien compris à IPv6).

    D'ailleurs au passage, qu'ils s'attaquent à IPv6, je ne m'y attendait pas, et du coup du cassage du genre ça sent très mauvais pour le déploiement d'IPv6, qui pour moi doit être irréprochable niveau qualité de service, sinon ça ne sert strictement à rien (c-à-d que faire du filtrage stateful sur de l'IPv6, c'est du sabotage délibéré qui devrait être sévèrement puni).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.