Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggz a écrit :
>>>
>> les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
>> Est ce normal ?
Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options
n'existaient pas lors de la conception initiale de TCP, et si la machine
en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont
essentiellement pour but d'augmenter les performances dans certaines
circonstances : produit débit*latence élevé, pertes de paquets,
nombreuses connexions...
> Bon ça avance!!! si je force via sysctl.conf la valeur de
> net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres
> valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le
> résultat.
Tu pouvais tester en modifiant directement la valeur du paramètre du
noyau en ligne de commande avec
sysctl -w net.ipv4.tcp_timestamps=1
(le -w n'est apparemment plus obligatoire pour modifier un paramètre)
(ou echo 1 > /proc/sys/net/ipv4/tcp_timestamps mais c'est laid)
d'autant plus que le résultat final au démarrage dépend de l'ordre dans
lequel firestarter et le script qui applique sysctl.conf sont exécutés.
> et c'est bien firestarter qui modifie cette valeur:
> dans /etc/firestarter/sysctl-tuning on a la valeur de
> net.ipv4.tcp.timestamps forcé à 0.
>
> Bon je suppose que si cette variable est forcée à 0 il doit y avoir une
> bonne raison.
Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas
correctement ces options, aussi il est parfois nécessaire de les
désactiver. Sinon je ne vois pas trop.
> je suppose que le rapport de bug doit plutot aller au
> maintenant du driver atl1c, non ?
Je vais encore te donner du travail, mais pourrais-tu vérifier si
tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en
fonction du MTU avec les autres distributions installées sur la machine
(sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug.
En gros vérifier sur chacune si (si j'ai bien compris) :
- MTU=1492 et tcp_timestamps=0 -> bug
- MTU=1500 ou tcp_timestamps=1 -> ok
En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug.
Reply to: