URL: https://linuxfr.org/users/lcld/journaux/bug-reseau-chez-free Title: Bug réseau chez Free Authors: lcld Date: 2018年12月08日T23:14:38+01:00 License: CC By-SA Tags: fai et free Score: 21 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](http://www.lavoixdunord.fr/502864/article/2018-12-07/que-se-passe-t-il-chez-free-des-dizaines-d-abonnes-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](https://fr.wikipedia.org/wiki/Autonomous_System)) 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](https://forum.universfreebox.com/viewtopic.php?t=71743) Donc le problème semble être chez Free et si j'écris ce journal, c'est surtout parce que ça pue le [DPI](https://fr.wikipedia.org/wiki/Deep_packet_inspection), 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](https://fr.wikipedia.org/wiki/R%C3%A9seau_de_neurones_artificiels#Opacit%C3%A9). 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.

AltStyle によって変換されたページ (->オリジナル) /