Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
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
Reply to: