La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
ADSL / VDSL => Discussion démarrée par: Happymeal le 28 décembre 2017 à 17:20:29
-
Bonjour,
Je viens de prendre contact avec l'assistance afin d'ouvrir un dossier pour analyse de ma situation sans succès (l'on m'a juste dit on va voir pour faire une analyse, et j'ai de gros doutes)
Voici la situation rencontrée:
Depuis que je suis abonné, je fais du streaming sur la plateforme twitch sans aucune difficulté via le logiciel OBS. Fin de semaine dernière il y a eu une coupure du DSLAM dans mon secteur (le SA213), celle ci a été très rapidement corrigée, cependant depuis je suis dans l'incapacité de stream correctement. Mes débits sont toujours identique, ce n'est donc pas un problème de débits faibles (à savoir que je stream avec un bitrate de 2000 depuis plus de 2 ans). Maintenant, lorsque je lance le stream, au bout d'un laps de temps d'environ 8 à 10mn, OBS se déconnecte par un manque de données à envoyer (mon débit d'envoi sur OBS descend à 0), puis celui ci se reconnecte et le service reprends et ainsi de suite, autant vous dire que cela n'est plus possible de stream dans de bonnes conditions. Je tiens à préciser que je n'ai aucune coupure de services lorsque ce dysfonctionnement survient, de plus mes débits ne fluctuent pas apparemment. A mon niveau, j'ai écarté tout mes éléments internes à savoir réinstallation complète de mon PC (au cas ou), reset usine de la box, changement de l'intégralité du câblage, diminution du débit d'envoi dans OBS etc...Etc... le problème est toujours le même. J'ai indiqué à la plateforme que je ne pouvais pas rester ainsi et j'ai insisté pour l'ouverture d'un dossier. Je suis convaincu que le problème est lié à l'interruption du DSLAM, puisque la veille de celle ci tout allait bien, et le lendemain problème, et depuis incapacité de stream dans de bonnes conditions.
J'ai fait un test sur différents PC, même constat, j'ai testé mon PC sur une autre ligne d'un voisin, aucun soucis.
Après analyse des logs de OBS (que vous trouverez ci dessous), il est clairement mis en évidence le manque de données à envoyer à la plateforme résultant à une déconnexion
Voici les logs de la situation rencontrée:
10:16:42.300: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://live-lhr.twitch.tv/app...
10:16:42.336: [rtmp stream: 'adv_stream'] Interface: Intel(R) Ethernet connexion (2) I219-V (ethernet, 100 mbps)
10:16:43.318: [rtmp stream: 'adv_stream'] connexion to rtmp://live-lhr.twitch.tv/app successful
10:16:43.320: ==== Streaming Start ===============================================
10:24:49.481: WriteN, RTMP send error 10054 (460 bytes)
10:24:49.481: WriteN, RTMP send error 10054 (98 bytes)
10:24:49.481: WriteN, RTMP send error 10038 (42 bytes)
10:24:49.481: [rtmp stream: 'adv_stream'] Disconnected from rtmp://live-lhr.twitch.tv/app
10:24:49.481: Output 'adv_stream': stopping
10:24:49.481: Output 'adv_stream': Total frames output: 13842 (14551 attempted)
10:24:49.481: Output 'adv_stream': Total drawn frames: 14609 (14615 attempted)
10:24:49.481: Output 'adv_stream': Number of lagged frames due to rendering lag/stalls: 6 (0.0%)
10:24:49.481: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connexion stalls: 709 (4.9%)
10:24:49.481: Output 'adv_stream': Reconnecting in 10 seconds..
10:24:49.481: [rtmp stream: 'adv_stream'] Freeing 817 remaining packets
10:24:59.481: ---------------------------------
Avez vous une idée d'une éventuelle solution, car malgré tout mes appels vers free (le dernier en date est de ce matin, et le comble c'est que la personne a bel et bien constaté mon dysfonctionnement mais m'indique être dans l'incapacité d'ouvrir un incident car son logiciel d'analyse ne voit pas ce soucis....)
Merci de m'avoir lu et à bientôt
-
Si tu en as la possibilité: change de FAI.
Les soucis de peering de Free sont bien connus, il a suffit que lors de cette "maintenance" ta route ai changé pour que tu passes par un lien vers Cogent ultra saturé (simple supposition de ma part)
-
Et qu'est-ce qui te fait croire que c'est ça ? Les peerings/Transits de Free ne saturent pas dans le sens Upload. Inutile de conclure ce qui t'arrange.
-
Et qu'est-ce qui te fait croire que c'est ça ? Les peerings/Transits de Free ne saturent pas dans le sens Upload. Inutile de conclure ce qui t'arrange.
Relis bien ma phrase: supposition pas conclusion. J'ai mis en gras et rouge car, à priori, ça t'avait échappé.
-
Quoi qu'il en soit, pour l'instant je ne compte pas encore changer de FAI, j'ai quand même bon espoir que la pseudo analyse que l'on m'a promis puisse aboutir.
Et merci à vous 2 d'avoir pris le temps de répondre.
Ce que je trouve plus qu’aberrant c'est que la personne de ce matin a bel et bien constaté en direct le soucis, et il me dit désolé je peux pas faire d'incident.... Et il ose me dire, vous savez les débits c'est variable, vous ne pouvez pas stream avec vos débits Monsieur, et je lui ai dit mais alors comment se fait il que depuis 2 ans tout se passe bien et que suite à une interruption du DSLAM tout va mal... bizarrement aucune réponse, et bien sur impossible de s'entretenir avec d'autres personnes que les personnes répondant au 3244
-
Si tu pouvais faire un trace-route, ça pourrait orienter les pro-réseau à t'aider à comprendre ce qui ne va pas.
Hugues, malgré sa mauvaise humeur, touche sa bille ;) ;D
Et avant de me faire défoncer --> https://fr.wiktionary.org/wiki/toucher_sa_bille
-
Je pourrai éventuellement faire ceci si vraiment cela est nécessaire (et encore que faire un trace route vers twitch ok car il s'agit de live.twitch.tv mais en ce qui concerne le stream, obs se connecte à un serveur particulier que les devs obs appelent "ingest server" et la j'avoue que je ne sais pas sur quoi faire le trace route), sinon j'ai à ma disposition l'ensemble des logs générés par le soft lorsque le soucis survient. Mais il est presque certains que le soucis est côté FAI, surtout que avant le soucis de DSLAM tout était ok et après ben catastrophe :(, ce qui est navrant car je ne vois pas comment m'en sortir avec eux vu qu'ils veulent pas faire d'incident :D
-
Je dirais plutôt un iperf ou un long upload, un Traceroute n'aidera pas des masses..
-
Je dirais plutôt un iperf ou un long upload, un Traceroute n'aidera pas des masses..
Ah c'est bien ce qu'il me semblait ::)
Par contre je n'ai aucune idée de la procédure pour faire un iperf, et un long upload ben faut disposer d'un emplacement ou upload non ? Ah moins qu'il y ai des outils permettant de faire ceci
-
Tu peux essayer avec testdebit.info :)
-
Lorsque je tente de faire un iperf, cela m'indique que j'ai une connexion refusée, peut etre que la syntaxe que je tente d'utiliser n'est pas la bonne
-
Surtout ne donne pas la commande que tu utilises pour qu'on ne t'aide pas.
-
Surtout ne donne pas la commande que tu utilises pour qu'on ne t'aide pas.
Un peu rude comme réponse....
Enfin bref, voici ce que j'ai essayé de faire
iperf3 -c bouygues.testdebit.info -p 5202 -R -t 20
-
Prend le avec le sourire. Quand on est dans son truc, des fois on en oublie l'essentiel. ;)
Flobaoti m'a en tout cas bien fait rire par son post, c'est le genre d'humour que j'aime.
-
A mon avis l'erreur que tu as obtenue vient juste du fait que le serveur était occupé au moment où tu as fait le test.
Réessaie, éventuellement en changeant de port.
-
Change de serveur de test vu qu'il ne répond pas à l'instant où je viens de tester.
Celui là répond par contre : bouygues.iperf.fr
-
Merci, voilà le retour
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 1.00-2.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 2.00-3.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 3.00-4.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 4.00-5.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 5.00-6.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 6.00-7.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 7.00-8.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 8.00-9.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 9.00-10.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 10.00-11.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 11.00-12.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 12.00-13.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 13.00-14.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 14.00-15.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 15.00-16.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 16.00-17.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 17.00-18.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 18.00-19.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 19.00-20.00 sec 384 KBytes 3.15 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 5.62 MBytes 2.36 Mbits/sec sender
[ 4] 0.00-20.00 sec 5.41 MBytes 2.27 Mbits/sec receiver
J'ai également fait un test sur 180s et le résultat est sensiblement identique... Ce soucis que j'ai depuis l'interruption du DSLAM, j'ai le sentiment que c'est mal barré :(
-
Vu que tu es visiblement en vdsl2, ça serait pas mal de regarder les caractéristiques dans l'interface de gestion de la freebox : il se peut que tu aies des pertes de paquet sans désynchro de ta ligne lorsque tu sollicites "fortement" ton upload.
-
Vu que tu es visiblement en vdsl2, ça serait pas mal de regarder les caractéristiques dans l'interface de gestion de la freebox : il se peut que tu aies des pertes de paquet sans désynchro de ta ligne lorsque tu sollicites "fortement" ton upload.
Apparemment ce n'est pas le cas, j'avais déjà consulté ceci pour voir le comportement. La seule chose que je constate c'est lorsque le soucis survient, l'on voit bien la courbe d'upload qui descend instantanèment à zéro ce qui implique la déconnexion du service et cela revient ensuite et ainsi de suite... Mise à part ceci il n'y a rien de particulier de visible
-
Ok autres piste : changer de serveur de streaming.
J'ai trouvé une liste là : https://boinx.com/connect/mimolive/knowledge/streaming/WS100412
Paris par exemple à tester en premier choix logique
RTMP URL: rtmp://live-cdg.twitch.tv/app
-
Il s'agit des serveurs nommés "ingest server" par le dev de OBS, et jusqu'à présent, j'ai testé PARIS, LONDRE, BERLIN et d'autres, et à chaque fois même constat :D
Et justement dans les logs de OBS le soucis est le timeout sur les servs et l'erreur est bien une erreur RTMP, un peu comme si pendant quelques secondes la route est coupée complétement. J'ai ce matin testé avec d'autres softs de stream, et j'ai également tenté de stream sur d'autres plateformes et c'est exactement pareil, le soucis ne vient clairement pas de chez moi (malheureusement, sinon ça aurai été plutôt simple :p)
En tout cas c'est gentil de ta part toutes ces réponses :)
Ce qui me navre dans cette situation c'est "l'incompétence" de free face à ma situation, sous pretexte que leur soft ne constate pas de dysfonctionnement sur ma ligne à un instant T, ils refusent d'ouvrir un incident, j'ai demandé une analyse mais alors là aucune preuve de la prise en charge, et encore moins de la réalisation de celle ci si jamais ils ont bien pris en compte ma demande, alors que la dernière personne que j'ai eu en ligne m'a clairement dit "oui effectivement j'ai bien vu votre soucis", car je l'ai provoqué en live avec lui au tel, mais non pas de dossier. Que je sache, pas ma faute si le DSLAM a eu un soucis :D
-
Ok donc je vais réinsister pour avoir des captures d'écran de ton interface de gestion de la freebox, en particulier les courbles de la marge de bruit avec l'onglet stats xdsl.
Après si c'est un problème de config du dslam, peut être essayer de forcer la connexion en adsl2+ pendant un jour : faire un test de streaming de plus de 15 min avec l'upload famélique du protocole et puis reforcer le passage en vdsl2.
-
Je dois partir sous peu je ferai ces screens ultérieurement et je testerai egalement de forcer en adsl2 (attention les débits que je vais avoir :D )
-
Une idée, regarde dans ton interface freebox os (et éventuellement abonné), si ton DSLAM n'aurait pas été migré sur un nouveau DSLAM IPv6, avec une adresse IPv4 partagée par 4 utilisateurs (1/4 des ports TCP). Normalement, dans la rubrique freebox, tu devrais avoir à côté de l'adresse IPv4, le range de ports qui t'ait assigné.
Après, je ne suis pas sûr que cela changerait le débit de streaming, mais c'est à vérifier...
-
Une idée, regarde dans ton interface freebox os (et éventuellement abonné), si ton DSLAM n'aurait pas été migré sur un nouveau DSLAM IPv6, avec une adresse IPv4 partagée par 4 utilisateurs (1/4 des ports TCP). Normalement, dans la rubrique freebox, tu devrais avoir à côté de l'adresse IPv4, le range de ports qui t'ait assigné.
Après, je ne suis pas sûr que cela changerait le débit de streaming, mais c'est à vérifier...
Aucun soucis de ce côté là, j'avais déjà regardé ceci.
Cependant, je viens de demander le forcage en ADSL2 comme l'on m'a proposé plus tôt nous verrons bien demain ce qu'il en est avec ensuite un passage à nouveau au VDSL2, et concernant les screens les voici:
http://hpics.li/cba558e
http://hpics.li/655ea9d
http://hpics.li/1bd4584
Sur le screen des courbes de débit, les descentes d'upload correspondent à mon soucis lorsque je fais tous mes tests, et l'on voit bien que je suis à fond et d'un coup chute à zéro et bim catastrophe :D
-
Merci pour les screenshots.
On voit bien que le nombre de rtx_uc semble élevé :
rtx_tx = Count of retransmitted DTUs.
rtx_c = Count of detected and corrected retransmissions.
rtx_uc = Count of detected DTU errors which have not been corrected within the delay_max constaint.
Donc c'est normal que ça bloque, ça devrait même afficher des erreurs CRC qui ne s'affichent pas (je ne sais pas trop pourquoi)
Je me base sur ce site http://www.kitz.co.uk/adsl/retransmission.htm#how-retransmission-works
Par ailleurs, l'incident sur ton dslam n'a pas été enregistré sur https://www.free-reseau.fr/sa213 ton voisin chez free si j'ai bien compris, a t il été aussi concerné ?
-
Oui tout à fait
Et effectivement l'incident n'est pas repertorié sur le site qui permet de savoir l'état des réseaux, pourtant le jour J il était bien en incident du jour, et le CM sur twitter me l'avait confirmé en DM que il y avait un incident DSLAM sur le SA213. De souvenir je peux même te dire que l'incident a commencé dans la nuit vers 2h du matin et a été résolu fin de matinée ou début d'après midi je ne sais plus trop mais nous sommes d'accord, aucun historique dans le suivi des incidents :(
-
Ok, après il n'est peut-être pas sur la même carte que toi sur le dslam et n'a pas les mêmes réglages que toi niveau config du dslam.
Y'a une histoire de buffer sur le dslam pour la retransmission des dtu, peut-être que c'est mal paramétré (c'est juste une hypothèse)
J'espère pour toi que forcer le passage du vdsl2 à l'adsl2+ puis revenir en vdsl2 va faire un genre de reset pour retrouver la configuration précédent l'incident.
Autrement, les spécialistes free semblent être surtout sur le site de l'aduf : https://www.aduf.org/index.php
-
Oui ben parlons en de ce fameux site, j'ai posté dessus suite aux recommandations du 3244 qui m'a grandement invité à le faire, et manifestement aucune de ces fameuses personnes ne réponds pour l'instant.
Je verrai bien si le passage de ADSL2 puis VDSL2 fait quelque chose, mais je commence à croire que je peux m'assoir sur la possibilité de stream sans interruption. C'est quand même dommage qu'il soit nécessaire que leur soft détecte un soucis sur un instant T pour que un incident soit ouvert... Je trouve que le SAV fasse à ce genre de situation est déplorable bien qu'il n'y est clairement pas mort d'homme.
-
Sinon faudrait voir si tu peux pas laisser un long upload via iperf ou FTP parce que d'après ce que j'ai compris le problème ne se produit qu'après plusieurs minutes.
-
Sinon faudrait voir si tu peux pas laisser un long upload via iperf ou FTP parce que d'après ce que j'ai compris le problème ne se produit qu'après plusieurs minutes.
C'est très variable à vrai dire, cela peut se produire au bout de 2 à 3 mn voir 7-8 mais dans tous les cas je n'ai jamais pu tenir plus de 10-11mn sans interruption. J'ai fait pour l'instant un iperf sur 180s et ça allait.
Je suis hyper satisfait du matériel de Free et de leur service jusqu'à ce désagrèment mais du coup j'envisage de changer si Free n'est pas capable de m'apporter une solution :(, le soucis c'est qu'ailleurs je n'aurai pas les mêmes débits j'en suis quasi convaincu, et sincérement j'ai pas envie de quitter Free car j'adore le matos fourni, j'ai déjà testé tous les autres, et c'est sans conteste le meilleur matos à mes yeux.
-
Bonjour,
bon ben me voilà en ADLS2 pour faire le test, et donc bien évidemment mes débits sont nettement moins bons. Je lance donc la simulation et c'est exactement le même soucis avec exactement les memes erreurs dans les logs. Je repasserai en VDSL2 dans la nuit prochaine pour voir ce que cela dit ensuite mais je crains qu'il en soit de même.
-
Oui ben parlons en de ce fameux site, j'ai posté dessus suite aux recommandations du 3244 qui m'a grandement invité à le faire, et manifestement aucune de ces fameuses personnes ne réponds pour l'instant.
Il faut dire qu'entre Noël et le premier de l'an, il n'y a probablement pas beaucoup de techniciens Free à se connecter sur ce forum.
-
Oui, il faut se montrer patient surtout si le problème n'est pas résolvable de ton seul fait ce qui semble fortement probable le cas présent.
Si tu veux définitivement, par exemple mettre hors de cause la freebox : tu pourrais investir dans un modem vdsl2 premier prix comme celui-ci https://ledenicheur.fr/product.php?p=3187864
Car là, c'est possible que l'on soit en présence de deux événements corrélés temporellement mais sans lien direct de cause à effet https://fr.wikipedia.org/wiki/Cum_hoc_ergo_propter_hoc
-
Je pense vraiment qu'un test d'upload de plus longue durée serait intéressant. Si le problème ne se produit que sur ton application de streaming, ça permettrait d'avoir une meilleure compréhension du problème.
-
Je pense vraiment qu'un test d'upload de plus longue durée serait intéressant. Si le problème ne se produit que sur ton application de streaming, ça permettrait d'avoir une meilleure compréhension du problème.
Bonjour,
J'étais quasi convaincu que le soucis n'était en rien lié à mon soft mais sur l'ensemble de la co, preuve en est
[ 4] 237.00-238.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 238.00-239.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 239.00-240.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 240.00-241.00 sec 384 KBytes 3.14 Mbits/sec
[ 4] 241.00-242.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 242.00-243.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 243.00-244.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 244.00-245.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 245.00-246.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 246.00-247.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 247.00-248.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 248.00-249.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 249.00-250.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 250.00-251.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 251.00-252.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 252.00-253.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 253.00-254.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 254.00-255.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 255.00-256.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 256.00-257.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 257.00-258.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 258.00-259.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 259.00-260.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 260.00-261.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 261.00-262.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 262.00-263.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 263.00-264.00 sec 256 KBytes 2.10 Mbits/sec
Bonne journée à tous, et surtout un bon bout d'an
-
Autre piste à envisager: on peut se mettre en mode fastpath pour éviter les buffers de protection de la ligne (vu que ta courbe de marge de bruit semble stable ça ne devrait pas poser de problème de désynchro de ligne).
Par contre, en vdsl2, je ne sais pas si changer ce mode est opérant de la même manière.
-
ça ne coûte rien d'essayer :)
Je viens de le mettre en place pour le jour suivant, cela dit je suis comme toi, je ne sais pas si en vdsl2 le comportement est identique.
-
Tu as vérifié que le download n'était pas touché ?
-
Tu as vérifié que le download n'était pas touché ?
oui aucun impact côté download.
-
Ça pourrait être une protection anti-DDoS qui s'activerait à tort et à travers.
-
[ 4] 237.00-238.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 238.00-239.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 239.00-240.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 240.00-241.00 sec 384 KBytes 3.14 Mbits/sec
[ 4] 241.00-242.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 242.00-243.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 243.00-244.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 244.00-245.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 245.00-246.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 246.00-247.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 247.00-248.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 248.00-249.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 249.00-250.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 250.00-251.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 251.00-252.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 252.00-253.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 253.00-254.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 254.00-255.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 255.00-256.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 256.00-257.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 257.00-258.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 258.00-259.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 259.00-260.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 260.00-261.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 261.00-262.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 262.00-263.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 263.00-264.00 sec 256 KBytes 2.10 Mbits/sec
Mais là, tu as une interruption totale pendant plus de 10 secondes ...
Aussi, https://www.free-reseau.fr/sa213 n'a pas détecté d'incident sur ton DSLAM depuis 2016.
-
Mais là, tu as une interruption totale pendant plus de 10 secondes ...
Aussi, https://www.free-reseau.fr/sa213 n'a pas détecté d'incident sur ton DSLAM depuis 2016.
Oui c'est ce que je m'efforce de dire à Free au 3244 que mon service d'upload est interrompu pendant un laps de temps et que cela génère des déconnexions du stream mais selon eux tout est ok...... Et je sais qu'aucun incident n'est répertorié pourtant c'est bel et bien le cas, j'ai même la conversation avec le CM twitter qui confirme que le DSLAM a été interrompu.
"Bonjour. Depuis cette nuit ma box est en étape 2. Mon numéro de ligne est le ***********. Il semble qu'il y est un incident sur mon dslam le SA213. Disposez vous d informations à ce sujet ? Merci par avance.
Free
Bonjour, en cours de résolution, je vous invite à la redémarrer de temps en temps. Bonne journée
22 déc. "
Je tente de poster sur ADUF (et oui il y a bien des corps qui se sont connectés depuis que j'ai posté, donc pas un soucis de fetes de fin d'annees) mais en vain...
-
Je pense quand même que tu auras plus de chance d'avoir une réponse à partir du 2 janvier.
Tu aurais un voisin chez Free qui te laisserait faire le même test pour voir si tu reproduis ?
-
Tu aurais un voisin chez Free qui te laisserait faire le même test pour voir si tu reproduis ?
Ca va être compliqué, je pense. Mon seul voisin chez Free n'est actuellement plus là pour une période inconnue.
-
Ca va être compliqué, je pense. Mon seul voisin chez Free n'est actuellement plus là pour une période inconnue.
Ton IP est dans quel réseau ?
88.183.140.0/23, 88.183.142.0/23, 78.235.84.0/23, 78.235.86.0/23. 78.207.72.0/23, 78.207.74.0/24.
-
Ton IP est dans quel réseau ?
88.183.140.0/23, 88.183.142.0/23, 78.235.84.0/23, 78.235.86.0/23. 78.207.72.0/23, 78.207.74.0/24.
Mon ip est en 82.64.xx.xx
-
Impossible que cela commence par "82.64", aucuns DSLAM de Salon et de sa périphérie n'ont cette adresse IP dans leurs pools.
On pourrait avoir le 3ème bloc ?
-
Et pourtant
La suite est 82.64.30.xx
-
Tu n'es pas dégroupé.
Avec un reverse en "xx.xx.xx.xx.subs.proxad.net"
-
Je suis en IPV4 full stack depuis fort longtemps, ce qui peut expliquer mon ip
-
Je peux avoir un tracert vers "ftth.freebox.fr" ?
-
Oui bien sur
Voici
1 <1 ms <1 ms <1 ms FREEBOX [192.168.0.254]
2 18 ms 23 ms 23 ms 194.149.164.52
3 17 ms 17 ms 17 ms p11-9k-3-be2000.intf.routers.proxad.net [194.149.163.54]
4 17 ms 17 ms 16 ms bzn-6k-1-po22.intf.routers.proxad.net [194.149.162.10]
5 17 ms 17 ms 16 ms 212.27.59.202
6 16 ms 16 ms 16 ms ftth.freebox.fr [212.27.36.148]
-
Et dans ton espace abonné, que dit les informations de ligne ?
Ah moins que tu sois sur SA213 en IPv4 Full-Stack encapsulée dans de l'IPv6.
Je vois, il n'y a plus de place sur les ranges IP des DSLAM de SA213.
-
Voici les infos:
Raccordée actuellement en offre : Freebox dégroupé total
NRA : SA213
Longueur : 1030 mètres
Affaiblissement : 15 dB
-
Une idée, regarde dans ton interface freebox os (et éventuellement abonné), si ton DSLAM n'aurait pas été migré sur un nouveau DSLAM IPv6, avec une adresse IPv4 partagée par 4 utilisateurs (1/4 des ports TCP). Normalement, dans la rubrique freebox, tu devrais avoir à côté de l'adresse IPv4, le range de ports qui t'ait assigné.
Bingo :D
-
Tu n'es pas dégroupé.
Avec un reverse en "xx.xx.xx.xx.subs.proxad.net"
Y’a pas de VDSL2 en non dégroupé, faut pas se baser sur les reverse dns ;)
-
Y’a pas de VDSL2 en non dégroupé, faut pas se baser sur les reverse dns ;)
Mhmhmh tout ça pour ça, à 1030m il ne devrait plus synchro en VDSL2. Max 980m (et encore c'est chaud, vaut mieux forcer l'ADSL à ce stade de distance).
-
Mhmhmh tout ça pour ça, à 1030m il ne devrait plus synchro en VDSL2. Max 980m (et encore c'est chaud, vaut mieux forcer l'ADSL à ce stade de distance).
Faut pas se baser sur la longueur de ligne, mais l'atténuation,et dans son cas,elle n'est pas mauvaise
-
Il a visiblement 3* plus d'upload qu'en ADSL, du coup, je dirais que non.
-
Clairement mes débits en VDSL2 face à ceux en ADSL2 sont non négligeables.
-
Il a visiblement 3* plus d'upload qu'en ADSL, du coup, je dirais que non.
Il vaut mieux avoir des débits moindres, qu'une instabilité du lien.
-
Bingo :D
Bah oui. Pourtant :
Aucun soucis de ce côté là, j'avais déjà regardé ceci.
Et maintenant, on apprend qu'il est passé en IP full stack... D'où l'IP un peu spéciale attribuée.
-
Et maintenant, on apprend qu'il est passé en IP full stack... D'où l'IP un peu spéciale attribuée.
IP Full Stack ? J'imagine plutôt que ça veut dire qu'il n'y a que de l'Internet v6 et du NAT64 pour l'IPv4 ?
Free.fr, le réseau pourri et plus d'IP, j'ose pas imaginer comme ça doit être bien..
En même temps, twitch.tv, 2018, pas d'IPv6. Faudrait peut-être qu'ils se réveillent.
-
"IP full stack", c'est une dénomination qui l'a fait "geek" de Free, en plus pour faire un peu peur aux néophytes pour qu'ils se disent que c'est réservé aux experts, mais cela désigne en fait une IPv4 habituelle, avec tous les ports TCP de 1 à 64000 et quelque, au lieu d'un quart des ports, du genre 16000 à 32000. Mais normalement, cela ne pose problème que quand on héberge des serveurs chez soi, genre serveur web sur 80 et 443. Quel port est utilisé pour le stream ?
Il est possible que ce ne soit pas les ports qui posent problème ici, mais une techno peut-être pas tout à fait carré dans tous les points (4rd), ou un actif sur la chaine qui a un problème... Au moins ce n'est pas le convertisseur 10G/1G qui pose problème là.
Vu que le flux marche pendant quelques minutes, mon hypothèse prinicipal serait qu'un équipement ne tient pas un débit élevé sur la durée. C'est probablement pour cela qu'Underground conseillait un test avec un upload long.
Ce serait peut-être bien de déclarer ce nouveau DSLAM IPv6 sur Freepon ?
https://freepon.lafibre.info/
-
mon hypothèse prinicipal serait qu'un équipement ne tient pas un débit élevé sur la durée
Élevé, élevé, toute proportion gardée quand même ;).
-
Élevé, élevé, toute proportion gardée quand même ;).
Oui, c'est vrai, on n'est quand même qu'en VDSL2 ici... On va dire un débit soutenu.
-
Et encore, on parle d'un VDSL2 qui pousse 2-3Mbps (ce qui à 1km est somme toute déjà pas mal). A voir si c'est le côté continu qui ne poserait pas soucis, faudrait trouver qqn pour faire le même test...
[ 4] 0.00-1.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 1.00-2.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 2.00-3.00 sec 384 KBytes 3.15 Mbits/sec
[ 4] 3.00-4.00 sec 256 KBytes 2.10 Mbits/sec
-
A voir si c'est le côté continu qui ne poserait pas soucis
D'où mon idée de l'anti-DDoS mais bon ça me parait pas très satisfaisant.
-
Non mais de toute façon apparement depuis l'espace client il peut récupérer son IPv4, donc faudrait commencer par ça.
-
Il l'a déjà fait !
Je suis en IPV4 full stack depuis fort longtemps, ce qui peut expliquer mon ip
-
Il l'a déjà fait !
Pourtant le préfixe ne semble pas correspondre.
-
Le 'fort longtemps' me semble bizarre, car à priori, cela ne devrait être possible que depuis le passage en DSLAM IPv6...
-
Pourtant le préfixe ne semble pas correspondre.
J'ai également une IP "full-stack" en 82.64.