verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 10:12 Sujet du message:
170468156571
Fuli a écrit:
En IPv6 ou en IPv4?
Peu importe, c'est aussi lent dans les deux cas (que ce soit activé au compte client ou pas, ou activa dans la box ou pas).
Ce NRO/NRA est en full IPv6 de toute façon, l'IPv4 est tranporté par tunnel sur IPv6 (et s'avère même un peu plus lent). Du moins c'est ce que je voyais depuis samedi matin.
Ce matin le débit est revenu et est utilisable, il n'y a plus ce tunnel (une route a du être corrigée), cependant la latence n'est pas ce qu'elle était (26 ms)
Jusqu'à vendredi la latence était à 9-10ms, plus stable que maintenant (moins de gigue).
Jusqu'à vendredi le débit Down au delà des 500 Mbps avec des pointes à 800Mpbs (maintenant seulement 190 Mbps pour un téléchargement jusqu'à 10Mo, ce débit descend à la moyenne de 64Mbps pour un chargement jusqu'à 1 Go). Le débit UP était aussi un peu plus élevé.
On voit bien que Free a mis en place un trafic shaper au niveau 4 (session par session en TCP: plus la session dure et cumule du trafic, plus ce trafic est lent).
Visiblement ceux qui ne sont pas impactés par ça sont ceux qui font du téléchargement pirate par torrent (nombreuses petites sessions TCP pour transmettre des fragments): ils bouffent toute la bande passante en détriment de tous les autres. Car Free n'applique pas d'équilibre au moins par abonné (par bloc d'adresses IPv6) comme le faisait sur les accès au niveau 3 en IPv4 (équilibrage IP par IP). La configuration des nouveaux switches de collecte de Free laisse à désirer...
Fuli, Posté le: Mer 02 Mai 2018, 11:38 Sujet du message:
1469712956
Non, pas peu importe. C'est important.
La première ligne était suffisant comme réponse. Pb IPv4 et IPv6= rien à voir avec les routes.
On est au courant pour le tunnel Merci.
Et le test debit en local? Depuis mafreebox.freebox.fr réglage avancé-> test debit local ?
En IPv4 puis en IPv6.
Je n'attend que les chiffres, avec normalement une légère différence IPv4 vs IPv6. Cela montrera si la Freebox est OK ou pas.
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 14:33 Sujet du message:
170468156571
Fuli a écrit:
Non, pas peu importe. C'est important.
La première ligne était suffisant comme réponse. Pb IPv4 et IPv6= rien à voir avec les routes.
On est au courant pour le tunnel Merci.
Et le test debit en local? Depuis mafreebox.freebox.fr réglage avancé-> test debit local ?
En IPv4 puis en IPv6.
Je n'attend que les chiffres, avec normalement une légère différence IPv4 vs IPv6. Cela montrera si la Freebox est OK ou pas.
Tu redemandes la même chose et j'ai déjà répondu.
Le test débit local est déjà fait il est à 1 gibagit/s exactement (en fait très légèrement au dessus), le maximum du port Ethernet du PC (là peu importe que ce soit en IPv6 (via l'adresse locale ff80::*) ou IPv4. (l'écart entre IPv4 et IPv6 est totalement insignifiant, mon PC tourne très bien Merci, la différence est du même ordre que les microdifférences liées aux autres activités mineures de la box elle-même ou du PC).
Le test du plus gros fichier proposé de 1 Go (8 gigabit utiles, plus quelques pourcents pour les entêtes IP/TCP) prends exactement 1,5 seconde mesure depuis le moniteur de performance du PC (sans aucune pause intermédaire: j'ai assez de mémoire pour ne même pas être ralenti par les I/O du SSD ou du disque dur: la courbe est parfaitement rectangulaire entre 0 % avant 100% pendant 1,5 seconde, puis à nouveau 0% du débit de l'interface Ethernet)
Et ce n'est clairement pas en local le problème mais bien sur la collecte en amont du NRO
(et j'ai toujours plus de 3% de perte de datagrammes ICMP ou UDP à ce niveau, que je le mesure avec mon PC ou avec un mobile en Wifi AC connecté à 350 Mbps dans une bande de 80 MHz continue sur les 8 canaux 36 à 47 non soumi à DPS (et sans aucun voisinage d'autres bornes Wifi sur les mêmes canaux), je ne franchis pas les 3 mégabit/s en Download).
Si tu lisais, il suffit de lancer un téléchargement non pas sur le PC, mais sur la Freebox elle-même (le PC peut être éteint) dans son propre disque dur (ma Freebox.Freebox.fs > connexion > téléchargements > ajouter une URL en haut du fichier test sur le serveur de Free, et OK: c'est la Freebox qui télécharge toute seule le fichier de 1 Go en HTTP, SANS même passer par le réseau local, juste par la Fibre: et là ça prend pas loin de 2 heures avec un débit moyen de 2,5 mégabit/s part "vite" à environ 150 Mbps sur une seconde, puis est très rapidement freiné qui ne cesse de baisser, la fin termine à moins d'1 Mbps, et le débit fait des sauts entre une fraction de seconde à quelques mégabits/s et 4-5 secondes de silence complet, souvent la session TCP est interrompu et je n'ai pas la fin du fichier, le téléchargement a échoué quand les "pauses" deviennent trop longues et dépassent plus de 30 secondes de complet silence... Il est impossible de maintenir une session HTTP ouverte fiable si elle dure plus de 30 minutes et impossible d'atteindre les 2 heures).
Donc pour le moment la seule façon fiable de transférer des fichiers, c'est d'utiliser des Torrents et transmettre par fragments de moins de 1 Mo (en torrent, il y a aussi des pertes de trames et des ruptures de session, mais le protocole reprend facilement et corrige automatiquement). Pour une image de 1 Go ou plus ça foire à chaque fois en HTTP ou FTP ou bien c'est corrompu (exemple une image ISO de DVD Linux depuis les sites officiels, certes ces serveurs n'émettent pas à 1gigabit/s mais en a plusieurs mégabit/s et c'est normalement fiable et on ne devrait pas avoir de rupture de session avec fichier tronqué ou très rarement, mais là c'est systématique).
Fuli, Posté le: Mer 02 Mai 2018, 16:12 Sujet du message:
1469712956
Faux.
Les tests n'ont pas été bien fait en IPv6. Il y a une différence.
Mais 1 Go en 1.5s cela fait du 5 Gbps.....
On peut avoir les vraies valeurs juste?
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 16:55 Sujet du message:
170468156571
Fuli a écrit:
Faux.
Les tests n'ont pas été bien fait en IPv6. Il y a une différence.
Mais 1 Go en 1.5s cela fait du 5 Gbps.....
On peut avoir les vraies valeurs juste?
C'est la vraie valeur en local je peux te montrer les graphiques en capture d'écran mais tu ne me croiras pas que je puisse avoir une connexion locale aussi rapide. Et pourtant ça montre une chose: le débit lent sur Internet ne vient pas de mon réseau local ou mon PC qui est parfaitement optimisé.
La capture écran du graphique généré par Freebox OS est tout aussi parlant (trafic uniquement Internet qui est le seul goulot d'étranglement, alors que la Fibre n'a aucune anomalie détectée par la Freebox et 0% de perte de trames jusqu'au switch/routeur Free installé au NRO
La lenteur est clairement sur le réseau de collecte en amont dont la configuration a changé brutalement entre vendredi soir et samedi matin, on ne peut pas voir les routes sur ce réseau interne mais on le mesure facilement quand Free a ajouté du jour au lendemain ~20 millisecondes de latence, ce qui correspond à peu près à deux VPN successifs et qu'on peut facilement compter et localiser: un passe par SFR, l'autre par OVH et entre les deux ça passe par Telehouse 1 avant d'arriver aux serveurs Free (à Bezon) puis enfin router vers Internet; Free n'a visiblement aucun peering à Telehouse 1 sauf pour ses clients normands, ça se sent que Free a changé le routage contraint et forcé suite à une panne et qu'il ne veut pas le dire, mais le contournement n'est pas dimensionné comme il faudrait: Free traite de la même façon les clients Fibre et ADSL, même même pour l'ADSL, les 2-3 Mbps c'est assez minable, et ça se voit dans les statistiques publiées par Netflix et d'autres qui classent Free comme bon dernier en Europe, de très loin, et même loin derrière des opérateurs africains.
Le réseau de collecte de Free est extrêmement fragile et instable (notamment hors des ZTD car Free n'y a strictement aucune infrastructure; quand on voit la carte du backbone de Free, il n'est même pas sécurisé par des boucles redondantes, il est très fortement hiérarchisé en étoile centré sur Paris; seules les ZTD sont preque correctement interconnectées, mais il y a des oublis, comme l'absence de liaison Rennes-Nantes et Rennes-Caen, aucune liaison frontalière en Alsace et le long de la frontière belge, aucune redondance pour la liaison vers le royaume-uni; et rien vers Francfort et vers l'Espagne; même l'axe nord-Sud Pris-Marseille est incomplet, Proxad n'a pas la capacité nécessaire entre Lyon et Marseille pour connecter son deuxième Pop pour France-IX: il taille son réseau au plus juste et au moindre pépin il sacrifie drastiquement sur le dos des abonnés régionaux Free).
Heureusement ce que Free ne veut pas nous dire, on peut le voir via les outils type "Spyglass" ouverts des autres opérateurs: son réseau est très instable et a bel et bien de fréquentes pannes et sinon est presque toujours à la limite de la saturation, Proxad attend seulement un gros pépin pour réagir quand les clients d'Online.net ayant une option de maintenance garantie commencent à se plaindre et qu'il doit les indemniser: là il se met à acheter des ressources en urgence (au plus mauvais prix), il n'est pas prévoyant du tout et concernant Free, ne travaille qu'à très court terme, et sinon il a cloisonné ses services internes pour les empêcher de communiquer entre eux.
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 17:27 Sujet du message:
170468156571
Je note que maintenant la "vraie" connexion avec OVH/completel est revenue (-3ms en ping et 500 mgbps Down) mais pas avec le reste (Orange et SFR encore à 65 Mbps en Down pendant environ 10 secondes puis chute progressive au delà, le trafic shaper est encore en marche, au moins un des deux VPN intermédiaires de secours est encore en service et encore 2% de trames perdues contre 17% hier soir sur une moyenne horaire avec 1 test de 10 trames toutes les 5 minutes).
La MTU max en IPv6 est remontée un peu (44 octets d'entête et non plus 48 comme hier soir; si c'était réellement de l'IPv6 natif, ce devrait être 40 octets)
Le ping d'OVH avec une trame de 1500 octets de MTU passe, mais pas encore le ping de Google (même en IPv4 seulement où la fragmentation devrait fonctionner): Google passe encore mais avec une MTU réduite sans fragmentation.
Le VPN de Free sur les liaisons de collecte IPv6 n'encapsule pas bien le trafic IPv4 pour supporter la fragmentation, et PMTUD est désactivé (la collecte en IPv6 ne semble pas prendre en charge les options de fragmentation non plus poru encapsuler les fragments IPv4: en IPv6, il est interdit de fragmenter au fil de l'eau par les transitaires, contrairement à IPv4, la fragmentation est à initier de bout en bout par les clients à cause des contraintes liées à IPSEC, et le support de PMTUD, est donc obligatoire; le désactiver en bloquant toutes les réponses ICMPv6 sur un parefeu par exemple empêche ce fonctionnement normal).
Ca ressemble à un gros bogue du logiciel ou des réglages de leur switch, les logiciels font ce qu'ils peuvent mais le taux d'échec de transmission trop important doit imposer un ralentissement sur les routeurs des transitaires, pour permettre aux logiciels client de faire une émulation et une découverte de MTU "passive" approximative (et lente).
Cyanos, Posté le: Mer 02 Mai 2018, 18:03 Sujet du message:
170478156580
Bonjour,
pour faire court, j'habite sur le même secteur que verdy_p et nous sommes plusieurs a être impacté par le problème.
Il semble tout simplement que le réseau ne fourni pas aux heures ou tout le monde est à la maison sur le net.
Le souci est récent et Free ne semble pas réactif et ne désire pas ouvrir de ticket incident.
Fuli, Posté le: Mer 02 Mai 2018, 18:56 Sujet du message:
1469712956
@Cyanos
Je ne nie pas le pbm sur Niort. J'aimerai juste des réponses simples et cohérentes afin de déterminer si:
- ca vient uniquement de l'encapsulation de l'IPv4
- de la collecte
- de sa Freebox
- de son PC
Pour le moment je ne sais même pas pourquoi il a 5 Gbps en local....
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 19:15 Sujet du message:
170468156571
Fuli a écrit:
Bon,
Plus de 10 lignes je ne lis plus.
Et donc en local on a plus de 5 Gbps depuis la Freebox qui ne supporte que du Gbits/s? Comprenons ce problème et ensuite on verra.
"Comprenons ce problème". Ce n'est justement pas un problème sur le LAN. A mon avis cette box de Free supporte un mode plus rapide côté LAN que 1 Gbps, le test interne doit ne pas utiliser des données aléatoire et une compression de données s'active qui permet de dépasser ce seuil. Mon LAN est déjà configuré aussi pour supporter les "jumboframes" si la qualité de connexion est bonne (ce qui réduit aussi le coût des entêtes)
Je ne sais pas jusqu'à quelle taille de jumboframe la Freebox supporte sur ses ports Ethernet, mais la carte réseau du PC accepte sans brancher des trames Ethernet très larges (jusqu'à 64Ko et non seulement les 1500 octets de base, la compression de données peut alors fonctionner de manière optimale, ma carte réseau sur PC pouvant prendre ça en charge sans recourir au CPU, et elle dispose d'un switch intégré avec 1 Go de RAM dédiée, je pense que la Freebox ne droit pas avoir plus de 1 Mo de RAM dédiée sur son switch, et doit supporter des jumboframes de 4Ko où la compression est malgré tout suffisante).
Si je regarde le contenu du fichier test de 1 Go intégré dans la box, il est très fortement compressible (une simple compression ZIP ou gzip le réduit en taille d'un facteur très élévé, voisin de... 256 pour 1!): il ne contient que des répétitions cycliques de séquences d'octets incrémentés de 0 à 255 (n'importe quelle compression à dictionnaire, type LZW, arrive sans difficulté, même sur un tampon de taille limitée à 1500 octets, à compresser au moins en 6 pour 1) au lieu de données aléatoires: ce test est donc faux: La Freebox supporte les compressions classiques d'HTTP (comme "deflate" ou "gzip", dérivés tous les deux basées sur l'algo LZW complété d'autres stratégies statistiques, et pas seulement sur une compression statistique octet par octet comme Huffman qui ne pratique ne sert que pour les longues séquences d'octets dans des images BMP, ou pour la compression de texte), et c'est un test en HTTP. Ce test de débit local aurait mieux fait de se faire avec une vidéo MPEG4 ou un fichier MP3 ou OGA (déjà fortement compressés) ou des données réellement aléatoires sur lesquels les méthodes de compression des donnes en HTTP sont désactivées. Là avec des données très fortement redondantes, il est trompeur (même si HTTP dans ce test est paramétré pour désactiver les caches du côté client, ce dont je ne suis même pas sûr).
Donc ça ne m'étonne pas qu'on dépasse facilement le 1 Gbits/s physique sur ce test LAN. Le test du LAN par la Freebox n'est pas significatif du tout, et 1,5 secondes de téléchargement de ce fichier de 1 Go est tout à fait normal ! (je n'ai pas la mesure très exacte à mieux qu'1/10e de seconde près sur la courbe de mesure de trafic sur le PC, mais c'est facile à estimer avec peu d'erreur et j'ai bien 10 échantillons de vitesse par seconde sur ce graphique, ça peut être 1,4 ou 1,6 seconde effectif).
Dernier point important: le test du fichier de 1 Go intégré dans la Freebox envoie un fichier non pas de 1 Go, mais seulement 147Mo, cela explique pas mal de chose même s'il n'y a pas de compression au niveau HTTP ou de compression au niveau des options IP. Ce test de la box est donc totalement faux mais le résultat est cohérent, et 1,5 seconde (à +/- 0.1 s près) pour charger ce fichier sur le LAN est tout à fait normal (et c'est le résultat attendu si on y est connecté sur une port Ethernet en mode 1 Gbps full duplex, ce qui est mon cas). Je pense que ce test intégré est délibérément biaisé par Free pour afficher de prétendues bonnes performances de sa box!
Ou alors c'est un gros bogue du firmware de la Box qui tronque et oublie des données (si le même bogue existe dans son switch interne, pas étonnant qu'on ait aussi des pertes de trames dans les mesures, et un débit TCP lamentable).
Pour info la Freebox a un firmware où le Freebox OS (l'appli Flash intégrée) se dit en version 3.5.2. Je ne peux pas dire si c'est un bogue de cette appli Flash ou de son serveur Web intégré ou de l'OS sous-jascent (plus ou moins basé sur un Linux modifié sans doute, ou de ses pilotes intégrés). Plus j'y pense et plus je crois que le problème est dans le firmware de la Freebox ! Si vous connaissez le moyen de faire un reste usine de ce firmware pour charger une version précédente, je suis preneur (je n'ai pas noté quelle était la version de ce firmware jusqu'à vendredi soir et si une mise à jour a été téléchargée dans la nuit de vendredi à samedi).
Mais cela ne dit toujours rien de la connexion Internet côté WAN.
Car c'est totalement indépendant du Download entre Internet et la box qui n'utilise que l'interface WAN-Fibre et pas du tout le LAN.
Un sujet intéressant:
https://dev.Freebox.fr/blog/?p=5281#more-5281
Là ça parle de gros bogues dans la gestion de la fragmentation IP (les MTU justement, qui doit pourtant être impeccable pour supporter la collecte en IPv6 et l'algo PMTUD obligatoire ainsi que le non filtrage sur le parefeu interne des réponses ICMPv6 nécessaires pour faire fonctionner PMTUD), problème constaté quand on règle la Freebox en mode bridge (en désactivant son routeur, mais en gardant sa fonction switch).
Dernière édition par verdy_p le Mer 02 Mai 2018, 19:42; édité 2 fois
Underground78, Posté le: Mer 02 Mai 2018, 19:35 Sujet du message:
35863324
J'ai pas lu les messages mais vu les témoignages multiples concernant la région de Niort c'est très certainement une rupture de Fibres ou un équipement en panne qui a fait perdre de la capacité vers Paris.
La plaque n'est pas complètement coupée mais fonctionne en mode dégradé. Même si la Hotline n'est pas au courant ça ne veut pas dire que le problème n'est pas connu chez Free (je suis sûr à 99% qu'il l'est).
Fuli, Posté le: Mer 02 Mai 2018, 19:40 Sujet du message:
1469712956
+1
Après pourquoi pour la plupart c'est 20Mbps et pour lui c'est 2.5Mbps.....
C'est juste ça que j'essaye de comprendre, mais comme il a déjà 5 Gbps en local depuis la box, je n'arrive à rien.
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 19:48 Sujet du message:
170468156571
Fuli a écrit:
+1
Après pourquoi pour la plupart c'est 20Mbps et pour lui c'est 2.5Mbps.....
C'est juste ça que j'essaye de comprendre, mais comme il a déjà 5 Gbps en local depuis la box, je n'arrive à rien.
Je viens de te dire pourquoi: le fichier de 1 Go du test intégré ne fait pas 1 Go.
Le calcul est vite fait, en fait sur 1,5 secondes je n'ai pas assez de temps pour faire évoluer la courbe de suivi de mesure, je ne peux donc pas afficher le vrai débit maximum obtenu mais avec 147Mo en 1,5 secondes sur le test LAN ça fait 1,176 Gigabits (et non Giga octets) en 1,5 seconde, donc 784 megabits/s et c'est cohérent sur un port Ethernet 1 Gbps (je ne sature pas le port, sans doute parce que le switch Gigabit intégré de la Freebox est trop lent ou son firmware est trop lent à générer les données bien que ce soit des données répétées (séquences de 256 octets de 0 à 255) qui tiennent dans un tout petit tampon. (Note: un port Gigabit Ethernet se mesure en bits et puissance de 10, les volumes de données utiles en puissances de 2 en octets; Le port Ethernet ne véhicule pas que les données, il y a aussi les entêtes, les bits de synchro de trames les codes de détection d'erreur, les bits de synchro d'horloge, et on peut estimer à environ 10% le surcout, donc pour 784 megabit/s de données utiles, il y a environ 866 bit/s de bits Ethernet, ce qui en fin de compte n'est pas mauvais du tout en tenant compte des temps de réponse/acquittements des trames en TCP entre le PC et la Box, et le franchissement des parefeux et les surcouts des sécurité de l'OS ou surcouts des couches applicatives ou des transitions user/kernel pour les I/O...)
Note: je veux bien essayer de refaire les tests en mettant la Freebox cette fois en mode bridge le temps des tests au moins ça éliminera les bogues de la partie routeur même s'il reste des bogues dans la partie switch, et un bogue explicable dans le test local qui affiche une taille de fichier de 1 Go (1 gibioctets en puissance de 2) alors qu'il s'agit seulement de 1 gigabit (en puissance de 10) ou que le générateur de données répétitives de ce test en est bogué (mauvais script de génération côté serveur Web intégré).
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 20:18 Sujet du message:
170468156571
Underground78 a écrit:
J'ai pas lu les messages mais vu les témoignages multiples concernant la région de Niort c'est très certainement une rupture de Fibres ou un équipement en panne qui a fait perdre de la capacité vers Paris.
La plaque n'est pas complètement coupée mais fonctionne en mode dégradé. Même si la Hotline n'est pas au courant ça ne veut pas dire que le problème n'est pas connu chez Free (je suis sûr à 99% qu'il l'est).
J'ai bien l'impression que c'est un gros bogue des nouveaux routeurs de Free pour la collecte en IPv6 des NRA/NRO lié à la non prise encharge (pourtant obligatoire) de PMTUD (blocage complet d'ICMPv6 sur leur parefeu).
Dans ce cas l'anomalie est sérieuse car ça va concerner énormément d'abonnés Fibre et ADSL (hors des zones Fibres en zone très dense): Free est en train de migrer tout le monde dans les ZMD en collecte full IPv6 (plus le routage simplifié d'IPv4 par un algo simple de traduction d'adresses IPv4 utilisant aussi les 2 bits de poids fort des ports TCP et UDP puisqu'il veut partager les adresses IPv4 entre 4 abonnés une fois la collecte en IPv6 possible et activée, méthode pas applicable du tout aux trames ICMPv6 et même pas standardisées pour ICMPv4 car il n'y a pas de port mais une traduction nécessaire des types standards de trames ICMP, ce qui nécessite de transiter par un tunnel, aucun des transitaires pour les ZMD ne pouvant accepter des flux ICMP avec des types non standards, et aucun moyen connu de faire cette traduction/adaptation en ICMPv6).
La désactivation d'IPv6 conseillée à Paris ou dans les ZTD est à proscrire partout ailleurs dans les ZMD et n'apporte aucun bénéfice, elle dégrade même le service. L'autre nouveauté en cours de déploiement est que dans les ZMD l'IPv4 attribuée est partagée entre 4 utilisateurs (4 fois moins de ports en UDP et TCP), mais là on peut encore demander à avoir une IPv4 full dans l'interface client (c'est mon cas: l'IPv4 demande une translation d'adresse un peu plus complexe pour convertir en IPv6 et l'acheminer, mais Free semble avoir voulu encapsuler 1 trame IPv4 dans 1 trame IPv6, et si les MTU sont mal gérées et pas rapportées correcdtement au client, et que le PMTUD nécessaire en IPv6 n'est pas supporté du fait du blocage des trames ICMPv6 dans les routeurs de Free, le résultat c'est catastrophique... Free a sans doute voulu éviter d'utiliser une vraie encapsulation IPv4 sur IPv6 par un tunnel standard et une couche d'adaptation en croyant bien faire et il s'est planté (on ne dit pas chapeau aux ingénieurs de Free qui ont pondu ça et l'ont déployé sans tests réels pour voir si les réseaux transitaires allaient accepter ça sans réagir alors que Free abuse forcément les normes de ces autres réseaux! On voit le résultat: trafic bloqué et Free obligé d'établir d'urgence des VPNs nettement plus lents)
Au fait je ne l'ai pas dit, j'ai une "Freebox Revolution", pas la "Freebox Mini 4K". Si le non conformité du trafic IPv6 vient d'un bogue du firmware 3.5.2 de la Freebox Revolution, puis un changement de firmware pour activer un mode de fonctionnement sur ses routeurs de collecte en ZMD, tout le monde n'est pas affecté (et ceux qui sont en ZTD Fibres ne le sont pas non plus): en ZMD, Free doit passer par des réseaux transitaires tiers, il doit se conformer aux normes. Il n'est pas dit que vous ne voyez pas ce bogue sur une Freebox Mini 4K n'ayant pas ce bogue (dans ce cas ça passe sans problème avec le routage normal sans devoir passer par le VPN établi d'urgence par Free pour les clients ayant une Freebox Revolution en ZMD, sinon ces box ne seraient plus joignables du tout).
Je m'attend assez rapidement à une mise à jour de firmware de la Freebox, mais Free devrait déjà communiquer dessus et ne pas faire l'autruche en disant sur son site et à son support qu'il n'y a aucun problème sur son réseau. Et donner des préconisations pour palier en partie le problème pour ceux qui ont la possibilité technique de changer des réglages par défaut.
Dernière édition par verdy_p le Mer 02 Mai 2018, 20:36; édité 1 fois
Fuli, Posté le: Mer 02 Mai 2018, 20:33 Sujet du message:
1469712956
Plus de 10 lignes je n'arrive pas à lire.
Le fichier de test de 1 Go fait 1 Go exactement. Si ce n'est pas le cas c'est qu'un truc sur le lien fbx <-> PC est moisi.
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 20:40 Sujet du message:
170468156571
Fuli a écrit:
Plus de 10 lignes je n'arrive pas à lire.
Le fichier de test de 1 Go fait 1 Go exactement. Si ce n'est pas le cas c'est qu'un truc sur le lien fbx <-> PC est moisi.
ou que la Freebox a un problème de firmware: j'ai demandé déjà à Free de recharger le firmware. Mais visiblement je ne suis pas le seul dans l'agglo de Niort.
Tout fonctionnait très bien vendredi soir et plus samedi matin. Je me demande quel ingénieur chez Free a décidé de lancer des migrations juste le premier soir d'un week-end prolongé, sans personne le samedi matin pour analyser le résultat et balancer ça sur le réseau opérationnel chez les clients sans passer par une plateforme de test ou le recrutement de clients volontaires avec un canal de support pour remonter les incidents constatés par eux (c'est ce que fait Orange par exemple avec ses expérimentations "Orange Labs").
Il y a quelques autres bogues remontés aux dev de Free depuis le 26 avril, plus visibles en mode bridge sur la Freebox.
Mais ce que je vois c'est que PMUTD ne fonctionne pas du tout en IPv6 alors que c'est obligatoire de bout en bout selon les normes actuelles. Pour Youtube par exemple, heureusement que Windows dispose de l'algo de détection du bogue PMTUD: il faut activer le "PMTU Black Hole Discovery" (nombre d'optimiseurs pour Windows désactivent cette option pour gagner un chouilla de performance, en pensant que cela ne sert à rien, que les FAI font correctement leur boulot), sinon par exemple les vidéos Youtube hébergées aux USA (sans connexion directe du CDN de Google dans le réseau de Free) ne passent pas du tout. Même Netflix est incapable de livrer son contenu en HD, il est dégradé en SD, et c'est bien ce qu'affiche aussi le test réseau de Netflix (débit là aussi très lent,à peine 50% des 7 mégabits/s demandés, et Free classé aujourd'hui bon dernier de tous les FAI dans le monde).
[HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
EnablePMTUDiscovery=0 ou 1
si on met 0, cela fixe les MTU à 576 octets (taille minimale) et désactive PMTUD.
Mais ça rétablit en grande partie le débit sur Internet (c'est juste une solution de contournement temporaire, la valeur par défaut sous Windows 10 devrait être 1).
Sur le réseau local c'est un peu plus lent, mais pas tellement visible surtout si on est déjà en Ethernet Gigabit. Alors on peut fonctionner en bloquant tout le trafic ICMPv4 ou ICMPv6 sur le parefeu (mais plus question alors de faire des tests de ping ICMP depuis le PC... mais Windows permet de filtrer selon chaque type de message ICMP et permet aussi de les tronquer à 64 octets maxi, ce qui suffit pour faire un test de latence mais ne permet pas à PMTUD de fonctionner, et il doit alors être désactivé comme ci-dessus en utilisant des trames limitées à MTU=576, et donc de la fragmentation si une session TCP démarre avec une MTU trop grosse).
Les "optimiseurs Internet" pour Windows utilisent une autre clé:
il faut la remettre à 1 pour permettre à Windows de découvrir les incohérences de MTU et l'adapter dynamiquement suivant la destination (démarrage de TCP plus lent mais ensuite ça va nettement plus vite avec moins de pertes de trames quand la MTU a été correctement ajustée).
Des paramètres de config TCP/IP équivalents existent aussi sous Linux. Je ne sais pas ce qu'il en est de MacOS, iOS ou Android pour utiliser ces contournements.
J'ai poussé un peu plus loin le problème de gestion des MTU est interne à la Freebox Revolution avec ce firmware 3.5.2, elle fait vraiment n'importe quoi, aussi bien sur le segment du réseau local que sur le segment WAN-Internet, c'est sa pile TCP/IP qui est complètement boguée dans son firmware.
Le contournement ci-dessus (uniquement côté PC sur le LAN) en résoud une partie mais c'est très instable (y compris en IPv4 seulement sur le LAN, même si c'est moins fréquent que si on autorise l'IPv6 sur le LAN, la Freebox se plante complètement et renvoie des paquets mal formés ou dans un état invalide et il manque des trames ICMP essentielles et là je ne parle pas des PING REQUEST et PING REPLY, mais des autres types de paquets ICMP nécessaires à la gestion des MTU).
Bref complètement merdique ce firmware 3.5.2 de la Freebox Revolution, je vais demander à Free de me remettre le firmware d'avant (je pense que c'était le 3.5.0 d'origine lors de la livraison le la mise en route de l'accès Free le 16 avril; pourtant ce firmware 3.5.2 date de début mars, et que ça a merdé quand il l'ont upgradé en 3.5.2 entre vendredi et samedi), d'autant qu'ils n'ont pas fini de déployer partout cette nouvelle version.
Fuli, Posté le: Mer 02 Mai 2018, 22:21 Sujet du message:
1469712956
Pour une fois par curiosité j'ai tout lu la dernière réponse.
Je confirme, à part le premier paragraphe j'ai raison de ne pas lire la suite. Les spéculations sur ce qui se passe chez Free ou sur les raisons du disfonctionnement ne sont d'aucune aide.
Bref oui c'est peut être un pbm de Freebox si le fichier ne fait pas 1 Go, ou de PC. Un test depuis un autre PC/smartphone devrait suffire pour vérifier si 1 Go est bien 1 Go.
Pour reset la box suffit de chercher sur Google comment faire un reset d'usine de la box.
verdy_p (Auteur du topic), Posté le: Mer 02 Mai 2018, 23:52 Sujet du message:
170468156571
J'ai la même chose sur smartphone Android.
Le "Reset d'usine" de la Box ne restaure pas la version avant 3.5.2, il la remet aussitot, c'est la version déployée actuelle, la 3.5.0 précédente n'est pas accessible (ou je ne sais pas comment faire, seul le support de Free pourrait le faire).
Le traçage des MTU confirme que les sessions TCP font du yoyo avec plein de tentatives de reset de la fenêtre TCP pour récupérer la session, redéfinir la MSS à sa taille minimale et la faire croitre doucement à nouveau, et à un moment ces resets ne passent plus, il y a trop de trames hors cadre, la session TCP est coupée sans aucun statut.
PMTUD ne fonctionne pas, pas plus que l'ajustement dynamique des tailles de fenêtre TCP.
ICMP et UDP ont des taux anormaux très élevés de perte de trames. Et pourtant les statistiques Ethernet de la Box relèvent 0 erreurs quelque soit le port, et une synchro Fibre parfaitement stable!
Le VPN lent c'est encore autre chose ça ressemble plusà une rustine pour contourner partiellement le bogue de la partie Switch (ou du parefeu interne de la box) mais elle ne l'évite pas, elle sert juste à augmenter la résistance des sessions au prix d'un fort ralentissement car c'est un vrai goulot d'étranglement et il est surchargé (le bogue doit donc concerner des milliers de clients à Niort et environs en ADSL comme en Fibre)
Maintenant cette Freebox me parait être recyclée avec juste une coque plastique neuve, elle a peut-être des soucis de RAM défaillante sur sa carte mère, mais je doute que ce soit le problème après 15 jours de bonne marche et quand on voit d'autres utilisateurs dans la même zone ayant le même problème (ont-ils eux aussi la même box?).
Free de plus m'a confirmé qu'il avait effectivement installé un firmware dessus dans la nuit de vendredi à samedi (par un robot). Je ne sais pas dire quel était la version d'avant.
Vous pouvez poster de nouveaux sujets dans ce forum Vous pouvez répondre aux sujets dans ce forum Vous pouvez éditer vos messages dans ce forum Vous pouvez supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum
FAQ
Rechercher
Liste des Membres
Groupes d'utilisateurs
S'enregistrer
, je suis le post uniquement en voyant tes réponses , je ne lis même plus ses posts 