Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Pb de transfert de fichiers entre un NAS et une debian lenny backport

Pb de transfert de fichiers entre un NAS et une debian lenny backport

35 réponses
Avatar
giggz
Bonjour,

derrière mon routeur j'ai :
un NAS
un laptop
un eeepc

le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
machines. Chaque machine a une ip fixe attribuée par le routeur.

je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
les suivants :
- je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
transfère 12K... :D

Voilà ce que j'ai tenté :
- j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
- j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
- je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
- j'ai pensé à un problème de droits: les users sont les mêmes entre mon
laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger
dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K...
- j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai
activé le parefeu en laissant tout ouvert...le problème persiste...

bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut
venir...et surtout où chercher...

j'ai oublié de préciser: j'ai évidemment regarder les logs (messages,
syslog, auth, user) et rien de rien...

Merci d'avance
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/i30v7e$ina$1@dough.gmane.org
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Jean-Yves F. Barbier
Le Sun, 01 Aug 2010 23:46:33 +0200,
giggz a écrit :

Le 01/08/2010 23:39, Jean-Yves F. Barbier a écrit :
> Le Sun, 01 Aug 2010 23:32:03 +0200,
> giggz a écrit :
>
> ...
>> J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne chang e rien. De
>> plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout m arche
>> très bien entre ce laptop et le NAS.
>
> la valeur std pour un LAN est de 1500 bytes.
>

je sais...mais malheureusement mon routeur force la valeur à 1492 au
moment où il y a dialogue avec le serveur dhcp. En gros si je foncti onne
en ip fixe je peux forcer la mtu à 1500. mais si je laisse le dhcp f aire
son travail j'ai tjs une mtu à 1492. bon en même temps c'est po très
grave si tout est à 1492, non ?



ça dépend à combien est le router du côté WAN.

c'est une valeur qu'il fallait souvent forcer il-y-a une dizaine d'annà ©e,
mais plus maintenant; je me rappelle qu'avec le câble, un déphasa ge entre
1492 et 1500 pouvait mener jusqu'à -80% de perfs sur le LAN.
en gros, c'est plus rapide de fragmenter.

--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
giggzounet
Le 31/07/2010 12:51, giggz a écrit :
Bonjour,

derrière mon routeur j'ai :
un NAS
un laptop
un eeepc

le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
machines. Chaque machine a une ip fixe attribuée par le routeur.

je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
les suivants :
- je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
transfère 12K... :D

Voilà ce que j'ai tenté :
- j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
- j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
- je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
- j'ai pensé à un problème de droits: les users sont les mêmes entre mon
laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger
dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K...
- j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai
activé le parefeu en laissant tout ouvert...le problème persiste...

bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut
venir...et surtout où chercher...

j'ai oublié de préciser: j'ai évidemment regarder les logs (messages,
syslog, auth, user) et rien de rien...




Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il
y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le
laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot
de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut
avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ?

Merci

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i35uvb$i85$
Avatar
giggzounet
Le 02/08/2010 10:17, giggzounet a écrit :
Le 31/07/2010 12:51, giggz a écrit :
Bonjour,

derrière mon routeur j'ai :
un NAS
un laptop
un eeepc

le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
machines. Chaque machine a une ip fixe attribuée par le routeur.

je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
les suivants :
- je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
transfère 12K... :D

Voilà ce que j'ai tenté :
- j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
- j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
- je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
- j'ai pensé à un problème de droits: les users sont les mêmes entre mon
laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger
dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K...
- j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai
activé le parefeu en laissant tout ouvert...le problème persiste...

bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut
venir...et surtout où chercher...

j'ai oublié de préciser: j'ai évidemment regarder les logs (messages,
syslog, auth, user) et rien de rien...




Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il
y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le
laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot
de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut
avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ?

Merci




J'ai aussi fait des tests entre mon eeepc et un fixe qui est aussi sur
mon LAN et je nai aucun probleme pour monter un partage NFS et
telecharger de gros fichiers dessus. Le probleme se concentre donc entre
mon NAS et mon eeepc et uniquement en download (quelque soit la méthode
utilisée: ftp, samba ou nfs).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i35vc4$jfg$
Avatar
Pascal Hambourg
Christophe a écrit :

Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
tient pas compte.



Non, car même si le MTU est réglé plus bas, une interface ethernet
accepte quand même les trames de 1500 octets (voire plus).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Christophe
Bonjour,

Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
Christophe a écrit :
>
> Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
> contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
> tient pas compte.

Non, car même si le MTU est réglé plus bas, une interface ethernet
accepte quand même les trames de 1500 octets (voire plus).




La commande 'ip link set dev <if> mtu <mtu>' tente de régler la MTU pour
la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
elle supporte cette MTU en dur. La notion dont tu parles est valide si
tu restreins ta MTU sur des routes, auquel cas l'interface pourra
entendre des paquets plus gros que la MTU assignée à la route en
question. Mais rien ne garantit que l'interface entendra au dessus de la
MTU qui lui est assignée par ip link.

Sous MS Windows, les réglages sont plus clairs : les options avancées de
la carte réseau permettent de régler la MTU "dure" ou la longueur de
trame de l'interface (souvent appelée "jumbo frames", avec des valeurs
discrètes), et 'netsh interface ipv4 show global' t'indique la MTU
utilisée par la pile IP pour cette liaison. Linux règle les deux depuis
la commande 'ip link'.

Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
un deuxième (mon portable, avec une Marvell 88E8072).
Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
et fragmente ses réponses.

Cordialement,

--
Christophe


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
Christophe a écrit :

Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
Non, car même si le MTU est réglé plus bas, une interface ethernet
accepte quand même les trames de 1500 octets (voire plus).



La commande 'ip link set dev <if> mtu <mtu>' tente de régler la MTU pour
la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
elle supporte cette MTU en dur.



MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne
devrait pas être affecté.

Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
un deuxième (mon portable, avec une Marvell 88E8072).
Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
et fragmente ses réponses.



Je suis surpris car d'une part car chez moi ça marche, et d'autre part
1495 reste inférieur à la taille du paquet de requête écho (1500) donc
ce n'est pas cohérent.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
Le Mon, 02 Aug 2010 14:44:20 +0200,
Christophe a écrit :

...
Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
un deuxième (mon portable, avec une Marvell 88E8072).
Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
et fragmente ses réponses.



J'abonde dans le sens de Pascal: chez moi aussi ça marche sans PB (ave c le
temps de réponse qui fait évidemment un bond lors de la fragmenta tion.)

--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
giggz a écrit :

En gros voilà ce que j'ai fait :
je me connecte sur mon NAS en ftp -p
ensuite je me balade dans mes répertoires et lance un get.
rien ne se passe.
je fais un ctrl+c
et encore un autre.
puis "bye"
et voilà.



Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein.
Ce que j'ai relevé comme bizarreries ou anomalies :


- Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
a normalement un certain nombre d'options TCP activées par défaut :
timestamp, selective ACK, window scaling...

- Des checksums sont indiqués comme incorrects. Apparemment cela se
produit avec les segments émis par le client contenant des données et
ayant le flag P (PSH, Push) activé. Dans cette trace tous les segments
émis par client avec des données ont le flag P, donc je ne sais pas si
c'est la présence de données ou le flag P qui provoque ça. Mais ça n'a
pas l'air de gêner la communication puisque le serveur acquitte ces
segments. C'est peut-être un faux positif causé par de l'offloading
(traitement déporté, par exemple segmentation et calcul du checksum) de
TCP dans l'interface réseau à la place du noyau.

- Le serveur envoie régulièrement des segments des données avec un
offset et une longueur aberrants : longueur des données 1444 au lieu de
1452 conformément au MSS annoncé par le client, et offset largement
au-delà de l'offset courant. Cela se produit systématiquement juste
après la séquence de synchronisation de la connexion de données lorsque
le transfert nécessite plus d'un segment :

séquence de synchronisation :

14:25:12 IP (id 17251, proto TCP (6), length 44) client.dat5 > serveur.dat5: S, 2994688280:2994688280(0) win 5808 <mss 1452>
14:25:12 IP (id 0, proto TCP (6), length 44) serveur.dat5 > client.dat5: S, 658576691:658576691(0) ack 2994688281 win 5840 <mss 1460>
14:25:12 IP (id 17252, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1 win 5808



2 segments aberrants :

14:25:12 IP (id 24813, proto TCP (6), length 1484) serveur.dat5 > client.dat5: . 1461:2905(1444) ack 1 win 5840
14:25:12 IP (id 17253, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1 win 5808
14:25:12 IP (id 24815, proto TCP (6), length 1484) serveur.dat5 > client.dat5: P 4365:5809(1444) ack 1 win 5840
14:25:12 IP (id 17254, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1 win 5808



Le client répond à chaque fois qu'il attend l'offset 1. Après un délai
de 3 secondes des segments normaux sont ensuite transmis par le serveur
et acquittés par le client :

14:25:15 IP (id 24816, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 1:1453(1452) ack 1 win 5840
14:25:15 IP (id 17255, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1453 win 8712
14:25:15 IP (id 24817, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 1453:2905(1452) ack 1 win 5840
14:25:15 IP (id 17256, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 2905 win 11616
14:25:15 IP (id 24818, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 2905:4357(1452) ack 1 win 5840
14:25:15 IP (id 17257, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 4357 win 14520
14:25:15 IP (id 24819, proto TCP (6), length 1492) serveur.dat5 > client.dat5: P 4357:5809(1452) ack 1 win 5840
14:25:15 IP (id 17258, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 5809 win 17424



Puis à nouveau un segment aberrant :

14:25:15 IP (id 24821, proto TCP (6), length 1484) serveur.dat5 > client.dat5: . 7269:8713(1444) ack 1 win 5840
14:25:15 IP (id 17259, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 5809 win 17424



Après un nouveau délai de 6 secondes cette fois, ça repart :

14:25:21 IP (id 24822, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 5809:7261(1452) ack 1 win 5840
14:25:21 IP (id 17260, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 7261 win 20328
14:25:21 IP (id 24823, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 7261:8713(1452) ack 1 win 5840
14:25:21 IP (id 17261, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 8713 win 23232



(Ces délais sont responsables de la lenteur de réception de fichiers qui
réussissent à passer.)

Et ça continue, avec des délais en augmentation jusqu'à ce que le client
perde patience et interrompe le transfert.

Je n'ai pas d'explication à proposer pour le moment. Il pourrait être
intéressant de comparer les traces avec les autres machine/distribution
qui marchent.

Quelle est la version du noyau de BackTrack ?
Quel est le type de l'interface réseau de l'Eee PC ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
giggz
Le 01/08/2010 23:10, Christophe a écrit :
Bonjour,

Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit :
Le 31/07/2010 14:39, Pascal Hambourg a écrit :
giggz a écrit :

question de NooB : les login/password en ftp sont en clair. si je
copie/colle ce que me sort tcpdump, est ce que mon login/password est
lisible ?



Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP
(wireshark/tshark si en revanche) et n'affiche pas non plus les données
des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être
des versions.




ok. je joins le fichier en question. apparemment je ne vois pas mon mot
de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou
non changer mon password ;)

En gros voilà ce que j'ai fait :
je me connecte sur mon NAS en ftp -p
ensuite je me balade dans mes répertoires et lance un get.
rien ne se passe.
je fais un ctrl+c
et encore un autre.
puis "bye"
et voilà.

Merci d'avance
Guillaume



Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
tient pas compte.
Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et
la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route
flush cache'.




nouveau rebondissement:

j'ai remis ma mtu de mon NAS à 1500. et j'ai tapé les commandes de
christopĥe ci-dessus sur mon eeepc. je me retrouve donc avec une mtu de
1500 et là ça marche parfaitement...

bon la question est maintenant de savoir pourquoi ça marche pas avec une
mtu plus basse...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i36u25$e8s$
Avatar
giggz
Le 02/08/2010 18:14, Pascal Hambourg a écrit :
giggz a écrit :

En gros voilà ce que j'ai fait :
je me connecte sur mon NAS en ftp -p
ensuite je me balade dans mes répertoires et lance un get.
rien ne se passe.
je fais un ctrl+c
et encore un autre.
puis "bye"
et voilà.



Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein.
Ce que j'ai relevé comme bizarreries ou anomalies :


- Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
a normalement un certain nombre d'options TCP activées par défaut :
timestamp, selective ACK, window scaling...

- Des checksums sont indiqués comme incorrects. Apparemment cela se
produit avec les segments émis par le client contenant des données et
ayant le flag P (PSH, Push) activé. Dans cette trace tous les segments
émis par client avec des données ont le flag P, donc je ne sais pas si
c'est la présence de données ou le flag P qui provoque ça. Mais ça n'a
pas l'air de gêner la communication puisque le serveur acquitte ces
segments. C'est peut-être un faux positif causé par de l'offloading
(traitement déporté, par exemple segmentation et calcul du checksum) de
TCP dans l'interface réseau à la place du noyau.

- Le serveur envoie régulièrement des segments des données avec un
offset et une longueur aberrants : longueur des données 1444 au lieu de
1452 conformément au MSS annoncé par le client, et offset largement
au-delà de l'offset courant. Cela se produit systématiquement juste
après la séquence de synchronisation de la connexion de données lorsque
le transfert nécessite plus d'un segment :

séquence de synchronisation :

14:25:12 IP (id 17251, proto TCP (6), length 44) client.dat5 > serveur.dat5: S, 2994688280:2994688280(0) win 5808 <mss 1452>
14:25:12 IP (id 0, proto TCP (6), length 44) serveur.dat5 > client.dat5: S, 658576691:658576691(0) ack 2994688281 win 5840 <mss 1460>
14:25:12 IP (id 17252, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1 win 5808



2 segments aberrants :

14:25:12 IP (id 24813, proto TCP (6), length 1484) serveur.dat5 > client.dat5: . 1461:2905(1444) ack 1 win 5840
14:25:12 IP (id 17253, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1 win 5808
14:25:12 IP (id 24815, proto TCP (6), length 1484) serveur.dat5 > client.dat5: P 4365:5809(1444) ack 1 win 5840
14:25:12 IP (id 17254, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1 win 5808



Le client répond à chaque fois qu'il attend l'offset 1. Après un délai
de 3 secondes des segments normaux sont ensuite transmis par le serveur
et acquittés par le client :

14:25:15 IP (id 24816, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 1:1453(1452) ack 1 win 5840
14:25:15 IP (id 17255, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 1453 win 8712
14:25:15 IP (id 24817, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 1453:2905(1452) ack 1 win 5840
14:25:15 IP (id 17256, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 2905 win 11616
14:25:15 IP (id 24818, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 2905:4357(1452) ack 1 win 5840
14:25:15 IP (id 17257, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 4357 win 14520
14:25:15 IP (id 24819, proto TCP (6), length 1492) serveur.dat5 > client.dat5: P 4357:5809(1452) ack 1 win 5840
14:25:15 IP (id 17258, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 5809 win 17424



Puis à nouveau un segment aberrant :

14:25:15 IP (id 24821, proto TCP (6), length 1484) serveur.dat5 > client.dat5: . 7269:8713(1444) ack 1 win 5840
14:25:15 IP (id 17259, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 5809 win 17424



Après un nouveau délai de 6 secondes cette fois, ça repart :

14:25:21 IP (id 24822, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 5809:7261(1452) ack 1 win 5840
14:25:21 IP (id 17260, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 7261 win 20328
14:25:21 IP (id 24823, proto TCP (6), length 1492) serveur.dat5 > client.dat5: . 7261:8713(1452) ack 1 win 5840
14:25:21 IP (id 17261, proto TCP (6), length 40) client.dat5 > serveur.dat5: ., ack 8713 win 23232



(Ces délais sont responsables de la lenteur de réception de fichiers qui
réussissent à passer.)

Et ça continue, avec des délais en augmentation jusqu'à ce que le client
perde patience et interrompe le transfert.

Je n'ai pas d'explication à proposer pour le moment. Il pourrait être
intéressant de comparer les traces avec les autres machine/distribution
qui marchent.

Quelle est la version du noyau de BackTrack ?
Quel est le type de l'interface réseau de l'Eee PC ?




tout d'abord merci de ton analyse!

backtrack 4 se base sur Ubuntu et j'ai un noyau 2.6.30.9
sous backtrack qd je boote j'ai aussi une mtu de 1492. mais je n'ai pas
de problème particulier pour télécharger des fichiers depuis mon NAS.

l'interface réseau est une interface ethernet gérer par le module atl1c.

je vais tenter de faire une capture sous forme de fichier pcap.

à plus tard,
Guillaume


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i36uv9$j6t$
1 2 3 4