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

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

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 ?