Bonjour à tous,

Je constate un problème de débit reproductible entre deux abonnés Freebox Pop FTTH distants d'environ 18 km, et j'aimerais savoir si d'autres ont le même comportement ou si quelqu'un peut m'aider à creuser davantage.

Configuration

- Deux abonnés Freebox Pop FTTH
- Distance géographique : ~18 km
- RTT stable entre les deux extrémités : 29–34 ms
- Serveurs Synology DS218+ des deux côtés (noyau Linux 4.4.59)
- Tampons TCP correctement dimensionnés des deux côtés (net.core.wmem_max = 67108864)

Symptôme

Les transferts rsync/scp entre les deux NAS plafonnent à 15–20 MB/s en moyenne, avec un profil en cloche caractéristique : montée à ~45 MB/s puis descente progressive jusqu'à ~15 MB/s. Avec 4 flux parallèles, on atteint ~60 MB/s agrégés sans problème.

Diagnostic iperf3

Flux unique TCP — forte variance entre deux tests consécutifs :

Test 1 :  341 MBytes  286 Mbits/sec   6 retrans  (mauvaise passe)
Test 2 :  857 MBytes  719 Mbits/sec  380 retrans  (bonne passe)

4 flux parallèles TCP — stable :

[SUM]  0.00-30.00 sec  2.45 GBytes  702 Mbits/sec  329 retrans

Analyse ss -tin en temps réel pendant rsync

Le cwnd de CUBIC s'effondre régulièrement toutes les 4 à 6 secondes, sans aucune augmentation du RTT — signe caractéristique d'un routeur intermédiaire avec un buffer très faible pratiquant le tail-drop :

22:43:27  cwnd:869  ssthresh:800  296 Mbps  retrans:0/2
22:43:29  cwnd:668  ssthresh:651  244 Mbps  retrans:0/3  ← perte
22:43:32  cwnd:764  ssthresh:539  272 Mbps  retrans:1/4  ← perte
22:43:36  cwnd:471  ssthresh:450  181 Mbps  retrans:0/5  ← perte
22:43:41  cwnd:403  ssthresh:379  156 Mbps  retrans:0/6  ← perte
22:43:45  cwnd:330  ssthresh:322  128 Mbps  retrans:0/7  ← perte
22:43:55  cwnd:295  ssthresh:288  113 Mbps  retrans:0/9  ← perte

Le RTT reste parfaitement stable à 29–34 ms tout au long — la perte se produit sans latence accrue.

Topologie du chemin

traceroute -T -p 34123 <IP publique distante>
 1  192.168.1.1      (Freebox locale)     0.8 ms
 2  192.168.10.1     (ONT/OLT)            1.2 ms
 3  * * *
 4  * * *
 ...
10  <IP distante>                         30.5 ms

8 sauts intermédiaires entièrement opaques (ICMP et TCP SYN bloqués). Le routeur problématique se trouve quelque part dans cette séquence.

Ce qui ne fonctionne pas comme solution

- Ajuster les tampons TCP : sans effet (déjà à 64 MB des deux côtés)
- Changer de congestion control : seuls cubic et reno sont disponibles sur le noyau 4.4.59 de DSM — BBR n'est pas disponible
- WireGuard : non viable sur ce matériel (pas de support ChaCha20 hardware sur J3355)

Questions

- Est-ce que d'autres abonnés Freebox Pop FTTH observent ce comportement sur des transferts TCP longue durée flux unique ?
- Y a-t-il un moyen d'identifier lequel des 8 sauts opaques est responsable ?
- Ce comportement vous semble-t-il lié à un changement récent dans l'infrastructure Free ?

Merci d'avance pour vos retours.

Le trafic en IPv4 doit passer par l'Île-de-France (encapsulé dans de l'IPv6) alors que l'IPv6 peut peerer localement.

Il faudrait comprendre l'origine des pertes de paquets Cela peut être une saturation des buffers à un endroit (lié soit à trop de paquet envoyé en local, soit à une saturation sur un segment où il y a d'autres flux) ou une perte liée à un média défectueux (ex: câble Ethernet défectueux).

Sur chaque Synology, tu peux tenter de lancer un ping ICMP vers l'autre Freebox. Normalement, tu dois avoir 0,00% de perte de paquets. Attention si tu lances des ping en même temps qu'il y a un transfert important, cela peut générer des pertes de paquets.

Pour l'hypothèse d'une saturation, le test à faire est simple : faire des transferts en heure de pointe (19h00 ⇒ 23h00) et en heure creuse (1h00 ⇒ 9h00) : Si les débits sont identiques, la piste de la saturation n'est pas la bonne.