[RESEAU] problème de téléchargement bizarre

Support Debian
#1

Bonsoir,

J’ai la fibre optique orange 200M depuis 1 an, jusque là, je téléchargeais à 35Mo/s sans problème.

Mais depuis 1 semaine, il m’est impossible de télécharger des fichiers de plus de 11,4Mo, sur un PC, 9,12Mo sur un autre, etc… sur 4 machines. La taille max tourne autour des 10Mo à chaque fois. Même problème sur les machines virtuelles.

Quelqu’un saurait ce qui peut provoquer ce genre de panne ?

Je suppose fortement un problème coté box ou fournisseur d’accès… Un technicien va venir jeudi mais avant qu’il vienne j’aimerai être sûr que celà ne peut pas provenir d’ailleurs.

Toutes mes machines sont sous debian testing, sauf un serveur en stable. Toutes sont mises à jour. Je n’ai pas de windows pour voir ce que ça donnerai.

Merci :slightly_smiling:

#2

As-tu testé depuis différentes sources ?
Que se passe-t-il exactement lorsque la limite est atteinte ? Ça part en time-out ou ça s’arrête immédiatement ? Y a-t-il une erreur ?
As-tu un proxy ?

#3

Hummmm ca sent la limitation de BP suite à des DL

Tu DL sous quelle forme?

Ensuite une question as tu bien formulé est ce que la bande passante est passée de 200 à 9/12Mo ou est ce que le téléchargement s’arrête au bout d’un volume de 9/12mo?

Si c’est la première option rien de grave tu as un souci de ligne, par contre si c’est la deuxieme ton fai te bloque le dl de fichiers de grands volumes en bridant certains ports ou en stoppant purement et simplement le téléchargement. (ps: plus radical qu’hadopi)

openclassrooms.com/courses/conto … rtains-fai

#4

Je télécharge avec wget ou le navigateur. Le résultat est le même.

Il n’y a pas de proxy.

Le téléchargement ne plante pas, il reste bloqué sur 11,40Mo téléchargés, et le debit fini par afficher --.-KB/s indéfiniement :

[code]wget http://test-debit.free.fr/image.iso
–2014-12-07 19:32:00-- http://test-debit.free.fr/image.iso
Résolution de test-debit.free.fr (test-debit.free.fr)… 212.27.42.153
Connexion à test-debit.free.fr (test-debit.free.fr)|212.27.42.153|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 678428672 (647M) [application/x-iso9660-image]
Sauvegarde en : « image.iso »

image.iso 1%[ ] 11,40M --.-KB/s eta 35m 5s[/code]

J’ai téléchargé des fichiers sur
http://test-debit.free.fr/image.iso
mais aussi les iso debian : http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/7.7.0/i386/iso-cd/firmware-7.7.0-i386-netinst.iso ou http://paris.cdn.mediactive-network.net/speedtest/100Mo.dat

La valeur max de données téléchargées avant que le problème arrive n’est pas la même selon le site ou le fichier. Ca n’ pas l’air d’arriver après un temps défini, car sur certains sites, j’ai un débit 5 fois moins rapide, et ça bloque aussi vers les 10Mo.
Par contre, quelque soit le PC, pour un fichier téléchargé, le bloquage se produit après une même quantité téléchargée.
Donc le wget du dessus s’arrête au même endroit sur tous mes PC.

J’ai réinitialisé la box, me suis branché par cable en direct, en ayant débranché tout autre appareil. Boitier TV, serveurs, switch etc… même résultat.

Évidement, la télévision ne fonctionne plus. J’ai passé 1h avec le technicien au téléphone, s’il y avait eu un bridage, je pense qu’il me l’aurai signalé.

#5

Forte probabilité que ton fai te bride

#6

Du jour au lendemain ? En plus, le mec que j’ai eu au téléphone me l’aurai signalé plutôt que de m’envoyer un technicien jeudi matin ?

Je ne sais pas ce qu’il va faire pour le coup… Refaire la même chose que j’ai fait… à moins qu’ils puisse tester les fibres…

EDIT: et pourquoi brider ainsi ? c’est stupide, en général ils brident le débit. Parce que là, ma connexion est inutilisable. Dès que je veux faire une mise à jour. Ca me coince sur chaque fichiers de plus de 10Mo. Sans compter que la télévision ne fonctionne plus non plus.
Sans connexion 3g du téléphone, je serais coincé.

#7

[quote=“vohu”]Du jour au lendemain ? En plus, le mec que j’ai eu au téléphone me l’aurai signalé plutôt que de m’envoyer un technicien jeudi matin ?

Je ne sais pas ce qu’il va faire pour le coup… Refaire la même chose que j’ai fait… à moins qu’ils puisse tester les fibres…

EDIT: et pourquoi brider ainsi ? c’est stupide, en général ils brident le débit. Parce que là, ma connexion est inutilisable. Dès que je veux faire une mise à jour. Ca me coince sur chaque fichiers de plus de 10Mo. Sans compter que la télévision ne fonctionne plus non plus.
Sans connexion 3g du téléphone, je serais coincé.[/quote]

Ton FAI t’envoie un technicien qu’il va te facturer.

Tu as beaucoup DL pendant un an?

#8

Une fibre optique ne compte pas les octets transmis dans une connexion TCP.
Je serais aussi surpris que ce soit un bridage volontaire. As-tu un quota dans ton abonnement ?
Par curiosité, as-tu testé avec d’autres protocoles comme FTP ou HTTPS ?

#9

