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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c56eee7.8090...@plouf.fr.eu.org