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).

Hello,

Je ne passe pas l'étape O3 (serial number) de mon côté malgré la configuration faite sur le SN et le password via telnet.

Je confirme être en GPON comme indiqué par /api/v1/wan/sff (sff, et non pas sfp). L'IMEI est vérifié sur l'étiquette de la bbox elle-même, qui est une bbox Wi-Fi 7 (modèle GP360BE34) et correspond à son numéro de série sur l'interface.
[{"wan":
   {"enable":1,
    "pon_mode":
      {"type":"GPON",
       "moduleclass":"B+",
       "internalstatus":"Up"},
    "sffserial":"ARMG54XXXXXX",
    "sff_vendor_id":"ARMG",
    "olt_vendor_id":"HWTC",
    "serial_number":"0x4152xxxxxxxxxxxx",
    "receive_power":"-18927",
    "transmit_power":2673,
    "temperature":503,
    "voltage":31,
    "firmware_vers_1":"17225.08.10",
    "status_firmware_v1":1,
    "firmware_vers_2":"",
    "status_firmware_v2":0}}]
Côté telnet, les choses que j'ai essayé (entre plusieurs redémarrages)
cmld_client set InternetGatewayDevice.WANDevice.1.X_SC_GponInterfaceConfig.X_SC_SerialNumber=4152xxxxxxxxxxxx
cmld_client set InternetGatewayDevice.WANDevice.1.X_SC_GponInterfaceConfig.X_SC_Password=0000017220XXXXXXXXXX
cmld_client save
gponctl stop
gponctl setSnPwd --pwd 00-00-01-72-20-XX-XX-XX-XX-XX --sn 41-52-XX-XX-XX-XX-XX-XX
gponctl start
Si quelqu'un aurait des idées, je suis preneuse ; j'ai essayé de suffixer le pwd par des 11 pour voir si ça y changerait quelque chose par hasard, mais non.

pas cool...
Au fait, tu as un modem huawei. Ils ont quoi comme port rj45? Sur ma calix, c'est du 1Gb/s, donc même si je passe à l'abonnement 2Gb/s, ça ne sert à rien et je ne pourrais pas dépasser le gigabit.