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! -- 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 [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: http://lists.debian.org/[email protected]
