La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus fibre Free => Discussion démarrée par: _ATOmix_ le 30 juin 2016 à 22:08:30
-
Bonjour,
Je fais fasse à un problème récent, plus aucun trafic sur certains ports (entrants ou sortants), voici un test effectué avec l'outil de vivien qui illustre bien le souci:
(http://i.imgur.com/8qQejgf.png)
Ma ligne FTTH en ZMD à été activée le 24/06/16, tout fonctionnait à merveille:
- Connexion FTP: OK
- Torrents: OK
- IPv4 avec les ports 0-16383
Jusqu'à ce que je m’aperçoive jeudi 30/06/2016 que je ne pouvais plus me connecter à mon serveur Kimsufi (que ce soit en FTP, x2Go, SSH) et impossible de télécharger un torrent Ubuntu avec mon client qBitorrent, cependant rien à déplorer au niveau de la navigation sur internet, mis à part le fait que je ne peux évidement pas télécharger depuis Firefox http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip par exemple.
J'ai essayé de faire les mêmes manipulations depuis mon smartphone connecté à la femtocell d'un voisin tout fonctionne.
Dès que je connexion mon smartphone à mon réseau wifi je n'arrive plus à me connecter, seule la navigation web est fonctionnelle.
j'ai essayé de télécharger mon torrent depuis le client intégré au Freebox Server, cela fonctionne, mais les ports utilisés sont différents (16383 & 14331)
(http://i.imgur.com/gLvOnQw.png)
Depuis mon smartphone:
Réseau Free Mobile: OK
Réseau Free Mobile (femtocell): OK
Réseau de mon FreeWifi_secure: OK, j'arrive même à télécharger un torrent
Les traceroute ne se font pas.
(http://i.imgur.com/XzF46iN.png)
(http://i.imgur.com/ZNZxL7N.png)
J'arrive pourtant à les consulter avec mes navigateurs.
Le 04/07/2016:
- J'ai ouvert un incident auprès du support mais qui à mit la ligne en observation mais entre nous je pense pas qu'ils vont chercher dans la direction de port inaccessibles mais dans la direction de soucis de synchronisation ou de débit, bien que j'ai précisé que le souci n'est pas là.
- J'ai basculé en IPv4 full-stack et rien n'y fait le problème est toujours entier
J'ai l'impression que mes soucis sont apparus depuis la mise ne place de l'IPv4 full-stack le 22/06/2016, mais cela peut être une coïncidence car je ne me suis rendu compte de souci que le 30/06/2016.
Suis-je le seul à rencontrer ces soucis?
MAJ 12/07/2015: Cela venait du contrôle parental, le filtre par défaut était sur "Accès web uniquement", j'ai ajouté mes périphérique dans un filtre manuel "Accès internet autorisé"
-
C'est un F.A.I. grand public qui fait ça ? :o
Ça ressemble à une connexion d'hôtel/location qui bride bêtement les ports différents de HTTP(S), IMAP, etc.
Edit 05-07 : Je précise que ce message a été posté avant l'edit de l'auteur du post.
-
Free en ZMD, suis-je un cas isolé de bridage? D'autant plus que cela fonctionnait bien il y à 1 semaine.
-
Ça correspondrait pas avec la disponibilité de l'option IP non partagée ? M'enfin je me demande s'il n'y aurait quand même pas un bug dans le script par ailleurs, le débit à 0 me semble bizarre ou alors c'est que le téléchargement ne démarre pas du tout ?
-
Pour l'émission, il faut avoir les ports 443, 554, 6881 etc. ouverts, ce qui n'est pas possible suivant la plage de ports disponibles, en revanche, pour la réception ça ne devrait pas poser de problèmes quelle que soit la plage, c'est plus bizarre.
-
Non, il s'agit des ports de réception donc à priori il n'y a aucun problème particulier même en cas de partage d'IP.
-
Pour l'émission, il faut avoir les ports 443, 554, 6881 etc. ouverts, ce qui n'est pas possible suivant la plage de ports disponibles, en revanche, pour la réception ça ne devrait pas poser de problèmes quelle que soit la plage, c'est plus bizarre.
J'ai la plage (ports 0-16383) de toute façon, donc il ne devrait pas y avoir de souci.
Et pourtant les transferts ne passe carrèment pas sur ces ports.
(http://i.imgur.com/yU7BUSp.png)
-
Je me demande s'il n'y aurait pas un soucis avec le serveur en fait, il faudrait que vivien vérifie.
-
Impossible de télécharger un torrent depuis qBittorent (port 6881), cependant ça fonctionne sur le Freebox Server, mais les ports utilisés sont différents (16383 & 14331)
(http://i.imgur.com/gLvOnQw.png)
-
Pour moi il y a un bug avec certains ports côté serveur, par exemple http://3.testdebit.info:80/fichiers/10Mo/10Mo.zip fonctionne mais pas http://3.testdebit.info:8080/fichiers/10Mo/10Mo.zip (j'obtiens une page générique "It worked!").
-
Pour moi il y a un bug avec certains ports côté serveur, par exemple http://3.testdebit.info:80/fichiers/10Mo/10Mo.zip fonctionne mais pas http://3.testdebit.info:8080/fichiers/10Mo/10Mo.zip (j'obtiens une page générique "It worked!").
oui Vivien a du rallumer son serveur Ookla sur 3.testdebit.info
-
Impossible de télécharger un torrent depuis qBittorent (port 6881), cependant ça fonctionne sur le Freebox Server, mais les ports utilisés sont différents (16383 & 14331)
(http://i.imgur.com/gLvOnQw.png)
Je suis passé en IP full stack même si je n'y croyais pas trop, mais bon juste pour être sur et...ça n'a rien changé! :D
-
Il se passe quoi quand tu essaies de télécharger http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip dans ton navigateur ? Ta capture d'écran ne me parait pas forcèment très claire...
-
Il se passe quoi quand tu essaies de télécharger http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip dans ton navigateur ? Ta capture d'écran ne me parait pas forcèment très claire...
Une belle erreur.
Le délai d'attente est dépassé
Le serveur à l'adresse 3.testdebit.info met trop de temps à répondre.
Le site est peut-être temporairement indisponible ou surchargé. Réessayez plus tard ;
Si vous n'arrivez à naviguer sur aucun site, vérifiez la connexion au réseau de votre ordinateur ;
Si votre ordinateur ou votre réseau est protégé par un pare-feu ou un proxy, assurez-vous que Firefox est autorisé à accéder au Web.
Avancé ▼
fait appel à des technologies de sécurité qui sont obsolètes et vulnérables aux attaques. Un attaquant pourrait facilement révéler des informations que vous pensiez être protégées.
(Non sécurisé) Essayer de recharger en faisant appel à des technologies de sécurité obsolètes
Avec mon forfait free mobile aucun soucis.
-
Intéressant, c'est là que ça serait bien d'avoir un contact pour remonter les bugs de la nouvelle archi ZMD... On va voir si Rani Assaf répond à ma question à ce sujet.
-
Est-ce normal que je n'arrive pas à faire de traceroute?
(http://i.imgur.com/XzF46iN.png)
(http://i.imgur.com/ZNZxL7N.png)
J'arrive pourtant à les consulter avec mes navigateurs, par contre impossible de me connecter à mon serveur Kimsufi.
J'ai ouvert un incident auprès du support mais qui à mit la ligne en observation mais entre nous je pense pas qu'ils vont chercher dans la direction de port inaccessibles mais dans la direction de soucis de synchronisation ou de débit, bien que j'ai précisé que le souci n'est pas là.
L'IPv4 Full-stack en ZMD c'est pas encore ça...
-
Avec un autre PC ou un portable Android arrives-tu à pinguer ces sites ?
Attention avec TF1, il faut pinguer www.tf1.fr. tf1.fr ne doit pointer sur aucun serveur, ça ne répond pas même avec un ping TCP.
-
J'ai demandé à Vivien le déplacement de tes messages dans une section Free comme c'est plus un bug qu'un problème de neutralité du net.
Comme 3.testdebit.info répond en IPv6 c'est quand même super étrange que ça soit un soucis lié à la nouvelle archi... Tu as tenté de forcer l'IPv4 pour voir si ça change quelque chose (wget -4 par exemple) ?
D'autres abonnés en ZMD pour tester l'URL http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip ? Si oui, donnez le résultat ici et indiquez si vous êtes en IP partagée ou non.
-
Avec un autre PC ou un portable Android arrives-tu à pinguer ces sites ?
Attention avec TF1, il faut pinguer www.tf1.fr. tf1.fr ne doit pointer sur aucun serveur, ça ne répond pas même avec un ping TCP.
C:\Users\_A.T.Omix_>ping www.tf1.fr
Envoi d’une requête 'ping' sur a1272.g.akamai.net [2.16.117.168] avec 32 octets de données :
Réponse de 192.168.1.254 : Impossible de joindre le réseau de destination.
Réponse de 192.168.1.254 : Impossible de joindre le réseau de destination.
Réponse de 192.168.1.254 : Impossible de joindre le réseau de destination.
Réponse de 192.168.1.254 : Impossible de joindre le réseau de destination.
Statistiques Ping pour 2.16.117.168:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Depuis mon smartphone:
Réseau Free Mobile: OK
Réseau Free Mobile (femtocell): OK
Réseau de mon FreeWifi_secure: OK, j'arrive à télécharger un torrent et http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip
J'ai demandé à Vivien le déplacement de tes messages dans une section Free comme c'est plus un bug qu'un problème de neutralité du net.
Comme 3.testdebit.info répond en IPv6 c'est quand même super étrange que ça soit un soucis lié à la nouvelle archi... Tu as tenté de forcer l'IPv4 pour voir si ça change quelque chose (wget -4 par exemple) ?
D'autres abonnés en ZMD pour tester l'URL http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip ? Si oui, donnez le résultat ici et indiquez si vous êtes en IP partagée ou non.
C'est une bonne chose, cela permettra d'avoir plus de visibilité afin de déterminer si je suis un cas isolé où non.
j'ai mis le message d'ouverture à jour afin de détailler mon problème.
Depuis mon PC
(http://i.imgur.com/2eEqhhp.png)
Depuis mon smartphone connecté au réseau FreeWifi_secure de ma freebox: ça fonctionne
-
Et sur ton WiFi perso avec ton smartphone tu peux pinguer les sites ? Avec une application comme HE.net Network Tools par exemple
-
Et sur ton WiFi perso avec ton smartphone tu peux pinguer les sites ? Avec une application comme HE.net Network Tools par exemple
Depuis mon Wifi perso non, cependant depuis le FreeWifi_secure de ma box oui:
PING lafibre.info (46.227.16.8): 56 data bytes
64 bytes from 46.227.16.8: icmp_seq=0 ttl=56 time=25.5 ms
64 bytes from 46.227.16.8: icmp_seq=1 ttl=56 time=12.8 ms
64 bytes from 46.227.16.8: icmp_seq=2 ttl=56 time=14.3 ms
--- lafibre.info ping statistics ---
3 packets transmitted, 3 packets received, 0,00% packet loss
round-trip min/avg/max/stddev = 12,80/17,53/25,50/5,67 ms
traceroute to testdebit.info (46.227.16.8), 50 hops max, 64 byte packets
1 10.159.255.254 (10.159.255.254) 3,37 ms 2,95 ms 7,60 ms
2 10.255.0.254 (10.255.0.254) * * *
3 bzn-9k-4-be1002.intf.routers.proxad.net (78.254.250.181) 4,16 ms 4,43 ms 4,47 ms
4 p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1) 5,90 ms 7,74 ms 9,35 ms
5 th2-9k-3-be1001.intf.routers.proxad.net (194.149.162.86) 4,23 ms 4,84 ms 4,09 ms
6 ge1-17-cr2.th2-prs.fr.rt.ielo.net (212.85.148.165) 4,39 ms 4,74 ms 5,02 ms
7 te-3-1-frlyo01-c6k1.rt.ielo.net (212.85.145.173) 12,40 ms 12,00 ms 12,70 ms
8 adeli1.ix-customers-le9lyon.ielo.net (212.85.148.226) 13,80 ms 13,10 ms 13,30 ms
9 lafibre.info (46.227.16.8) 13,10 ms 12,80 ms 13,00 ms
-
C'est un F.A.I. grand public qui fait ça ? :o
Ça ressemble à une connexion d'hôtel/location qui bride bêtement les ports différents de HTTP(S), IMAP, etc.
Non, ça ressemble à un routeur complètement largué. Ce ne sont pas juste des ports qui sont bloqués, même les ICMP ne sont (si tu utilises bien un traceroute ICMP). Il faudrait faire un traceroute en TCP.
Et j'ajoute que Windows est une belle daube s'il n'affiche pas l'origine des messages d'erreur ICMPv6.
-
C'est un F.A.I. grand public qui fait ça ? :o
Ça ressemble à une connexion d'hôtel/location qui bride bêtement les ports différents de HTTP(S), IMAP, etc.
Pardon mais on dirait que tu débarques!
Le FAI ADSL grand public Free est connu historiquement pour avoir fait ça, pas juste en privilégiant des ports aux "heures de pointe" (plage horaire définie administrativement et non en fonction du débit observé à chaque instant) mais même en regardant le user-agent HTTP.
Historiquement, ça veut bien dire qu'on ne peut pas accuser Free de le faire juste parce que ça a déjà eu lieu.
-
D'autres abonnés en ZMD pour tester l'URL http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip ? Si oui, donnez le résultat ici et indiquez si vous êtes en IP partagée ou non.
IP Full Stack
wget http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip
--2016-07-05 10:56:57-- http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip
Résolution de 3.testdebit.info (3.testdebit.info)... 62.34.91.3, 2001:860:f70b:100::3
Connexion vers 3.testdebit.info (3.testdebit.info)|62.34.91.3|:6881...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 10000000 (9,5M) [application/zip]
Sauvegarde en : «10Mo.zip»
100%[======================================>] 10 000 000 5,95M/s ds 1,6s
2016-07-05 10:56:59 (5,95 MB/s) - «10Mo.zip» sauvegardé [10000000/10000000]
-
Intéressant, le problème n'est donc pas général.
-
Ca ne pourrait pas être un problème sur le PC genre firewall mal configuré qui bloque trop de choses?
-
Il semble que _ATOmix_ a également testé en Wifi depuis son téléphone.
-
Ca ne pourrait pas être un problème sur le PC genre firewall mal configuré qui bloque trop de choses?
On pourrait penser à un souci purement local quand on lit "Impossible de joindre le réseau de destination" (du style routage en vrac) sauf que :
Réponse de 192.168.1.254 : Impossible de joindre le réseau de destination.
C'est pas le pare-feu local qui envoie ça.
-
IP Full Stack
wget http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip
--2016-07-05 10:56:57-- http://3.testdebit.info:6881/fichiers/10Mo/10Mo.zip
Résolution de 3.testdebit.info (3.testdebit.info)... 62.34.91.3, 2001:860:f70b:100::3
Connexion vers 3.testdebit.info (3.testdebit.info)|62.34.91.3|:6881...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 10000000 (9,5M) [application/zip]
Sauvegarde en : «10Mo.zip»
100%[======================================>] 10 000 000 5,95M/s ds 1,6s
2016-07-05 10:56:59 (5,95 MB/s) - «10Mo.zip» sauvegardé [10000000/10000000]
Merci.
Et tu n'as pas d'anomalies avec https://lafibre.info/testdebit/curl/test-neutralite.zip ?
-
Le temps de rentrer et démarrer un netbook sous Windows (pas envie de refaire le .bat sous linux et je sais pas si un script existe déjà)
05/07/2016 19:20:52 Téléchargement de 50 Mo depuis 3.testdebit.info :
IPv4+TCP80 +http .zip: 17,507 Mb/s (DNS:187ms+SYN:0ms+GET:16ms+Down:22854ms)
IPv4+TCP80 +http .jpg: 16,840 Mb/s (DNS:110ms+SYN:0ms+GET:15ms+Down:23759ms)
IPv4+TCP80 +http .mp4: 19,40 Mb/s (DNS:109ms+SYN:0ms+GET:3198ms+Down:21013ms)
IPv4+TCP80 +http .pdf: 16,611 Mb/s (DNS:124ms+SYN:0ms+GET:47ms+Down:24087ms)
IPv4+TCP443 +https.zip: 14,934 Mb/s (DNS:125ms+SYN:0ms+GET:1591ms+Down:26786ms)
IPv4+TCP443 +https.jpg: 14,867 Mb/s (DNS:109ms+SYN:16ms+GET:1404ms+Down:26910ms)
IPv4+TCP554 +http .zip: 18,968 Mb/s (DNS:109ms+SYN:47ms+GET:62ms+Down:21092ms)
IPv4+TCP554 +http .jpg: 16,638 Mb/s (DNS:109ms+SYN:16ms+GET:31ms+Down:24040ms)
IPv4+TCP554 +http .mp4: 17,761 Mb/s (DNS:109ms+SYN:16ms+GET:0ms+Down:22526ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP993 +https.zip: 17,761 Mb/s (DNS:188ms+SYN:0ms+GET:301877ms+Down:0ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP993 +https.jpg: 17,761 Mb/s (DNS:140ms+SYN:47ms+GET:301441ms+Down:0ms)
IPv4+TCP1194+https.zip: 15,590 Mb/s (DNS:156ms+SYN:15ms+GET:1248ms+Down:25662ms)
IPv4+TCP1194+https.jpg: 14,480 Mb/s (DNS:1638ms+SYN:94ms+GET:1669ms+Down:27628ms)
IPv4+TCP6881+http .zip: 18,649 Mb/s (DNS:125ms+SYN:93ms+GET:31ms+Down:21450ms)
IPv4+TCP6881+http .jpg: 16,409 Mb/s (DNS:109ms+SYN:0ms+GET:16ms+Down:24383ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP8080+http .zip: 16,409 Mb/s (DNS:187ms+SYN:0ms+GET:78ms+Down:0ms)
IPv4+TCP8080+http .jpg: 0,54 Mb/s (DNS:187ms+SYN:0ms+GET:16ms+Down:16ms)
IPv4+TCP8080+http .mp4: 0,54 Mb/s (DNS:125ms+SYN:31ms+GET:0ms+Down:16ms)
05/07/2016 19:36:57 Emission de 50 Mo vers 3.testdebit.info :
IPv4+TCP80 +http .zip: 16,633 Mb/s (DNS:110ms+SYN:0ms+POST:1232ms+Up:24055ms)
IPv4+TCP80 +http .jpg: 16,840 Mb/s (DNS:109ms+SYN:0ms+POST:1342ms+Up:23759ms)
IPv4+TCP80 +http .mp4: 16,0 Mb/s (DNS:62ms+SYN:16ms+POST:1700ms+Up:25007ms)
IPv4+TCP443 +https.zip: 16,15 Mb/s (DNS:109ms+SYN:0ms+POST:1498ms+Up:24976ms)
IPv4+TCP554 +http .zip: 17,674 Mb/s (DNS:109ms+SYN:15ms+POST:1264ms+Up:22636ms)
IPv4+TCP1194+https.zip: 16,366 Mb/s (DNS:63ms+SYN:15ms+POST:1311ms+Up:24445ms)
IPv4+TCP6881+http .zip: 17,661 Mb/s (DNS:62ms+SYN:32ms+POST:1248ms+Up:22651ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP8080+http .zip: 17,661 Mb/s (DNS:109ms+SYN:16ms+POST:1295ms+Up:0ms)
05/07/2016 19:40:01 Appuyez sur une touche pour quitter.
C'est bizarre ces erreurs de division par zéro.
-
Pas vraiment, y a un soucis avec le serveur donc le script se plante.
-
Pas vraiment, y a un soucis avec le serveur donc le script se plante.
Les valeurs comme "IPv4+TCP993 +https.jpg: 17,761 Mb/s (DNS:140ms+SYN:47ms+GET:301441ms+Down:0ms)" sont très étranges, je n'ai pas ce comportement.
Les erreurs de division par zéro viennent des "Down:0ms".
Le serveur a effectivement un soucis sur le port 8080.
Sous Linux il y a aussi https://github.com/kgersen/neutrality-test/ (Je ne sais pas s'il y a un package Windows quelque part, kgersen avait expliqué comment en faire un).
-
Bon sans surprise la conseillère qui à ouvert mon incident le 04/07/2016 n'à pas du tout compris mon souci, elle à reporté une perte de synchronisation ce qui n'est pas du tout cas ??? , le ticket à été clôturé aujourd'hui sans compte rendu j'ai donc décidé de rappeler aujourd'hui et j'ai expliqué ma situation à un conseiller, qui a vu avec son référant technique, il en retourne que mon cas est du "jamais vu" et l'incident à été remonté au niveau 2, avec les bonnes informations cette fois-ci, réponse sous 5 jours ouvrés.
-
Salut,
De mon côté je viens de repasser chez Free en FTTH @ZMD après environ 2ans chez Orange (je suis sur Chatou dans le 78)
Voici le résultat du test-neutralite.bat
08/07/2016 20:41:23 Téléchargement de 200 Mo depuis 3.testdebit.info :
IPv4+TCP80 +http .zip: 409,836 Mb/s (DNS:16ms+SYN:0ms+GET:0ms+Down:3906ms)
IPv4+TCP80 +http .jpg: 409,836 Mb/s (DNS:15ms+SYN:0ms+GET:0ms+Down:3906ms)
IPv4+TCP80 +http .mp4: 544,959 Mb/s (DNS:16ms+SYN:31ms+GET:0ms+Down:2937ms)
IPv4+TCP80 +http .pdf: 550,964 Mb/s (DNS:31ms+SYN:16ms+GET:0ms+Down:2906ms)
IPv4+TCP443 +https.zip: 214,362 Mb/s (DNS:15ms+SYN:0ms+GET:500ms+Down:7469ms)
IPv4+TCP443 +https.jpg: 238,948 Mb/s (DNS:16ms+SYN:16ms+GET:312ms+Down:6703ms)
IPv4+TCP554 +http .zip: 500,0 Mb/s (DNS:16ms+SYN:0ms+GET:0ms+Down:3203ms)
IPv4+TCP554 +http .jpg: 507,614 Mb/s (DNS:0ms+SYN:15ms+GET:0ms+Down:3157ms)
IPv4+TCP554 +http .mp4: 359,712 Mb/s (DNS:16ms+SYN:0ms+GET:0ms+Down:4453ms)
IPv4+TCP993 +https.zip: 231,213 Mb/s (DNS:31ms+SYN:16ms+GET:625ms+Down:6922ms)
IPv4+TCP993 +https.jpg: 165,16 Mb/s (DNS:16ms+SYN:0ms+GET:390ms+Down:9703ms)
IPv4+TCP1194+https.zip: 207,468 Mb/s (DNS:15ms+SYN:47ms+GET:344ms+Down:7719ms)
IPv4+TCP1194+https.jpg: 257,400 Mb/s (DNS:15ms+SYN:0ms+GET:297ms+Down:6219ms)
IPv4+TCP6881+http .zip: 560,224 Mb/s (DNS:0ms+SYN:47ms+GET:0ms+Down:2859ms)
IPv4+TCP6881+http .jpg: 560,224 Mb/s (DNS:0ms+SYN:15ms+GET:0ms+Down:2860ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP8080+http .zip: 560,224 Mb/s (DNS:15ms+SYN:16ms+GET:16ms+Down:0ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP8080+http .jpg: 560,224 Mb/s (DNS:15ms+SYN:0ms+GET:0ms+Down:0ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP8080+http .mp4: 560,224 Mb/s (DNS:31ms+SYN:0ms+GET:0ms+Down:0ms)
IPv6+TCP80 +http .zip: 539,83 Mb/s (DNS:125ms+SYN:31ms+GET:0ms+Down:2969ms)
IPv6+TCP80 +http .jpg: 542,5 Mb/s (DNS:266ms+SYN:31ms+GET:0ms+Down:2953ms)
IPv6+TCP80 +http .mp4: 497,512 Mb/s (DNS:15ms+SYN:16ms+GET:0ms+Down:3219ms)
IPv6+TCP443 +https.zip: 192,864 Mb/s (DNS:140ms+SYN:0ms+GET:516ms+Down:8297ms)
IPv6+TCP554 +http .zip: 523,560 Mb/s (DNS:16ms+SYN:15ms+GET:0ms+Down:3063ms)
IPv6+TCP1194+https.zip: 191,570 Mb/s (DNS:79ms+SYN:15ms+GET:563ms+Down:8359ms)
IPv6+TCP6881+http .zip: 523,560 Mb/s (DNS:31ms+SYN:16ms+GET:0ms+Down:3062ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv6+TCP8080+http .zip: 523,560 Mb/s (DNS:63ms+SYN:31ms+GET:0ms+Down:0ms)
08/07/2016 20:43:22 Emission de 200 Mo vers 3.testdebit.info :
IPv4+TCP80 +http .zip: 174,825 Mb/s (DNS:15ms+SYN:0ms+POST:703ms+Up:9157ms)
IPv4+TCP80 +http .jpg: 179,372 Mb/s (DNS:16ms+SYN:0ms+POST:375ms+Up:8922ms)
IPv4+TCP80 +http .mp4: 170,212 Mb/s (DNS:47ms+SYN:0ms+POST:282ms+Up:9406ms)
IPv4+TCP443 +https.zip: 155,884 Mb/s (DNS:16ms+SYN:47ms+POST:422ms+Up:10265ms)
IPv4+TCP554 +http .zip: 175,131 Mb/s (DNS:16ms+SYN:0ms+POST:250ms+Up:9140ms)
IPv4+TCP1194+https.zip: 155,642 Mb/s (DNS:16ms+SYN:31ms+POST:375ms+Up:10282ms)
IPv4+TCP6881+http .zip: 174,520 Mb/s (DNS:47ms+SYN:31ms+POST:875ms+Up:9172ms)
Erreur de division par zéro.
Erreur de division par zéro.
IPv4+TCP8080+http .zip: 174,520 Mb/s (DNS:31ms+SYN:0ms+POST:438ms+Up:0ms)
IPv6+TCP80 +http .zip: 178,94 Mb/s (DNS:15ms+SYN:0ms+POST:344ms+Up:8984ms)
IPv6+TCP80 +http .jpg: 180,18 Mb/s (DNS:0ms+SYN:16ms+POST:250ms+Up:8890ms)
IPv6+TCP80 +http .zip: 178,94 Mb/s (DNS:16ms+SYN:15ms+POST:360ms+Up:8984ms)
IPv6+TCP443 +https.zip: 158,856 Mb/s (DNS:16ms+SYN:0ms+POST:469ms+Up:10078ms)
Nombre non valide. Les nombres sont limités à une précision de 32 bits
IPv6+TCP554 +http .zip: 0,0 Mb/s (DNS:20447828000ms+SYN:-2147483585ms+POST:16ms+
Up:500ms)
IPv6+TCP1194+https.zip: 160,771 Mb/s (DNS:16ms+SYN:0ms+POST:359ms+Up:9953ms)
Nombre non valide. Les nombres sont limités à une précision de 32 bits
IPv6+TCP6881+http .zip: 0,0 Mb/s (DNS:21226937000ms+SYN:-2147483631ms+POST:15ms+
Up:344ms)
IPv6+TCP8080+http .zip: 0,0 Mb/s (DNS:0ms+SYN:15ms+POST:0ms+Up:235ms)
08/07/2016 20:45:46 Appuyez sur une touche pour quitter.
D'après mes premiers tests ça semble aussi rapide que chez Orange niveau speedtest, nperf et Youtube
-
Toi aussi tu as le bug sur le port 6881 on dirait.
-
Toi aussi tu as le bug sur le port 6881 on dirait.
La division par 0 est sur le port 8080, c'est le serveur qui remonte une erreur.
Pour le "Nombre non valide. Les nombres sont limités à une précision de 32 bits" sur l'upload IPv6 sur les ports 554 et 6681, je ne sais pas d'où ça vient.
Là, ce que je vois surtout, ce sont de mauvaises performances en https (un vieux PC ?).
-
Oui mon PC est pas tout jeune (2007 ou 2008 je ne sais plus quand je l'ai monté). Un core2duo e6600 avec 4go de RAM (mais un SSD:)) je suis clairement limité de ce côté la!
-
Pour le "Nombre non valide. Les nombres sont limités à une précision de 32 bits" sur l'upload IPv6 sur les ports 554 et 6681, je ne sais pas d'où ça vient.
Effectivement j'avais pas vu que c'était l'up.
-
Salut,
De mon côté je viens de repasser chez Free en FTTH @ZMD après environ 2ans chez Orange (je suis sur Chatou dans le 78)
D'après mes premiers tests ça semble aussi rapide que chez Orange niveau speedtest, nperf et Youtube
Et tu es raccordé à quel NRO? CAR78?
-
Bonjour
Pas de NRO CAR78, Carrieres sur Seine est d'ailleurs relié sur Sartrouville et peut-être une partie sur Houilles.
Pour Chatou le NRA/NRO c'est MTS78 (Montesson)
-
En ADSL j'étais sur VES78 de mémoire. La je ne sais pas encore vu que je n'ai toujours pas accès a l'interface de gestion (sauf si il y a un autre moyen pour savoir?)
-
Ah oui ,tu as raison, certains quartiers de Chatou sont reliés sur Le Vesinet. Si tu étais sur VES78 tu dois l'être encore, à mon avis.
-
Bonjour
Pas de NRO CAR78, Carrieres sur Seine est d'ailleurs relié sur Sartrouville et peut-être une partie sur Houilles.
Pour Chatou le NRA/NRO c'est MTS78 (Montesson)
Oui, je me suis trompé mon NRO est 78586SAT
-
Je suis sur 78418MTS
-
Redémarrage en mode secours: pas d'amélioration
Redémarrage en mode normal mais freebox en mode bridge: ça fonctionne (avec le DNS google 8.8.8.8, pas avec le DNS free 212.27.40.240 & 212.27.40.241)
Finalement j'ai trouvé mon d'où cela venait: du contrôle parental, le filtre par défaut était sur "Accès web uniquement", j'ai ajouté mes périphérique dans un filtre manuel "Accès internet autorisé" et roule ma poule.
Désolé les gars, ce n'était rien :-[