La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
Ozone - Nomotech => Discussion démarrée par: Mnk14 le 27 juillet 2022 à 19:55:23
-
Bonjour
Comme le dit le titre,par moment les pages de n'importe quel site sont très longues a ouvrir ,ainsi que des applications comme discord,youtube etc
Le débit est très bon environ 950 mbps des deux côtés ainsi que le ping 10ms.
Je suis chez Ozone via covage 14
Merci
-
Bonjour,
il faudrait que tu fasses un ping depuis ton PC. (Sous Windows démarrer => executer => cmd => ping google.fr -n 900
Au bout de 900 secondes (15 minutes) le résultat apparait. c'est quelque chose comme celà.
Statistiques Ping pour 216.58.206.227:
Paquets : envoyés = 900, reçus = 899, perdus = 1 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 24ms, Maximum = 59ms, Moyenne = 29ms
Il faut regarder le nombre de "perdus" et la différence entre le Min, le Max et la moyenne.
-
Bonjour
Merci pour votre réponse.
J'ai ce résultat
Statistiques Ping pour 142.250.75.227:
Paquets : envoyés = 900, reçus = 900, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 7ms, Maximum = 11ms, Moyenne = 8ms
Merci
-
C'est plutôt parfait.
il faudrait savoir ce qu'il se passe au moment où les pages sont longues à charger. ça ne semble pas venir du réseau, donc soit un panne/pertubation intermittente soit la RAM/CPU tu PC est momentanément surchargé.
serait-ce possible de vérifier çà à la prochaine lenteur lors du chargement des pages ?
pour tester d'autre site, il faut remplacer google.fr par le site en question dans cette commande.
ping google.fr -n 900
-
J'avais deja vérifié si dans le gestionnaire des taches si j'etais surchargé ,mais non .
Le souci est le meme sur tous les apareils de la maison,bon debit mais malgré ça ,c'est trés long .
J'ai téster avec l'application Nperf et il me zappe des fois la partie streaming avec 950 mega :(
-
Cela pourrait être lié à une lenteur DNS.
Que donne nPerf sur ton mobile (pour avoir les tests navigation et streaming) ?
Si tu es prêt à faire une capture Wireshak je suis prêt à l'analyser.
Il faut suivre le tutoriel Réaliser une capture Wireshark pas à pas (https://lafibre.info/tcpip/realiser-une-capture-wireshark-pas-a-pas/)
1/ Ouvre ton navigateur et Wireshark
2/ démarre la capture Wireshark
3/ ouvre un site web (il faut qu'il soit lent à s'afficher sinon j'aurais du mal à comprendre l'origine du pb)
4/ arrête Wireshark et sauvegarde et envoi moi la capture.
Si tu souhaites me montrer le comportement sur plusieurs sites, je préfère une capture par site.
-
D'accord merci
Je fait ça demain matin
Merci beaucoup 🙂
-
Sinon
Voilà pour Nperf
Merci
-
L'indice de performance navigation est parfait, c'est étonnant par contre le bug sur la vidéo.
Tu pourrais faire une demande à nPerf pour avoir accés à la section privée nPerf ?
=> https://lafibre.info/tester-son-debit/beta-test-application-nperf-pour-windows-mac-linux/
Le pseudo Sn@ke est le dirigeant et fondateur de nPerf, il répond aux problèmes soulevés dans la section nPerf privée et cela serait intéressant de voir sila vidéo passe ou pas avec nPerf desktop (application nPerf pour PC permettant des tests plus fiables et plus complet que ce que l'on a dans un navigateur)
La capture Wireshark reste nécessaire pour que je trouve rapidement la root cause des lenteurs.
-
Bonjour
j'ai installé Wireshark ,mais pour l'instant je pas pu reproduire le phenomene des chargements lents :(
Si le probleme revient je serait pret a poster des captures.
Encore merci
-
Je précise un point : Il est important d'avoir le début de la capture. Donc si tu vois qu'une page est lente et que tu démarres rapidement Wireshark, c'est trop tard.
Tu peux aussi laisser wireshark lancé pendant que tu surf sur plusieurs pages, mais bien essayer d'avoir l'heure précise de la page qui a posé un problème pour que je la retrouve dans la capture. Comme il y a un horodatage, si tu as l'heure et le nom du site, c'est bien, cela me permettra de faire les recherches pour le retrouver.
À noter qu'il ne faut pas faire trop de vidéo avec Wireshark ouvert, il est compliqué d'ouvrir un fichier de plus de 500 Mo.
-
Finalement
J'ai reussi à faire 2 capture sur 2 sites differents
-
Sur la capture N°1, je ne vois aucun chargement de page web. On voit juste du trafic arrière-plan de Google, lié probablement à Chrome.
Sur la capture N°2, il y a une grosse parie qui est du trafic HTTP/3 (trafic UDP). Tout est caché, on ne peut rien analyser.
Toutefois, il y a un peu de trafic TCP. Notamment une connexion TCP sur "partenaire.bemove.fr"
Voici les paquets en question :
(https://lafibre.info/images/ozone/202207_ozone_perte_paquets_tcp.webp)
Le premier paquet, c'est toi (192.168.1.65) qui établie la connexion vers partenaire.bemove.fr (62.210.235.151). Le paquet est perdu, on doit attendre une seconde avant la retransmission.
La seconde tentative est la bonne. Ton PC demande à monter la connexion https (Client Hello, un paquet qui envoi la suite d’algorithmes supportés) et là de nouveau paquet perdu. Le paquet Client Hello sera renvoyé 6 fois pour avoir enfin la réponse Server Hello (Choix de la version de la suite d’algorithmes).
On a ensuite les échanges de clés qui se passent bien.
Ensuite ton PC envoie "Change Cipher Spec" (Passage du client en mode chiffré avec la clé master comme clé symétrique) et de nouveau paquet perdu. Il faudra attendre la troisième tentative pour avoir une réponse.
TLS 1.3 n'est pas encore monté qu'on a déjà perdu bêtement 6,3 secondes (c'est énorme) alors que cela doit être fait en quelques dizaines de ms vu que le serveur semble proche.
La connexion ne sera finalement pas utilisée, car le navigateur à, au vu les problèmes à monter la connexion, démarré une seconde connexion vers "partenaire.bemove.fr". Cette seconde connexion va aussi avoir des paquets perdus, mais moins. TLS 1.3 est monté en 1,15 seconde, c'est mieux que les 6,3 secondes observées ici, mais ce n'est pas acceptable.
Il y a visiblement des pertes de certains de paquets. Tu as une IPv4 dédiée ou tu es derrière du CG-Nat (IPv4 publique mutualisée entre plusieurs clients) ?
-
Bonjour
Alors pour l'IP je peux le savoir comment ?
J'ai la même depuis le début.
Après j'ai un routeur derrière la box Ozone depuis octobre,donc je pense pas que ça soit le problème,car ça marche depuis le début.
Merci
-
Je viens de regarder le baromètre IPv6 Arcep, Ozone à 25% de clients FttH avec un IPv4 dédiée. Tu es probablement en mutualisé.
Je ne sais pas si tu peux le voir dans la box, mais qu'elle est l'IP fournie pas le réseau ?
Si c'est une IP dans ces plages, c'est une IP mutualisée, avec un CG-Nat qui pourrait être la cause du problème (c'est une hypothèse, pas la seule)
Récapitulatif des plages d'IP privées :
- 10.0.0.0/8 (10.0.0.0 – 10.255.255.255) - RFC 1918 : 16 777 216 IPv4
- 100.64.0.0/10 (100.64.0.0 - 100.127.255.255) - RFC 6598 : 4 194 304 IPv4
- 172.16.0.0/12 (172.16.0.0 – 172.31.255.255) - RFC 1918 : 1 048 574 IPv4
- 192.168.0.0/16 (192.168.0.0 – 192.168.255.255) - RFC 1918 : 65 536 IPv4
- fd00::/8 - RFC 4193
-
Je n'ai pas accès à la box, c'est une interface sur le site d'ozone.
Mais si il y a un moyen de récupérer les infos par un autre moyen,je peux le faire,car la plage d'ip que vous me donnez, j'avoue que c'est un peu compliqué pour moi 😔
-
Sur le site d'Ozone, tu peut rediriger des ports ?
Il te propose une option IPv4 dédiée à 8 €/mois ?
Pourais-tu faire une capture de 10 chargements de la page de référence 2 (grande taille) : https://lafibre.info/navigateurs/surf-web/
(le tout dans une même capture wireshark) pour que je regarde ?
-
Oui je peux redirigé les ports,
Ok je ferais la procédure ce soir.
Pour l'option je suis pas très chaud a payé plus sans être sûr du résultat.
Merci
-
Si tu peux rediriger les ports, tu fais partie des 25% avec IPv4 dédiée (gratuitement, sûrement lié à ton ancienneté, tu es client depuis de nombreuses années ?).
En aucun cas je te demande de prendre l'option. On cherche à comprendre l'architecture.
-
Non je ne suis client que depuis octobre 2021
Mais je n'ai pas vu l'option IP dédiée sur le site
-
Étonnant. Cela serait en fonction des collectes ?
-
Aucune idée
Voici la capture
Merci
-
Tu n'avais pas vidé le cache, doit la requête est toute petite (et pas de paquet perdu).
Tout le transfert (avec ouverture de la connexion et monter TLS 1.3, transfert de la page) s'est fait en 0,08 seconde pour comparer avec les temps précédents.
La connexion est rapide, ce qui pose problème, c'est les paquets perdus et il est possible que ce ne soit pas sur l'accès.
Tu as le support Orone au téléphone ?
-
J'ai ouvert un onglet a la suite en cliquant sur le lien.
J'ai peut être pas fait comme il fallait.
J'ai un collègue qui a le même soucis que moi a 15 bornes de chez moi ,il les a eu au téléphone ,il fallait qu'il vérifie ses câbles 😔
Donc pas de solutions crédible.
-
Bonjour
En faisant un ping sur degrouptest j'ai ce resultat :
PS C:\Users\Philippe> ping -t degrouptest.com
Envoi d’une requête 'ping' sur degrouptest.com [62.210.235.151] avec 32 octets de données :
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=7 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=7 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Réponse de 62.210.235.151 : octets=32 temps=8 ms TTL=53
Délai d’attente de la demande dépassé.
Je vois pas ce qui me bloque
-
Quand je fais un traceroute vers ton IPv4 publique, je ne vois aucune perte (testé depuis plusieurs serveurs).
Je me demande si cela ne serait pas sur l'accès.
Un MTR (WinMTR sous Windows) permettait de voir où les pertes apparaissent.
$ mtr -zrwc100 85.203.81.xx
Start: 2022-07-29T09:54:09+0200
HOST: massy Loss% Snt Last Avg Best Wrst StDev
1. AS5410 _gateway 11.0% 100 1661. 729.5 0.2 2004. 855.0
2. AS5410 62.34.2.156 94.0% 100 0.4 0.4 0.4 0.4 0.0
3. AS5410 62.34.2.155 86.0% 100 0.4 0.5 0.4 0.7 0.1
4. AS5410 be11.cbr01-cro.net.bbox.fr 0.0% 100 1.4 1.2 0.9 1.6 0.2
5. AS??? ? ? 100.0 100
6. AS??? luxnetwork.par.franceix.net 0.0% 100 1.2 4.0 0.9 67.7 10.4
7. AS29467 lu-153-92-62-21.luxnetwork.eu 0.0% 100 1.2 9.6 0.9 127.6 26.3
8. AS29467 lu-185-4-124-210.luxnetwork.eu 0.0% 100 1.9 1.9 1.7 2.3 0.1
9. AS39886 vlan-3801.hu0-0-0-20.par-co1.as39886.net 0.0% 100 2.0 1.9 1.7 3.5 0.2
10. AS??? ? ? 100.0 100
-
Essaye de faire un PingPlotter vers n'importe quel site. Ca permettra de mettre en évidence où se situe le pb.
-
Merci pour vos reponses
je vais essayer ces 2 solutions.
J'ai tester avec un vpn (Cyberghost) avec un serveur sur paris et je n'ai plus d'erreur de ping
Merci
-
J'ai fait les deux solutions proposée
Avec VPN :
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 10.15.128.1 - 0 | 49 | 49 | 7 | 7 | 8 | 8 |
| unn-84-17-43-28.cdn77.com - 0 | 49 | 49 | 7 | 7 | 8 | 8 |
| vl222.par-itx5-core-2.cdn77.com - 0 | 49 | 49 | 7 | 7 | 8 | 8 |
| unn-185-156-45-117.cdn77.com - 3 | 45 | 44 | 0 | 8 | 10 | 8 |
| dedibox-par.cdn77.com - 0 | 49 | 49 | 8 | 8 | 9 | 9 |
| 62.210.0.156 - 0 | 49 | 49 | 8 | 8 | 9 | 9 |
| 51.158.1.35 - 0 | 49 | 49 | 8 | 8 | 9 | 9 |
| 45-s43-1-a9k1.dc3.poneytelecom.eu - 0 | 49 | 49 | 8 | 10 | 24 | 9 |
| 62.210.235.151 - 0 | 49 | 49 | 8 | 8 | 12 | 9 |
|________________________________________________|______|______|______|______|______|______|
Sans VPN :
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 57 | 57 | 0 | 0 | 0 | 0 |
| 192.168.8.254 - 0 | 57 | 57 | 0 | 0 | 1 | 0 |
| 172.26.0.118 - 0 | 57 | 57 | 2 | 2 | 3 | 2 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| vlan2018.be8.par-co1.as39886.net - 24 | 30 | 23 | 8 | 8 | 9 | 8 |
| vlan-3801.hu0-0-0-20.par-p1.as39886.net - 17 | 37 | 31 | 8 | 8 | 9 | 8 |
| ae0-4102.par-th2-crluxpe02.as29467.net - 18 | 34 | 28 | 7 | 13 | 101 | 7 |
| lu-153-92-62-20.luxnetwork.eu - 31 | 26 | 18 | 7 | 7 | 8 | 7 |
| No response from host - 100 | 12 | 0 | 0 | 0 | 0 | 0 |
| 51.158.1.41 - 17 | 36 | 30 | 8 | 8 | 9 | 8 |
| 45-s43-1-a9k2.dc3.poneytelecom.eu - 24 | 30 | 23 | 0 | 8 | 9 | 8 |
| 62.210.235.151 - 30 | 27 | 19 | 7 | 7 | 8 | 8 |
|________________________________________________|______|______|______|______|______|______|
Merci
-
Merci, cela montre clairement où est le problème et c'est bien chez ton opérateur.
Le débit ne devrait pas être si bon avec des pertes de paquets.
Tu pourrais tester en mono-connexion Cubic vs BBR ?
Tutoriel pour tester son débit et comprendre les limitations
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/tuto_test_debit.webp) (https://lafibre.info/testdebit/linux/tuto_test_debit.pdf)
Pour en savoir plus sur la résistance de Cubic et BBR aux pertes de paquets : https://lafibre.info/qos-mobile/protocole-qos-arcep-2022/
-
Pour le dernier (Orly) je l'ai fait 3 fois que des erreurs
-
Étonnant, pour moi Orly fonctionne bien.
Coté réseau, c'est un serveur qui est à côté de Palaiseau dans la baie (Palaiseau => BBR IPv4 only)
Massy qui fait du BBR IPv4+IPv6 est lui dans un autre datacenter (mais toujours chez Bouygues Telecom, comme Orly Cubic et Palaiseau BBR).
(https://www.speedtest.net/result/13470588310.png)
-
Du coup le fait que ça marche bien avec un vpn,peut provenir de quel problème ?
-
Si cela marche bien avec un VPN et impossible sans, là ce ne sont plus des pertes de paquet au hasard !
Une capture Wireshark pourrait être intéressante pour voir quel paquet bloque, mais cela change complètement le diagnostic. Un lien défectueux va perdre de paquets n'importe où, pas toujours au même endroit, ce qui doit être le cas avec Orly.
-
Peut-être que tu empruntes un autre chemin pour ton VPN, un chemin sain, qui ne souffre pas d'erreurs, etc.
Ou que le VPN corrige les erreurs avec l'encapsulation ?
-
Ils doivent me rappeler,si ils ne le font,je passerai par la case résiliation
-
Ils doivent me rappeler,si ils ne le font,je passerai par la case résiliation
Je ne sais pas , j'avoue que je suis un peut largué.