Qu’est ce qu’on appelle " télécharger beaucoup " ?

  • Je tiens un mirroir des dépots debian et d’autres distrib.
  • je transfère beaucoup de données entre 2 serveurs. (des Tera et des Tera, ça, c’est sûr, c’est pour ça que je voulais la fibre !)
  • niveau film ?.. non, je télécharge pas.

Ils factureront rien puisque c’est lui qui m’a envoyé le technicien, j’ai rien demandé. (s’ils le font, je fais opposition et je résilie dans la foulée… faut pas se fiche des gens…)
Je veux juste que ça fonctionne.

Maintenant, si ce que tu me dis est vrai, ça mérite clairement de porter plainte. Ils n’ont pas à brider sans prévenir. Ni à facturer quoi que ce soit sans l’avoir précisé avant.

PascalHambourg > non aucun quota, mais ce serait aussi une façon bizarre de procéder à une limitation.

pour le transfert en ftp :

[code]wget ftp://debian.netcologne.de/debian-cd/7.7.0/amd64/iso-cd/debian-7.7.0-amd64-CD-1.iso
–2014-12-07 20:12:38-- ftp://debian.netcologne.de/debian-cd/7.7.0/amd64/iso-cd/debian-7.7.0-amd64-CD-1.iso
=> « debian-7.7.0-amd64-CD-1.iso.1 »
Résolution de debian.netcologne.de (debian.netcologne.de)… 194.8.197.22, 2001:4dd0:1234:1::deb
Connexion à debian.netcologne.de (debian.netcologne.de)|194.8.197.22|:21… connecté.
Ouverture de session en tant que anonymous… Session établie.
==> SYST … terminé. ==> PWD … terminé.
==> TYPE I … terminé. ==> CWD (1) /debian-cd/7.7.0/amd64/iso-cd … terminé.
==> SIZE debian-7.7.0-amd64-CD-1.iso … 665845760
==> PASV … terminé. ==> RETR debian-7.7.0-amd64-CD-1.iso … terminé.
Taille : 665845760 (635M) (non certifiée)

debian-7.7.0-amd64-CD-1.iso.1 0%[ ] 4,09M --.-KB/s eta 18m 46s[/code]

https je trouve pas de sites publics avec ça.

#10

kernel.org ?

Apparemment c’est encore pire en FTP…

#11

ha ??? je suis loin des débits habituels (mais c’est peut être le site qui limite la bande passante)
Mais ça fonctionne !

Je ne sais pas quelle conclusion en tirer…

[code]wget https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.18-rc7.tar.xz
–2014-12-07 20:48:05-- https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.18-rc7.tar.xz
Résolution de www.kernel.org (www.kernel.org)… 149.20.4.69, 199.204.44.194, 198.145.20.140, …
Connexion à www.kernel.org (www.kernel.org)|149.20.4.69|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 80927772 (77M) [application/x-xz]
Sauvegarde en : « linux-3.18-rc7.tar.xz »

linux-3.18-rc7.tar.xz 100%[=============================================================>] 77,18M 4,47MB/s ds 20s

2014-12-07 20:48:26 (3,83 MB/s) — « linux-3.18-rc7.tar.xz » sauvegardé [80927772/80927772]
[/code]

#12

On ne peut guère tirer de conclusion fiable d’un test aussi sommaire. Dommage qu’on ne puisse pas télécharger depuis www.kernel.org en HTTP (accessible mais redirige tout en HTTPS) ou en FTP (non accessible).

Tu as écrit que tu transfères des données entre deux serveurs, je suppose qu’un est sur ton LAN connecté par la fibre et l’autre à l’extérieur ? Est-ce que les transferts fonctionnent encore ? Pourrais-tu tester divers protocoles de transfert en clair (FTP, HTTP) et chiffrés (HTTPS, SFTP/SSH) avec le serveur distant ?

S’il s’avérait que de façon générale le HTTP et le FTP en clair sont interrompus mais pas le HTTPS chiffré, alors on pourrait soupçonner que quelque chose intercepte les connexions non chiffrées (par exemple un proxy transparent) et dysfonctionne.

#13

As-tu moyen de passer par un tunnel SSH par exemple ?
ça ressemble a une mauvaise règle de routeur, qui boucle sur les DNS, en passant par un tunnel tu vas schunter tes règles de routeur.

#14

Peux-tu préciser ta pensée ?
Les routeurs n’utilisent pas de DNS.
Un téléchargement en cours n’utilise pas de DNS. La résolution DNS ne sert que pour récupérer l’adresse IP du serveur.

#15

On a eu récemment exactement le même problème, notre architecture est un peut compliqué, mais les règles du routeur bouclaient entre plusieurs routeurs en interne quand on se connectait sur l’extérieur par un nom de domaine (si le fichier à télécharger était dispo depuis une IP il n’y avait aucun problème).
Quand on passait par un tunnel SSH, tout fonctionnait bien également.

#16

D’après ta description, ce n’est pas du tout le même problème.
Ici le téléchargement commence mais se bloque au bout d’une certaine taille.

#17

PascalHambourg > les transferts entre mes serveurs n’ont pas l’air d’avoir de problèmes.
Par contre le ftp/http en clair je ne peux rien faire pour l’instant, je n’ai pas les ports ouverts sur place.

EDIT : j’ai pu faire le test depuis un chez un pote. En HTTP, ça fonctionne parfaitement aussi.

#18

Quel est le protocole utilisé par ces transferts ?

Quel test, au juste ?

#19

j’utilise rsync en ssh.

Pour le test http, j’ai installé apache et téléchargé puis uploadé un gros fichier avec wget et firefox

#20

Apache et wget/firefox sur quelles machines ?