je suyis devant le problème suivant. Un routeur qui était sous RH -512
RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection
Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les
autre interfaces en 1500.
Les machines du réseau Intranet qui veulent se connecter à Internet
voient la première page s'afficher -lentement- puis plus rien. Un
serveur derrère le firewall ne peut copier de gros fichiers, à un momemt
X de l copie scp affiche "stalled". Un petit fichier se copie sans
problème. La même copie à partir du firewall ne poses pas de problème,
de même que la copie en interne.
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le
sujet. S'il y a d'autres pistes, je suis preneur.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai
affiché par tshark le trafic, il y a eu deux paquets d'échangé, le
second étant la réponse du distant "lost".
Merci pour vos idées
--
Daniel
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C6D0DFB.5050407@tootai.net
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
daniel huhardeaux a écrit :
je suyis devant le problème suivant. Un routeur qui était sous RH -512 RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les autre interfaces en 1500.
PPPoE, je suppose ?
Les machines du réseau Intranet qui veulent se connecter à Internet voient la première page s'afficher -lentement- puis plus rien. Un serveur derrère le firewall ne peut copier de gros fichiers, à un momemt X de l copie scp affiche "stalled". Un petit fichier se copie sans problème. La même copie à partir du firewall ne poses pas de problème, de même que la copie en interne.
Copie en émission ou réception ? C'est à partir de quelle taille "petit" et "gros" ?
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492. Sinon, parmi les autres suspects habituels on peut citer les options d'optimisation TCP comme ECN, timestamps, selective ACK (sack), window scaling... mal gérées par certains équipements non conformes, à tester en les désactivant via leurs sysctls respectifs net.ipv4.tcp_* toujours sur une machine cliente.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai affiché par tshark le trafic, il y a eu deux paquets d'échangé, le second étant la réponse du distant "lost".
"la réponse du distant "lost"" ?? On peut avoir la trace ?
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Salut,
daniel huhardeaux a écrit :
je suyis devant le problème suivant. Un routeur qui était sous RH -512
RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection
Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les
autre interfaces en 1500.
PPPoE, je suppose ?
Les machines du réseau Intranet qui veulent se connecter à Internet
voient la première page s'afficher -lentement- puis plus rien. Un
serveur derrère le firewall ne peut copier de gros fichiers, à un momemt
X de l copie scp affiche "stalled". Un petit fichier se copie sans
problème. La même copie à partir du firewall ne poses pas de problème,
de même que la copie en interne.
Copie en émission ou réception ?
C'est à partir de quelle taille "petit" et "gros" ?
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le
sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Sinon, parmi les autres suspects habituels on peut citer les options
d'optimisation TCP comme ECN, timestamps, selective ACK (sack), window
scaling... mal gérées par certains équipements non conformes, à tester
en les désactivant via leurs sysctls respectifs net.ipv4.tcp_* toujours
sur une machine cliente.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai
affiché par tshark le trafic, il y a eu deux paquets d'échangé, le
second étant la réponse du distant "lost".
"la réponse du distant "lost"" ??
On peut avoir la trace ?
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C6D117B.8090405@plouf.fr.eu.org
je suyis devant le problème suivant. Un routeur qui était sous RH -512 RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les autre interfaces en 1500.
PPPoE, je suppose ?
Les machines du réseau Intranet qui veulent se connecter à Internet voient la première page s'afficher -lentement- puis plus rien. Un serveur derrère le firewall ne peut copier de gros fichiers, à un momemt X de l copie scp affiche "stalled". Un petit fichier se copie sans problème. La même copie à partir du firewall ne poses pas de problème, de même que la copie en interne.
Copie en émission ou réception ? C'est à partir de quelle taille "petit" et "gros" ?
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492. Sinon, parmi les autres suspects habituels on peut citer les options d'optimisation TCP comme ECN, timestamps, selective ACK (sack), window scaling... mal gérées par certains équipements non conformes, à tester en les désactivant via leurs sysctls respectifs net.ipv4.tcp_* toujours sur une machine cliente.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai affiché par tshark le trafic, il y a eu deux paquets d'échangé, le second étant la réponse du distant "lost".
"la réponse du distant "lost"" ?? On peut avoir la trace ?
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
daniel huhardeaux
Le 19/08/2010 13:11, Pascal Hambourg a écrit :
Salut,
daniel huhardeaux a écrit :
je suyis devant le problème suivant. Un routeur qui était sous RH -512 RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les autre interfaces en 1500.
PPPoE, je suppose ?
Pardon, oui.
Les machines du réseau Intranet qui veulent se connecter à Internet voient la première page s'afficher -lentement- puis plus rien. Un serveur derrère le firewall ne peut copier de gros fichiers, à un momemt X de l copie scp affiche "stalled". Un petit fichier se copie sans problème. La même copie à partir du firewall ne poses pas de problème, de même que la copie en interne.
Copie en émission ou réception ?
Réception, pas testé en émission.
C'est à partir de quelle taille "petit" et "gros" ?
1399 octets passent, 1649 non
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Pas de changement
Sinon, parmi les autres suspects habituels on peut citer les options d'optimisation TCP comme ECN, timestamps, selective ACK (sack), window scaling... mal gérées par certains équipements non conformes, à tester en les désactivant via leurs sysctls respectifs net.ipv4.tcp_* toujours sur une machine cliente.
Ce qui est étonnant c'est que le problème surgit au moment de l'évolution vers Squeeze. Auparavant les machines étaient déjà en place et pas de problème. Il n'ya aeu qu'un changement logiciel, pas matériel.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai affiché par tshark le trafic, il y a eu deux paquets d'échangé, le second étant la réponse du distant "lost".
"la réponse du distant "lost"" ?? On peut avoir la trace ?
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 19/08/2010 13:11, Pascal Hambourg a écrit :
Salut,
daniel huhardeaux a écrit :
je suyis devant le problème suivant. Un routeur qui était sous RH -512
RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection
Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les
autre interfaces en 1500.
PPPoE, je suppose ?
Pardon, oui.
Les machines du réseau Intranet qui veulent se connecter à Internet
voient la première page s'afficher -lentement- puis plus rien. Un
serveur derrère le firewall ne peut copier de gros fichiers, à un momemt
X de l copie scp affiche "stalled". Un petit fichier se copie sans
problème. La même copie à partir du firewall ne poses pas de problème,
de même que la copie en interne.
Copie en émission ou réception ?
Réception, pas testé en émission.
C'est à partir de quelle taille "petit" et "gros" ?
1399 octets passent, 1649 non
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le
sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Pas de changement
Sinon, parmi les autres suspects habituels on peut citer les options
d'optimisation TCP comme ECN, timestamps, selective ACK (sack), window
scaling... mal gérées par certains équipements non conformes, à tester
en les désactivant via leurs sysctls respectifs net.ipv4.tcp_* toujours
sur une machine cliente.
Ce qui est étonnant c'est que le problème surgit au moment de
l'évolution vers Squeeze. Auparavant les machines étaient déjà en place
et pas de problème. Il n'ya aeu qu'un changement logiciel, pas matériel.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai
affiché par tshark le trafic, il y a eu deux paquets d'échangé, le
second étant la réponse du distant "lost".
"la réponse du distant "lost"" ??
On peut avoir la trace ?
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C6D490B.9020106@tootai.net
je suyis devant le problème suivant. Un routeur qui était sous RH -512 RAM- a été upgradé en Debian Squeeze Kernel 2.6.32. La connection Internet se fait via ppp (FT), le lien ppp ayant une MTU de 1492, les autre interfaces en 1500.
PPPoE, je suppose ?
Pardon, oui.
Les machines du réseau Intranet qui veulent se connecter à Internet voient la première page s'afficher -lentement- puis plus rien. Un serveur derrère le firewall ne peut copier de gros fichiers, à un momemt X de l copie scp affiche "stalled". Un petit fichier se copie sans problème. La même copie à partir du firewall ne poses pas de problème, de même que la copie en interne.
Copie en émission ou réception ?
Réception, pas testé en émission.
C'est à partir de quelle taille "petit" et "gros" ?
1399 octets passent, 1649 non
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Pas de changement
Sinon, parmi les autres suspects habituels on peut citer les options d'optimisation TCP comme ECN, timestamps, selective ACK (sack), window scaling... mal gérées par certains équipements non conformes, à tester en les désactivant via leurs sysctls respectifs net.ipv4.tcp_* toujours sur une machine cliente.
Ce qui est étonnant c'est que le problème surgit au moment de l'évolution vers Squeeze. Auparavant les machines étaient déjà en place et pas de problème. Il n'ya aeu qu'un changement logiciel, pas matériel.
Note: durant la copie du fichier scp sur la machine derrière le FW, j'ai affiché par tshark le trafic, il y a eu deux paquets d'échangé, le second étant la réponse du distant "lost".
"la réponse du distant "lost"" ?? On peut avoir la trace ?
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Daniel Huhardeaux
Le 19/08/2010 17:08, daniel huhardeaux a écrit :
[...] Copie en émission ou réception ? Réception, pas testé en émission.
C'est à partir de quelle taille "petit" et "gros" ?
1399 octets passent, 1649 non
Test final: taille maxi d'un fichier qui passe: 1406 octets
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Et si je mets la MTU de ppp0 à 1406?
-- Daniel
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 19/08/2010 17:08, daniel huhardeaux a écrit :
[...]
Copie en émission ou réception ?
Réception, pas testé en émission.
C'est à partir de quelle taille "petit" et "gros" ?
1399 octets passent, 1649 non
Test final: taille maxi d'un fichier qui passe: 1406 octets
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le
sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Et si je mets la MTU de ppp0 à 1406?
--
Daniel
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C6D6228.7000307@tootai.net
[...] Copie en émission ou réception ? Réception, pas testé en émission.
C'est à partir de quelle taille "petit" et "gros" ?
1399 octets passent, 1649 non
Test final: taille maxi d'un fichier qui passe: 1406 octets
Je pense à un problème de MTU, j'aimerai connaitre votre avis sur le sujet. S'il y a d'autres pistes, je suis preneur.
Possible. Tester en baissant le MTU d'une machine cliente à 1492.
Et si je mets la MTU de ppp0 à 1406?
-- Daniel
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
daniel huhardeaux
Le 19/08/2010 18:56, Daniel Huhardeaux a écrit :
[...]
Et si je mets la MTU de ppp0 à 1406?
Ca fonctionne! Je ne vois que le fait qu'il y ai eu des modifs chez FT sans prévenir les clients. J'imagine mal quelle màj logiciel _sans changement_ de matériel ferait qu'il faille modifier ce paramètre.
Merci pour votre aide.
-- Daniel
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 19/08/2010 18:56, Daniel Huhardeaux a écrit :
[...]
Et si je mets la MTU de ppp0 à 1406?
Ca fonctionne! Je ne vois que le fait qu'il y ai eu des modifs chez FT
sans prévenir les clients. J'imagine mal quelle màj logiciel _sans
changement_ de matériel ferait qu'il faille modifier ce paramètre.
Merci pour votre aide.
--
Daniel
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C6D6632.9090302@tootai.net
Ca fonctionne! Je ne vois que le fait qu'il y ai eu des modifs chez FT sans prévenir les clients. J'imagine mal quelle màj logiciel _sans changement_ de matériel ferait qu'il faille modifier ce paramètre.
Merci pour votre aide.
-- Daniel
-- 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 En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
