La Fibre

Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => Free Incidents Free => Discussion démarrée par: Lemmiwinks le 28 avril 2017 à 16:58:41

Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: Lemmiwinks le 28 avril 2017 à 16:58:41
Bonjour tout le monde,

J'habite en ZMD dans une commune fibrée par Orange en cofinancement avec Free (zone AMII) il y a un peu plus d'un an.
Ma connexion à la fibre Free a été réalisée début décembre 2016, jusque ici, tout se passait bien.

Mais depuis plusieurs jour, je constate des lenteurs de navigation web, des flux vidéos dégradés et très lents, voire des pages qui ne se chargent pas à certaines heures de la journée.
En effectuant des tests de ping sur l'IP d'un serveur DNS Free (212.27.32.2) je constate un nombre important de paquets perdus (jusqu'à 30%).
Les latences de ping, au moment où se produisent les lenteurs, se rallongent de 3ms en temps normal à 15 ou 20 ms.
Les tests de débit en ethernet réalisés sur speedtest sont très irréguliers, de 0,6 Mbps à 166 Mbps en descendant en passant par des valeurs intermédiaires à chaque essai.
De 3,5 Mbps à 237 Mbps en ascendant, avec des pings soit de 3ms (avec un débit maximum) soit de 15ms (avec des débits faibles).

Le 3244, ne voit rien d'anormal (je suis à pas loin d'une dizaine d'appels, comme à chaque fois on a des infos différentes, on réessaie...)
Un technicien est venu remplacer le module SFP de mon Freebox Server R1, sans rien constater d'anormal sur mon installation mais pas de changement.

J'ai testé:
- Test de ping et speedtest sur 2 PC différents, sous Win7 et sous GNU/Linux Trisquel
- Derrière un switch et en connexion ethernet directe, en ne branchant que la machine de test
- Remplacement des câbles ethernet
- Permutation des Freeplugs
- Réinitialisation usine du Freebox server
- Test de ping de l'adresse IP publique de ma Freebox depuis mon smartphone en 4G Free Mobile : perte de paquets.

La réponse de la hotline est qu'ils ne peuvent rien faire, mon problème serait plus ou moins imaginaire car leurs outils indiquent que tout va bien.

Quelqu'un d'autre est-il touché?
Quelqu'un aurait-il des pistes?
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 28 avril 2017 à 17:11:19
Cela a tout l'air d'un problème de saturation, perte de paquets, hausse du ping... Même ton débit max en download, 166 Mb/s, est très bas pour du FTTH 1 Gb/s, et 0.6 Mb/s est misérable. En upload, 237 Mb/s est par contre une valeur tout à fait correcte, mais descendre à 3.5 Mb/s, c'est aussi très bas.

On a déjà vu des problèmes de ce type en ZMD (avec le 10G-EPON et le protocole utilisé, le 4rd, traffic IPv4 encapsulé dans de l'IPv6).

Le 3244 ne peut malheureusement rien faire, et n'a pas les informations pour faire quelque chose. Il a déjà fait déplacer un technicien, c'est déjà bien. Certains sur ce forum peuvent faire remonter ton problème plus efficacement.

Tu es dans quelle zone AMII ? Cela permettrait de demander si d'autres dans la même zone rencontrent aussi ces problèmes.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 28 avril 2017 à 17:51:43
Je vois que tu as rajouté la localisation, Brunoy. Quelqu'un a déjà déclaré la commune dans les ZMD couvertes par Free sur Freepon :

https://freepon.lafibre.info/

Est-ce que tu as le même préfixe IPv6 ? Il n'a pas renseigné le NRO. De quel NRO dépends-tu ?

Tu peux demander un graphe smokeping à Vivien, qui permettra d'avoir un historique de tes temps de réponse au ping et de pertes de paquets :
https://lafibre.info/dns/smokeping.cgi?target=Free
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 28 avril 2017 à 18:02:56
Merci pour tes réponses.
Je te dirais qu'au niveau du préfixe il débute bien par "2a01:e0a" mais le reste ne correspond pas à ce que peux voir dans le détail de ma connexion sous Windows.
Je suis pas super calé en IPv6, si tu peux m'aiguiller...

Pour le NRO, je dirais qu'il n'y a qu'un sur Brunoy:
http://degroupage.online.fr/connex_dslam.php?dslam=2a01:e02:a:1700:fe00::36c&nra=e02-a-1700-36c-Z&periode=C

Pour le Smokeping, et d'après ce que j'ai pu voir, ça n'a l'air de s'appliquer que sur l'IPv4 en ZTD (en tout cas, seuls ces NRO sont visibles dans le menu de navigation de la section dédiée)
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 28 avril 2017 à 18:17:14
En fait, sur francois04, la localisation du NRO n'est indiquée que justement si elle été renseignée sur Freepon. Donc si tu es sur un deuxième équipement ou NRO qui n'a pas été signalé, il ne le sera pas non plus sur le site de francois04.

Si ton adresse IP se poursuit par 8:9000, c'est effectivement le même préfixe que celui déjà déclaré sur Freepon (2a01:e0a:8:9000:). Pour le nom du NRO, tu peux le trouver dans ton interface web de gestion de ton abonnement Free.

Pour le graphe smokeping, il y en a déjà en ZMD Free, en 10G-EPON. Je pense que là (et j'en suis même quasi sûr), que c'est l'adresse IPv6 qu'il faut donner à Vivien. Celle IPv4 ne répond pas au ping, et de toute façon, elle est par défaut partagée entre 4 abonnés.

https://lafibre.info/dns/smokeping.cgi?target=Free.FTTH
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 28 avril 2017 à 18:31:09
Pour mon préfixe IPv6, il ne correspond pas à celui déjà renseigné...
Je ne vois pas où tu peux trouver le nom du NRO sur ton interface web, tu parles de laquelle? Freebox OS ou l'interface en ligne sur le site de Free? Dans les 2 cas, je ne vois rien.
Tu les vois où les graphes smokeping en ZMD? J'ai l'impression qu'il s'agit de NRO 10G-EPON mais en ZTD...
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 28 avril 2017 à 18:33:14
Ok, c'est bon pour le nom du NRO, c'est dans l'espace abonné sur le site de Free, onglet "Ma Freebox" puis "Afficher mon adresse IP et les caractéristiques de ma ligne"
Je l'ai renseigné sur FreePON.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 28 avril 2017 à 18:46:26
Merci pour Freepon. Donc tu es sur un deuxième équipement (OLT) par rapport à celui déjà signalé et tes problèmes ne sont peut-être pas rencontrés sur l'autre équipement.

Pour le graphe smokeping, quand tu vois mentionné 10G-EPON, c'est une technologie qui n'était jusqu'ici utilisée qu'en ZMD (depuis peu elle commence à l'être en ZTD). Tu vois d'ailleurs que le premier graphe est précédé de la mention 'IPv6'. Quelque soit l'endroit d'ailleurs, ZMD ou ZTD, si c'est le 10G-EPON (et en fait le protocole 4rd) qui est utilisé, il faut indiquer l'IPv6, qui est par défaut avec ces technos.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 28 avril 2017 à 22:05:44
Sinon, pour essayer d'avancer un peu dans le diagnostic de ton problèmes, on peut essayer quelques petits tests.

D'abord un traceroute, en ligne de commande pour essayer de déterminer où sur le chemin peut se situer le problème. Tu peux faire un test en Ipv6 et un en Ipv4(différenciés par le -6 et -4), sur le site de Free pour rester sur son réseau :

$ traceroute -6 www.free.fr
et en IPv4 :

$ traceroute -4 www.free.fr
dont tu pourras recopier ici la sortie, en masquant la fin de ton adresse IP, pour préserver ton anonymat. A noter que je ne crois pas trop à ces tests, car en ZMD, avec le 4rd, le tunnel ressort à Courbevoie, sur un routeur Free.

Et aussi un test de débit en utilisant aussi un utilitaire en ligne de commande qui va moins dépendre d'un navigateur, wget (apt-get install wget s'il n'a pas été installé), pour télécharger un fichier de test sur le site test-debit de Free, en redirigeant vers le "vide" (-O /dev/null), pour ne pas écrire sur le disque, et donc ne pas dépendre de la vitesse du disque :

$ wget -O /dev/null http://test-debit.free.fr/1048576.rnd
L'utilitaire a aussi porté sous windows :

https://eternallybored.org/misc/wget/

Les différents fichiers possible (tu peux prendre une taille plus petite, celui indiqué fait 1 Gb, si ton débit est trop faible), sont indiqués ici. Le nom, c'est la taille :

http://test-debit.free.fr/

Vivien a aussi publié aujourd'hui un tutoriel pour faire des tests de débit avec un autre utilitaire, curl :
https://lafibre.info/tester-son-debit/curl-upload/new/?topicseen#new
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 29 avril 2017 à 13:50:43
Merci pour les liens.

Je commence à piger que le problème vient de la saturation des équipements Free.
On a l'habitude que Free se défausse de toute responsabilité alors qu'ils savent très bien où se situe le dysfonctionnement.
Ils sont concentrés sur le déploiement de la fibre et ne semblent pas en mesure de s'occuper de la maintenance ou de l'augmentation des capacités de transport de leurs infrastructures, certes récentes mais déjà existantes, ce n'est pas leur priorité.

Deux éventualités:
- soit leur capacité d'approvisionnement en équipements réseau est limitée donc ils se concentrent sur les déploiement (ça fait plus sérieux, ça permettra d'annoncer des bons chiffres de déploiement au détriment de la qualité de service)
- soit c'est au niveau de la capacité en ressources humaine (pour les mêmes motifs, priorisation au déploiement)

On m'a répondu que mon accès était sans doute dégradé mais pas en rideau, je devais donc m'en satisfaire.
On m'a aussi expliqué que Free n'avait pas possibilité de faire intervenir, ni même de rentrer en contact avec Orange (leur prestataire chargé de la collecte qui a une obligation de fourniture de service, non?)
Quand on a le décodeur Free, on comprend qu'ils essaient de gagner du temps et que Orange n'est sans doute pas en cause...

J'ai reçu une freebox server de remplacement ce matin, mais je constate toujours des déconnexions dans l'historique de Freebos OS.
Des lenteurs de navigation, des erreurs 404 à un moment pendant une poignée de minutes...

Sinon pour les test, voilà les résultats:
# traceroute -6 www.free.fr
traceroute to www.free.fr (2a01:e0c:1::1), 30 hops max, 80 byte packets
 1  2a01:e0a:e:f****** (2a01:e0a:e:f******)  0.350 ms  0.335 ms  0.508 ms
 2  * * *
 3  2a01:e02:a:1700::ffff (2a01:e02:a:1700::ffff)  2.752 ms  3.945 ms  3.931 ms
 4  * * *
 5  2a01:e00:18::6 (2a01:e00:18::6)  3.655 ms  4.065 ms  4.037 ms
 6  2a01:e00:1c::a (2a01:e00:1c::a)  3.750 ms  3.466 ms  3.434 ms
 7  www.free.fr (2a01:e0c:1::1)  2.872 ms  2.976 ms  2.945 ms

# traceroute -4 www.free.fr
traceroute to www.free.fr (212.27.48.10), 30 hops max, 60 byte packets
 1  192.168.0.254 (192.168.0.254)  0.197 ms  0.378 ms  0.376 ms
 2  194.149.164.56 (194.149.164.56)  3.347 ms  3.356 ms  3.336 ms
 3  p11-9k-1-be1000.intf.routers.proxad.net (78.254.249.130)  4.231 ms  4.744 ms  4.738 ms
 4  bzn-9k-2-sys-be2001.intf.routers.proxad.net (194.149.161.246)  4.716 ms  4.681 ms  4.700 ms
 5  www.free.fr (212.27.48.10)  3.771 ms  3.981 ms  3.962 ms

Pour ce qui est des tests de débit, c'est très aléatoire:
# wget -O /dev/null http://test-debit.free.fr/1048576.rnd
--2017-04-29 12:54:07--  http://test-debit.free.fr/1048576.rnd
Résolution de test-debit.free.fr (test-debit.free.fr)… 2a01:e0c:1:1598::3, 212.27.42.153
Connexion à test-debit.free.fr (test-debit.free.fr)|2a01:e0c:1:1598::3|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1073741824 (1,0G) [text/plain]
Enregistre : «/dev/null»

100%[==========================================================================================>] 1 073 741 824 74,4MB/s   ds 16s   
2017-04-29 12:54:23 (64,1 MB/s) - «/dev/null» enregistré [1073741824/1073741824]

100%[==========================================================================================>] 1 073 741 824 51,8MB/s   ds 19s   
2017-04-29 12:55:26 (54,7 MB/s) - «/dev/null» enregistré [1073741824/1073741824]

100%[==========================================================================================>] 1 073 741 824 49,0MB/s   ds 39s   
2017-04-29 12:56:55 (26,2 MB/s) - «/dev/null» enregistré [1073741824/1073741824]

Je crois que c'est clair, y'a une congestion évidente du réseau.
Combien de temps leur faudra t-il pour réagir?
On ne le saura que quand ce sera réglé.
Un fournisseur d'accès internet qui nous vend de l'accès à la communication et qui n'est pas capable lui même de communiquer.
Comme un gosse qui a fait une connerie et qui veut pas avouer en attendant que ça se tasse...

Je vais guetter les autres sujets d'abonnés qui se plaignent de ce genre de problème et va falloir qu'on mette ensemble la pression sur Free, ils ne comprennent que le rapport de force, c'est dommage.

Je vais essayer de voir avec mes voisins fibrés que je n'ai pas encore croisé.

Merci encore pour ces instructions de test et bon weekend.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Jojo78 le 29 avril 2017 à 14:24:33
Citer
On m'a aussi expliqué que Free n'avait pas possibilité de faire intervenir, ni même de rentrer en contact avec Orange (leur prestataire chargé de la collecte qui a une obligation de fourniture de service, non?)
Quand on a le décodeur Free, on comprend qu'ils essaient de gagner du temps et que Orange n'est sans doute pas en cause...
Si free a laissé entendre que orange est en cause, c'est un mensonge.
En amii orange, notamment, free est celui qui gère tous les équipements actifs concernant les clients finaux. orange ne fait que fournir le lien fibre passif entre le nro et le client final...
Ragardes papa33, il a lui aussi des soucis comme plein d'autres d'ailleurs.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: romeo_en_skate_board le 29 avril 2017 à 14:27:29
bonjour

je prends connaissance de vos messages. J'ai palié le souci de la manière suivante :

tous les 6/9 jours, j'appelle la plateforme en m'étonnant que ma bande passante soit si basse....
Curieusement pour les 6/9 jours suivants la BP est de nouveau correcte.

Free est comme un géant que l'on veut déplacer :
il y a une énergie énorme à développer pour obtenir sa cohésion. Une fois obtenue on a des résultats.

Honnêtement, étant un freenaute de la 1ère heure, je ne pense plus que free soit intéressant comme FAI principal :
matériel devenant obsolète " freebox revo et 4K" pas spécialement performant
refus de fibrer les immeubles déjà impactés ( depuis 2 ans je me bats pour avoir la fibre alors que mes voisins du dessus et dessous l'ont par Orange...

Je serai étonné, d'autant qu'il plane des bruits de rachat de free par un autre opérateur dans les milieux financiers, que vous réussissiez en ce moment à obtenir gain de cause...

merci à vous de nous tenir informés.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 29 avril 2017 à 14:33:29
Je constate que les résultats sont quand même meilleurs qu'annoncés. Le traceroute est très bon, ~3ms pour atteindre la destination, que ce soit en IPv6 ou en Ipv4. Pour le débit, en Mo/s, il faut donc multiplier par 8, on est à 600 Mb/s pour le premier test, et aux environs de 400 Mb/s pour les deux autres. C'est à peu près ce que constatent d'autres en ZMD Free. C'est sûr que l'on est loin du Gb/s annoncé (disons 930 Mb/s de façon réaliste), mais c'est mieux que les 160 Mb/s, débit max annoncé dans le premier post. Peut-être que le disque, ou l'antivirus ?, participent à la limitation du débit ? Tu as quoi comme PCs ?

Et puis évidemment, on est plutôt en heure creuse, vers 13h, un samedi de long week-end. Il faudrait recommencer ce soir, et surtout le plus représentatif, mardi soir, après la fin du week-end.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 29 avril 2017 à 14:44:03
Bonjour romeo_en_skate_board,

Pour ce qui est de contacter Free pour déclarer des pertes de débits et de paquets, je l'ai fait plusieurs fois ces derniers jours, je ne constate pas d'évolution. Ces dégradations de qualité de service paraissent se manifester de façon aléatoire pendant des périodes plus ou moins longues.

Je ne peux parler de "bande passante correcte", c'est la stabilité de la connexion qui est en cause.
Un coup tout fonctionne très bien et d'un coup, ça déconne puis ça refonctionne normalement...

Citer
Free est comme un géant que l'on veut déplacer :
il y a une énergie énorme à développer pour obtenir sa cohésion. Une fois obtenue on a des résultats.

Vous êtes Macroniste? Je ne comprend pas bien votre argumentaire ensuite.
Je plaisante bien sûr, c'est juste un petit trait d'humour en rapport avec cette belle actualité.
Pour ce qui est des annonces du monde financier, c'est à prendre avec des pincettes, entre susciter l'envie d'investissement d'un coté et ceux qui auraient un intérêt contraire, ce ne sont que des effets d'annonce destinés à pousser vers une certaine évolution du marché.

Je vous tiendrai informé dès qu'il y aura du nouveau.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 29 avril 2017 à 14:55:00
Je constate que les résultats sont quand même meilleurs qu'annoncés. Le traceroute est très bon, ~3ms pour atteindre la destination, que ce soit en IPv6 ou en Ipv4. Pour le débit, en Mo/s, il faut donc multiplier par 8, on est à 600 Mb/s pour le premier test, et aux environs de 400 Mb/s pour les deux autres. C'est à peu près ce que constatent d'autres en ZMD Free. C'est sûr que l'on est loin du Gb/s annoncé (disons 930 Mb/s de façon réaliste), mais c'est mieux que les 160 Mb/s, débit max annoncé dans le premier post. Peut-être que le disque, ou l'antivirus ?, participent à la limitation du débit ? Tu as quoi comme PCs ?

Et puis évidemment, on est plutôt en heure creuse, vers 13h, un samedi de long week-end. Il faudrait recommencer ce soir, et surtout le plus représentatif, mardi soir, après la fin du week-end.

Je reprécise, les problèmes constatés apparaissent de manière aléatoire.
Ca fonctionne très bien, d'un coup ça déconne (pages qui ne chargent plus, erreurs 404) les pings se rallongent et les requêtes ping n'aboutissent pas dans 10 à 30% des cas, puis ça se remet à fonctionner correctement.
Et ça plusieurs fois dans la journée, aggravé au moment des pics importants de trafic.

Qu'est-ce que vous avez tous avec les débits?
Je ne cherche pas à avoir la plus grosse, je veux un traffic stable à toute heure de la journée comme Free me l'a fourni pendant des mois en FTTH.
J'avais une meilleure qualité de service en ADSL et même si les débits étaient beaucoup plus faibles.

Pour répondre à Jojo, Free ne laisse rien entendre, vous les connaissez, non?
Ils laissent sous entendre que ce n'est pas de leur ressort, tirez-en les conclusions que vous voulez...
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: romeo_en_skate_board le 29 avril 2017 à 16:12:13
Bonjour romeo_en_skate_board,

Vous êtes Macroniste? Je ne comprend pas bien votre argumentaire ensuite.
Je plaisante bien sûr, c'est juste un petit trait d'humour en rapport avec cette belle actualité.
Pour ce qui est des annonces du monde financier, c'est à prendre avec des pincettes, entre susciter l'envie d'investissement d'un coté et ceux qui auraient un intérêt contraire, ce ne sont que des effets d'annonce destinés à pousser vers une certaine évolution du marché.

Je vous tiendrai informé dès qu'il y aura du nouveau.

cELLE LÀ on ne me l'avait jamais faite encore
mais oui c'est peut-être d'actualité mais imaginez que je vous dise non  je ne le suis pas...
et voilà que je m'aliène la moitié au moins du forum
Attention. hein je vais vous signaler hein.....
je suis MDR


plus sérieusement, j'ai constaté que l'on avait plus souvent des techniciens en fin de journée ( de Free bien entendu:)
pour orange, la nuit était meilleure conseillère pour avoir un technicien réseaux et télécoms vers 2 4h du matin.

le tout avec Free est de lui dire, je ne comprends pas, la bande passante par mes tests ( et on fait plusieurs sites) me donne ça ...
vous vous me dites ....
Curieusement, si je compare vos chiffres avec les miens sur plusieurs sites, vos chiffres sont systématiquement remis en cause tant par les freenautes que par les sites de tests sfradsl, speed.... etc.
J'ai toujours pratiqué cette démarche de comparaison. Pour moi elle porte effet.

Concernant la mise en vente ou pas de Free,
lorsque la rumeur vient de la toile grand-public je suis d'accord
mais si des sites spécialisés bancaires ou investisseurs interviennent il n'est pas bon choix que d'ignorer ces interventions pour un investisseur.
Vous connaissez LDLC ? Pendant des mois la rumeur a laissé entendre qu'il serait racheté par MATERIEL je ne sais plus quoi.
En février 2016, il y a eu 3 entre filets dans les sites liés à la Bourse et au rachat ... 5 lignes environ pour dire que LDLC était acquéreur. En mars de la même année, le mariage était fait sous LDLC rachète ...
Donc non les grandes déclarations fracassantes ne sont pas à prendre en considération.
Le diable se cache dans les détails...

Par contre je suis interpellé par ce que tu dis ici :
"  Je ne peux parler de "bande passante correcte", c'est la stabilité de la connexion qui est en cause.
Un coup tout fonctionne très bien et d'un coup, ça déconne puis ça refonctionne normalement..."


Il y a quelques années, j'avais une situation comme la tienne, j'étais chez Orange alors FT. J'en ai tellement marre que je les ai quitté pour FREE. j'avais des pertes de porteuse (entre box et dslam) des coupures de téléphones...
J'ai mis en cause FREE qui m'a renvoyé vers FT qui a fait venir un technicien.
Mes coupures venaient simplement du fait que la ligne téléphonique PHYSIQUE tapait avec le vent contre l'arête du coin de l'immeuble et que, petit à petit, le cable en cuivre intérieur de la gaine extérieure, à force d'être tapé ainsi se coupait.

Le technicien est resté 20 minutes, a changé tout le cable et l'a fixé.
Aux résultats : FT qui gagnait alors 2000/mois pour les appels m'a perdu au profit de FREE.

Donc regarde par ta fenêtre si ton cable est fixé, s'il bouge avec le vent....
Si tu es en maison, regarde le câble sortir de chez toi jusqu'au boitier puis du boitier jusqu'au poteau. Si tu trouves que cela flotte trop à ton goût c'est que peut-être cela vient de là.
Et s'il est enterré, vérifies qu'il ait été enterré selon les normes et non suivant un bricolage de bricolo donc au minimum 1.5m de profondeur. Si c'est du bricolage, vérifies qu'un coup de bêche ou un stationnement de voiture ne l'ai ni sectionné partiellement ni écrasé par le poids....
Si c'est correctement fait, tu dois avoir un filet avant d'apercevoir le cable...
Tu peux aussi vérifier cela avec un voltmètre ohmètre :
de mémoire - les gars de la fibre te le diront ici - tu cherches quels fils amènent le courant.
Mode d'emploi
tu cherches le + et le - dans les fils de ta prise téléphonique
j'ai oublié la norme de l'impédance au repos
mais tu prends ton portable et tu appelles ton numéro adsl ou fixe ( si c'est un portage)
tu verras alors l'aiguille monter et s'affoler...
cela simplement t'indique que le courant arrive chez toi par le téléphone.
je crois que c'est 15v en sonnerie mais d'autres te le diront avec exactitude...
Cela permet d'active la sonnette extérieure du téléphone.
Du moment que tu ne mets pas en contact le + et le - La démarche n'a pas de conséquence si tu sais te servir de cet appareil. Sinon laisses tomber et demandes à un copain.

Désolé de ne pas approfondir mais je n'ai plus le temps. Regardes à tous hasard ds ggle  cablage téléphonique + tension repos tension sonnerie
J'espère avoir répondu à des questions. Tiens nous au courant
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 29 avril 2017 à 16:37:52
Dis Romeo, tu ne confondrais pas cuivre et FTTH ? Ici, c'est du FTTH (en ZMD).
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 29 avril 2017 à 17:17:39
Dis Romeo, tu ne confondrais pas cuivre et FTTH ? Ici, c'est du FTTH (en ZMD).
C'est exact!
Pour info, le technicien free qui est passé il y a trois jours a testé l'affaiblissement: 17dB (en sortie de jarretière, juste avant l'ONU)
C'est un affaiblissement normal d'après lui (faudrait s'inquiéter au delà de 20-21dB...)
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 29 avril 2017 à 17:42:01
En fait, cela doit être des valeurs négatives, -17 db. Plus l'affaiblissement est petit, plus la valeur en db (négative) est petite. Effectivement, -17 db, cela me parait très bien. (db = 10 log(P reçue/ P émise), P reçue < P émise, donc x < 1, log(x) < 0)

Voir :
https://lafibre.info/dorsale-internet/la-notion-daffaiblissement-pour-la-fibre/msg59228/#msg59228
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Nico le 29 avril 2017 à 18:51:41
On m'a aussi expliqué que Free n'avait pas possibilité de faire intervenir, ni même de rentrer en contact avec Orange (leur prestataire chargé de la collecte qui a une obligation de fourniture de service, non?)
Oh j'avais loupé ce passage, joli bullshitage en règle !
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Jojo78 le 29 avril 2017 à 19:05:22
Ils laissent sous entendre que ce n'est pas de leur ressort, tirez-en les conclusions que vous voulez...
C'est du 1er degré?
Parce que si oui, malheureusement, free raconte n'importe quoi.
Si c'est du second degré, bah effectivement ils racontent n'importe quoi.
Bonne chance...
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: alain_p le 29 avril 2017 à 19:25:23
De toute façon, la HotLine confond encore bien souvent FTTH et xDSL, malheureusement...
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 03 mai 2017 à 10:54:41
Bonjour,

Quelqu'un aurait-il de nouvelles infos?
Le problème n'est toujours pas réglé.

Quand les perturbations se produisent, l'OLT sur lequel ma box semble être connectée (du moins le premier équipement actif après ma box selon le traceroute, qui semble correspondre à l'OLT selon françois04)
http://degroupage.online.fr/connex_dslam.php?nra=e02-a-1700-3b4-Z (http://degroupage.online.fr/connex_dslam.php?nra=e02-a-1700-3b4-Z)
Détermination de l'itinéraire vers 2a01:e02:a:1700:fe00::3b4 avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  2a01:e0a:e:*:*:*:*:*
  2     *        *       11 ms  2a01:e02:a:1700:fe00::3b4
soit ne répond pas, soit sa latence augmente.
**** 03/05/2017 - 09:28 ****

Détermination de l'itinéraire vers 2a01:e02:a:1700:fe00::3b4 avec un maximum de 30 sauts.

  1  Erreur de transmission : code 1231

Itinéraire déterminé.

---

Envoi d'une requête 'Ping'  2a01:e02:a:1700:fe00::3b4 avec 32 octets de données :
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=2 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=3 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms

Statistiques Ping pour 2a01:e02:a:1700:fe00::3b4:
    Paquets : envoyés = 65, reçus = 18, perdus = 47 (perte 72%),
Durée approximative des boucles en millisecondes :
    Minimum = 0ms, Maximum = 3ms, Moyenne = 0ms

Envoi d'une requête 'Ping'  2a01:e02:a:1700:fe00::3b4 avec 32 octets de données :
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=18 ms
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1028 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=32 ms
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=6 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=9 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=4 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Délai d'attente de la demande dépassé.
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=10 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=6 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=13 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=4 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=9 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=13 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=11 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=12 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=10 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=4 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=10 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=9 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps<1ms
Réponse de 2a01:e02:a:1700:fe00::3b4 : temps=1 ms

Statistiques Ping pour 2a01:e02:a:1700:fe00::3b4:
    Paquets : envoyés = 100, reçus = 88, perdus = 12 (perte 12%),
Durée approximative des boucles en millisecondes :
    Minimum = 0ms, Maximum = 1028ms, Moyenne = 17ms

J'attends un technicien qui doit venir remplacer l'ONU.
Si seulement ça pouvait être ça!
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: paokouran le 03 mai 2017 à 14:13:58
ésalut Lemmiwinks

alors moi j'habite à crosne, même nro même déploiement etc et aussi même soucis depuis environ une semaine un coup on a 200 meg un coup 0,5 un coup en up un coup en down...

tech est deja venu aussi, a refait les soudures pour rien etc etc

moi ce qui me dérange c'est que la tv free (sur boîtier 4k) elle marche très bien et non stop pas un freeze rien "lol" alors que dans le même temps t'arrives pas à afficher une page web...  rien que ça on imagine bien un delire sur le réseau alors quoi j'en sais rien mais de mon point de vue ce n'est pas un soucis matériel, tout le monde plaide sur l' ONU moi je demande à voir mais ça m'étonnerai... ( il aurait claqué en même temps pour toi et moi alors hummm...)

je sais que ça va rentrer dans l ordre perso je sais juste pas quand, hier soir ras 0 soucis j ai pu regarder mon iptv perso en full hd sans soucis 0 freeze etc, 1 ère fois depuis une semaine ... wait and see

ps: je mets un petit screenshot de mes tests de debit du 29/04

++
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 03 mai 2017 à 14:25:52
Salut Paokouran,

J'ai eu quelques infos de la part du responsable technique du secteur.
Ils auraient identifié un problème sur le NRO qui est en cours de résolution...

Pour le coup de la TV qui fonctionne alors que le reste déconne, c'est sans doute dû à la priorisation de certains flux sur le réseau:
https://youtu.be/eKFjW2IqJI4?t=13m58s (https://youtu.be/eKFjW2IqJI4?t=13m58s)

et au cache du flux TV suffisamment important pour que les coupures soient invisibles.

Tu es sur le NRO 91114BRN ?
Par contre, on doit être connectés à des OLT (équivalent des DSLAM pour la fibre) différents, enfin je pense...
Sur Brunoy, il y en aurait au moins 2.

T'as renseigné tes données (sans oublier le code de ton NRO) sur https://freepon.lafibre.info/ (https://freepon.lafibre.info/) ?
Je t'invite à le faire pour permettre d'avoir un meilleur visu sur le déploiement de la zone.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: underground78 le 03 mai 2017 à 14:26:31
Si vous êtes deux à avoir le soucis dans la même ville et que le problème persiste, ça pourra valoir le coup d'ouvrir un sujet dans le forum de l'ADUF sur lequel une personne de Free intervient régulièrement.
Titre: Lenteurs de navigation et perte importante de paquets en ZMD
Posté par: Lemmiwinks le 03 mai 2017 à 14:28:00
Merci underground78, c'est déjà fait:
http://www.aduf.org/viewtopic.php?t=279561 (http://www.aduf.org/viewtopic.php?t=279561)
Titre: Lenteurs de navigation et perte importante de paquets (ZMD / Val d'Yerres)
Posté par: paokouran le 03 mai 2017 à 14:46:28
J'éditerai mon profil ce soir ;)

y'a du monde qui s'occupe du soucis j'en doute pas :)

a+
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: Lemmiwinks le 03 mai 2017 à 16:48:52
Passage à l'instant d'un technicien Free.
Installation d'un nouvel ONU et d'une jarretière optique neuve.
Démarrage du Freebox Server.
Connexion à Freebox OS.
Bim, une page entière de déconnexions sur l'historique.

A part le cordon d'alim du freeplug, on a tout remplacé ces derniers jours:
- Freebox server
- ONU
- SFP+
- Jarretière optique
- Permutation des freeplugs

Tout laisse à penser que c'est bien du coté des équipements Free et du NRO qu'il faut chercher...
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 03 mai 2017 à 22:05:55
et ça continue ça devient ridicule

sur un test de debit 70 % du test je suis a 0,00 mbits/s WOOOOOOOOOOO bravoooooooooooooo pffff

preuve en image

ps: bien évidemment la tv free marche tout à fait normalement sans coupure ni rien pendant ce temps là hein ... m enerve
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: underground78 le 03 mai 2017 à 22:22:55
Attention à la version 3.4.0 du firmware de la Freebox, il est bogué et provoque des pertes de connexion par moment. Si vous avez un soucis de stabilité de la connexion, n'hésitez pas à rebooter pour être sûr que ça ne vient pas de ça.
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 03 mai 2017 à 22:27:52
hello

je suis en 3.4.1 ... :/

à part attendre on peut pas faire grand chose :)
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: alain_p le 03 mai 2017 à 22:32:41
Les flux TV et Internet passent par deux VLANs (réseaux virtuels différents), 835 et 836. Certains se plaignent de télé qui freeze aux heures de pointe malgré un débit Internet tout à fait suffisant, ~500 Mb/s, pap33, et d'autres, toi, se plaignent d'un débit très faible malgré une TV sans freeze (ce qui est le cas le plus courant).

On peut avoir saturation sur l'un ou l'autre réseau, indépendamment.
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: vivien le 04 mai 2017 à 09:26:46
Les tests SmokePing ne peuvent pas être réalisée sur l'IP partagée de Free.

Je ne me souviens plus si dans le cadre d'une IPv4 dédiée, si c'est la Freebox qui répond au ping.

Je propose de faire :
- Un graphe IPv6
- Un graphe IPv4 si celle ci est dédiée.

Ce qui me faut :
1/ Que vous activiez la réponse au ping sur votre Freebox
2/ Me contacter par MP pour le graphe avec ces 3 informations :
- IPv4 si dédié (elle est visible sur https://ip.lafibre.info/ )
- IPv6 de la Freebox (ou si vous ne la connaissez pas, l'IPv6 tel qu'elle apparaît sur https://ip.lafibre.info/ )
- Votre Ville
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: Lemmiwinks le 04 mai 2017 à 11:55:57
Citer
et d'autres, toi, se plaignent d'un débit très faible malgré une TV sans freeze (ce qui est le cas le plus courant).

Juste pour info, j'ai résilié mes options TV depuis plusieurs mois (donc je peux pas test...)
Mon Freebox Player prend la poussière sous mon meuble TV, j'ai pas de Wii sinon elles y auraient fait une coloc  ;)
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: noctam le 04 mai 2017 à 14:41:38
Paokouran : édit ton commentaire pour effacer ton IP etc. Envoie juste un MP ViVIEN
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 04 mai 2017 à 14:48:36
done noctam, dsl mode speed...

merci
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: neogta le 05 mai 2017 à 15:13:25
bonjour,
j'habites Yerres et suis sur ce NRO également depuis juin 2016,
tout 2016 j'ai eu un débit du style 800 voire 900 en DL et 200 en UL.

Depuis 2017 je suis plus à 400/200.
Mes premiers VRAIS problèmes datent du weekend du 1er mai (débit très aléatoire, reconnexions, etc.) avec une belle coupure pendant plusieurs heures mardi soir.
(bloqué à l'étape 3)

J'ai appelé le 3244 qui m'a dit que le secteur avait un problème mais après débranchement électrique de l'ONU / module optique et rebranchement, c'était reparti.
Depuis debit plutôt stable à 400/120 malgré quelques coupures régulières.

Ce matin 4 heures, coupure totale, je re branche au reveil à 8h, ca fonctionne, re coupure à 10h30.

A 12h30 un technicien free m'a contacté pour m'indiquer qu'il voyait que il y avait un problème chez moi, quelle proactivité !
J'ai rendez vous demain matin 10h avec ce dernier qui vient changer l'ONU.

Je vous tiens au courant !
Younes
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: Lemmiwinks le 05 mai 2017 à 17:37:39
Bonjour neogta,

Je rencontre les mêmes problèmes que toi.
Ne te fais d'illusion quand au remplacement de l'ONU, le mien a été remplacé il y a deux jours mais ça n'a rien réglé au problème.

Ca fait 10 jours qu'on me répond qu'ils sont dessus.
Le responsable technique du secteur est passé chez moi hier pour ne constater aucun défaut dans mon installation et un affaiblissement du signal plus que correct (-13,5dB).

Franchement, je ne sais plus quoi faire, j'ai l'impression qu'ils ne s'en occupent pas et qu'ils essaient de gagner du temps.
Je n'ai aucun retour malgré les dires de plusieurs téléconseillers m'ayant annoncé suivre le dysfonctionnement durant plusieurs jours.
Il m'a aussi été dit qu'ils ne manqueraient pas de me recontacter pour prendre des nouvelles.
Toujours rien, silence radio.

Il paraîtrait que mon cas est isolé.
Pas tant que ça apparemment.

Bon courage!
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: underground78 le 05 mai 2017 à 18:37:06
Si des techniciens passent c'est bien qu'on prête un minimum d'attention à ton problème chez Free.
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: Lemmiwinks le 05 mai 2017 à 19:23:56
Citer
Si des techniciens passent c'est bien qu'on prête un minimum d'attention à ton problème chez Free.

Et quand ça ne règle rien?
C'est quoi cette réponse?
Ma part du contrat est remplie, je paie tous les mois.
A eux de remplir la leur, me fournir un accès correct.
Je peux comprendre qu'il y ait des soucis occasionnels mais là ça dure et on m'enfume!

Heureusement qu'ils prêtent attention à mon problème, faudrait que je les supplie, que je les soudoies?
Free nous a très mal habitués, on devrait être content quand ils s'occupent de nous, alors que c'est juste leur boulot d'opérateur réseau.
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: neogta le 05 mai 2017 à 19:26:15
Bonsoir,
Des nouvelles, c'est fini je n'ai plus du tout internet
Bloqué à l'étape 3 depuis ce matin malgré des reboots
Curiosité, si kkun est ds le même cas, en allant ds le menu tactile puis fibre, ds la partie lasr j'ai rx détecté, tx inactif
Ds la partie état
Alim Ok sfp présent laser détecté signal absent lien down
Et vous ?
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: Lemmiwinks le 05 mai 2017 à 19:34:18
Ma box est restée bloquée en étape 3 cet aprem.
J'ai simplement bien enfoncé les connecteurs de la jarretière optique dans l'ONU et dans le PTO.
Essaie pour voir.

TX inactif, c'est pas normal, le mien est actif.
Signal absent, c'est pas normal non plus.

Essaie de remboiter gentiment la jarretière à fond.
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: neogta le 06 mai 2017 à 10:35:41
Bonjour
Quelques nouvelles, les techniciens free sont passés ce matin changé mon onu qui d'après leur dires était responsable des coupures ds le quartier
Quand j'avais Internet, plus personne ds mon armoire avait internet
Pour l'instant ça fonctionne !
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 06 mai 2017 à 22:15:12
hello

bon pour moi tout marche au moins de manière stable depuis hier soir, bcp moins de débit mais bon pas grave ;)

a confirmer...

merci!

a+
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: alain_p le 06 mai 2017 à 22:52:20
Donc on s'orienterait sur un ONU qui aurait arrosé et pollué l'arbre 10G-EPON, impactant tout le monde sur l'arbre...
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 09 mai 2017 à 12:53:31
bon bah j'ai parlé trop vite lol

étape 3 depuis cette nuit vers 0h10, des furtifs passages avec l heure maintenant ça reste en étape 3, parfois 2 sec je vois la lumière orange et rien de plus ...

alalalala
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: neogta le 09 mai 2017 à 13:56:24
@alain_p c'est ce que m'ont dit les techniciens free et leur responsable

@paokouran, tu as la lumière orange en permanence ou c'est 2 sec sur l'ONU ?
Peut-être que toi aussi ton ONU est foireux et qu'ils t'ont débrancher dans l'armoire en attendant de te le remplacer (c'est ce qui m'est arrivé vendredi soir).

de mon côté, debit stable depuis samedi, par contre la connexion n'est pas vraiment stable, depuis ce matin, déconnexion à 7h27/7h28/11h20/11h41 ...
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 09 mai 2017 à 14:32:50
ola

non tout a marche nickel de vendredi a cette nuit 0h05

actuellement j ai que la lumiere verte et etape 3 treeees rare d avoir la orange....
Titre: Instabilité des connexions sur 91114BRN (Brunoy, Crosne, Yerres)
Posté par: paokouran le 09 mai 2017 à 16:11:41
bon bah c'est revenu pour l'instant ...