Christophe a écrit :
>
> Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
>> Non, car même si le MTU est réglé plus bas, une interface ethernet
>> accepte quand même les trames de 1500 octets (voire plus).
>
> La commande 'ip link set dev <if> mtu <mtu>' tente de régler la MTU pour
> la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
> elle supporte cette MTU en dur.
MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne
devrait pas être affecté.
> Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
> un deuxième (mon portable, avec une Marvell 88E8072).
> Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
> l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
> et fragmente ses réponses.
Je suis surpris car d'une part car chez moi ça marche, et d'autre part
1495 reste inférieur à la taille du paquet de requête écho (1500) donc
ce n'est pas cohérent.
Christophe a écrit :
>
> Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
>> Non, car même si le MTU est réglé plus bas, une interface ethernet
>> accepte quand même les trames de 1500 octets (voire plus).
>
> La commande 'ip link set dev <if> mtu <mtu>' tente de régler la MTU pour
> la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
> elle supporte cette MTU en dur.
MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne
devrait pas être affecté.
> Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
> un deuxième (mon portable, avec une Marvell 88E8072).
> Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
> l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
> et fragmente ses réponses.
Je suis surpris car d'une part car chez moi ça marche, et d'autre part
1495 reste inférieur à la taille du paquet de requête écho (1500) donc
ce n'est pas cohérent.
Christophe a écrit :
>
> Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
>> Non, car même si le MTU est réglé plus bas, une interface ethernet
>> accepte quand même les trames de 1500 octets (voire plus).
>
> La commande 'ip link set dev <if> mtu <mtu>' tente de régler la MTU pour
> la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
> elle supporte cette MTU en dur.
MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne
devrait pas être affecté.
> Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
> un deuxième (mon portable, avec une Marvell 88E8072).
> Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
> l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
> et fragmente ses réponses.
Je suis surpris car d'une part car chez moi ça marche, et d'autre part
1495 reste inférieur à la taille du paquet de requête écho (1500) donc
ce n'est pas cohérent.
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...
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...
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...
Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
je soupconne firestarter de me modifier tout ca.
Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
je soupconne firestarter de me modifier tout ca.
Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
je soupconne firestarter de me modifier tout ca.
giggzounet a écrit :Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
je soupconne firestarter de me modifier tout ca.
Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.
De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...
giggzounet a écrit :
Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
je soupconne firestarter de me modifier tout ca.
Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.
De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...
giggzounet a écrit :Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
je soupconne firestarter de me modifier tout ca.
Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.
De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...
Le 04/08/2010 01:26, Pascal Hambourg a écrit :giggzounet a écrit :Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
bon je vais regarder ca! je poste ca des que possible.
je soupconne firestarter de me modifier tout ca.
Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.
ben je comprends mais qd on n a pas trop envie de se fatiguer... :)De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...
De mon coté j ai appris via google l'existence d'un autre driver
supportant ma carte: celui du site atheros. il est normalement plus
avancé. j ai donc booté sur mon 2.6.32 et fait un "make install". il
m'installe un driver du nom de atl1e. mais apparemment c'est normal. le
atl1e d'atheros supporte en fait les cartes supportées par les drivers
atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et
modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca
n a pas l air de venir du driver en lui meme.
J ai oublié de préciser:
sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module
atl1e d'atheros.
Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des
bidouille avec ethtool -k/-K.
Le 04/08/2010 01:26, Pascal Hambourg a écrit :
giggzounet a écrit :
Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
bon je vais regarder ca! je poste ca des que possible.
je soupconne firestarter de me modifier tout ca.
Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.
ben je comprends mais qd on n a pas trop envie de se fatiguer... :)
De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...
De mon coté j ai appris via google l'existence d'un autre driver
supportant ma carte: celui du site atheros. il est normalement plus
avancé. j ai donc booté sur mon 2.6.32 et fait un "make install". il
m'installe un driver du nom de atl1e. mais apparemment c'est normal. le
atl1e d'atheros supporte en fait les cartes supportées par les drivers
atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et
modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca
n a pas l air de venir du driver en lui meme.
J ai oublié de préciser:
sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module
atl1e d'atheros.
Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des
bidouille avec ethtool -k/-K.
Le 04/08/2010 01:26, Pascal Hambourg a écrit :giggzounet a écrit :Le 02/08/2010 18:14, Pascal Hambourg a écrit :
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
bon je vais regarder ca! je poste ca des que possible.
je soupconne firestarter de me modifier tout ca.
Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.
ben je comprends mais qd on n a pas trop envie de se fatiguer... :)De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...
De mon coté j ai appris via google l'existence d'un autre driver
supportant ma carte: celui du site atheros. il est normalement plus
avancé. j ai donc booté sur mon 2.6.32 et fait un "make install". il
m'installe un driver du nom de atl1e. mais apparemment c'est normal. le
atl1e d'atheros supporte en fait les cartes supportées par les drivers
atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et
modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca
n a pas l air de venir du driver en lui meme.
J ai oublié de préciser:
sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module
atl1e d'atheros.
Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des
bidouille avec ethtool -k/-K.
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
bon je vais regarder ca! je poste ca des que possible.
les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où
ça vient ?
je soupconne firestarter de me modifier tout ca.
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
bon je vais regarder ca! je poste ca des que possible.
les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où
ça vient ?
je soupconne firestarter de me modifier tout ca.
- 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...
Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ?
Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
bon je vais regarder ca! je poste ca des que possible.
les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où
ça vient ?
je soupconne firestarter de me modifier tout ca.
les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ?
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.
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.
je suppose que le rapport de bug doit plutot aller au
maintenant du driver atl1c, non ?
les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ?
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.
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.
je suppose que le rapport de bug doit plutot aller au
maintenant du driver atl1c, non ?
les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ?
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.
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.
je suppose que le rapport de bug doit plutot aller au
maintenant du driver atl1c, non ?
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) :
- MTU92 et tcp_timestamps=0 -> bug
- MTU00 ou tcp_timestamps=1 -> ok
En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug.
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) :
- MTU92 et tcp_timestamps=0 -> bug
- MTU00 ou tcp_timestamps=1 -> ok
En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug.
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) :
- MTU92 et tcp_timestamps=0 -> bug
- MTU00 ou tcp_timestamps=1 -> ok
En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug.
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) :
- MTU92 et tcp_timestamps=0 -> bug
- MTU00 ou tcp_timestamps=1 -> ok
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) :
- MTU92 et tcp_timestamps=0 -> bug
- MTU00 ou tcp_timestamps=1 -> ok
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) :
- MTU92 et tcp_timestamps=0 -> bug
- MTU00 ou tcp_timestamps=1 -> ok
sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
MTU92 et tcp_timestamps=0 -> bug
MTU92 et tcp_timestamps=1 -> ok
MTU00 ou tcp_timestamps=0 -> ok
MTU00 ou tcp_timestamps=1 -> ok
Ce n'est vraiment que dans le cas où MTU92 et tcp_timestamps=0 que le
bug apparait.
sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
graphique et pas le même driver (b44).
sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
MTU92 et tcp_timestamps=0 -> bug
MTU92 et tcp_timestamps=1 -> ok
MTU00 ou tcp_timestamps=0 -> ok
MTU00 ou tcp_timestamps=1 -> ok
Ce n'est vraiment que dans le cas où MTU92 et tcp_timestamps=0 que le
bug apparait.
sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
graphique et pas le même driver (b44).
sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
MTU92 et tcp_timestamps=0 -> bug
MTU92 et tcp_timestamps=1 -> ok
MTU00 ou tcp_timestamps=0 -> ok
MTU00 ou tcp_timestamps=1 -> ok
Ce n'est vraiment que dans le cas où MTU92 et tcp_timestamps=0 que le
bug apparait.
sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
graphique et pas le même driver (b44).
