Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 04/08/2010 18:13, Pascal Hambourg a écrit :
> 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.
>
firestarter a toutjours le dernier mot malheureusement. Une possibilité
est de modifier a la main le fichier sysctl-tuning de firestarter...mais
c est po tres satisfaisant.
>> 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.
>
bon je teste ca des que je suis sur mon LAN.
ce que je peux te dire direct c'est que sous backtrack 4 les valeurs
sont a 1 et la mtu a 1492 et que ca marche.
Merci!
Reply to: