Le site qui liste les antennes https://www.antennesmobiles.fr// a été très récémmenet "refresh"

Son collègue https://www.couverture-mobile.fr/ existe depuis des années...

Il reste étonnant que d'autres ont encore un tel tarif... FREE s"etant engagé à ne pas augmenter jusqu'en 2027 va peut etre le faire dès le 1/1/20Z7

Si il reste peu de contrats, ce n'est clairement pas un sujet.

Mais attention, qui doit payer pour le démantèlement du réseau câble ? Ce réseau ancien devra bien être démonté.

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.

Avec les fréquences mobiles, il y a des obligations associées (couverture du territoire, ect..) et il est possible de rajouter des obligations de support d'IPv6, car c'est relativement simple sur un mobile de rajouter de l'IPv6 : Pas besoin d'une compatibilité de bout en bout, il faut surtout faire évoluer l'APN.

Les paquets entre l'antenne et le cœur de réseau peuvent être transportés en IPv4 (quand on regarde les paquets mobile sur le réseau d'accès, on voit des paquets IPv4 / IPv6 encapsulé dans des paquets IPv4 (une sorte de VPN).

Sur le fixe, il n'y a pas d'obligations et c'est plus compliqué, il faut que tous les équipements intermédiaires gèrent IPv6. Enfin, il y a les cas de Wi-Fi avec portail captif. Pour le moment tout n'est pas mûr pour que le portail captif log les IPv6.

Le problème pour pouvoir éteindre IPv4 dans 10 ou 20 ans, ce n'est pas le grand public, mais les grandes entreprises (celles qui ont plus qu'une box et doivent avoir la compétence en interne ou via un prestataire).