Sur une passerelle internet, le routage est devenu impossible, et ce,
depuis un crash disque.
web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et
les news avec pine, c'est pas top).
iptables semble fonctionner, car en local, c'est Ok.
/proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés
bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre
fichier aussi peut être ?
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
On Sat, 18 Sep 2004 10:04:21 +0200, pascal wrote:
Salut,
Sur une passerelle internet, le routage est devenu impossible, et ce, depuis un crash disque. web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et les news avec pine, c'est pas top). iptables semble fonctionner, car en local, c'est Ok. /proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre fichier aussi peut être ?
Merci
Je precise gentoo 2004.0, kernel 2.4.27 .
On Sat, 18 Sep 2004 10:04:21 +0200, pascal wrote:
Salut,
Sur une passerelle internet, le routage est devenu impossible, et ce,
depuis un crash disque.
web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et
les news avec pine, c'est pas top).
iptables semble fonctionner, car en local, c'est Ok.
/proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés
bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre
fichier aussi peut être ?
Sur une passerelle internet, le routage est devenu impossible, et ce, depuis un crash disque. web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et les news avec pine, c'est pas top). iptables semble fonctionner, car en local, c'est Ok. /proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre fichier aussi peut être ?
Merci
Je precise gentoo 2004.0, kernel 2.4.27 .
Gaelle
Peux tu mettre quelques info en plus :
ifconfig (pour que l'on comprenne tes interfaces) route -n (pour voir les routes actuelles) et un IPTable -L pour voir les regles actuelles
a+
"pascal" a écrit dans le message de news:
Salut,
Sur une passerelle internet, le routage est devenu impossible, et ce, depuis un crash disque. web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et les news avec pine, c'est pas top). iptables semble fonctionner, car en local, c'est Ok. /proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre fichier aussi peut être ?
Merci
Peux tu mettre quelques info en plus :
ifconfig (pour que l'on comprenne tes interfaces)
route -n (pour voir les routes actuelles)
et un IPTable -L pour voir les regles actuelles
a+
"pascal" <pascal.conrad@libertysurf.fr> a écrit dans le message de
news:pan.2004.09.18.08.04.20.883471@libertysurf.fr...
Salut,
Sur une passerelle internet, le routage est devenu impossible, et ce,
depuis un crash disque.
web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et
les news avec pine, c'est pas top).
iptables semble fonctionner, car en local, c'est Ok.
/proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés
bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre
fichier aussi peut être ?
ifconfig (pour que l'on comprenne tes interfaces) route -n (pour voir les routes actuelles) et un IPTable -L pour voir les regles actuelles
a+
"pascal" a écrit dans le message de news:
Salut,
Sur une passerelle internet, le routage est devenu impossible, et ce, depuis un crash disque. web et ftp passe par le proxy, mais irc,nntp,netmeeting et autres non (et les news avec pine, c'est pas top). iptables semble fonctionner, car en local, c'est Ok. /proc/sys/net/ipv4/ip_forward est bien à 1, et cela fonctionnait trés bien avant.
Lors du crash disque /var/log/messages avait pris un coup. Un autre fichier aussi peut être ?
Merci
pascal
On Sat, 18 Sep 2004 14:24:49 +0200, Gaelle wrote:
Peux tu mettre quelques info en plus :
ifconfig (pour que l'on comprenne tes interfaces) route -n (pour voir les routes actuelles) et un IPTable -L pour voir les regles actuelles
212.129.9.66 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.60.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.203.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 0.0.0.0 212.129.9.66 0.0.0.0 UG 0 0 0 ppp0
239.0.0.0 correspond au proxy netmeetin (upnp).
Pour le firewall, il y a trop de régle. Mais meme avec un firewall désactivé (juste le masquerade) le phénoméne est identique.
TiChou
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
[...]
Pour le firewall, il y a trop de régle. Mais meme avec un firewall désactivé (juste le masquerade) le phénoméne est identique.
Mais le « phénomène » se présente comment concrètement ? Dire que « c'est impossible ou pas top » ça ne veut pas dire grand chose en informatique. Les problèmes rencontrés sont des erreurs de résolution dans les noms (DNS), des refus de connexion, des tentatives de connexions qui n'aboutissent pas après un long temps d'attente, etc ? Le mieux serait de faire des essais de ping et de traceroute sur les machines clientes.
$ ping ip_passerelle
$ ping www.google.fr
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème et déterminer la cause du problème.
-- TiChou
Dans le message <news:pan.2004.09.18.13.50.33.547273@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
[...]
Pour le firewall, il y a trop de régle. Mais meme avec un firewall
désactivé (juste le masquerade) le phénoméne est identique.
Mais le « phénomène » se présente comment concrètement ? Dire que « c'est
impossible ou pas top » ça ne veut pas dire grand chose en informatique.
Les problèmes rencontrés sont des erreurs de résolution dans les noms (DNS),
des refus de connexion, des tentatives de connexions qui n'aboutissent pas
après un long temps d'attente, etc ?
Le mieux serait de faire des essais de ping et de traceroute sur les
machines clientes.
$ ping ip_passerelle
$ ping www.google.fr
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème
et déterminer la cause du problème.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
[...]
Pour le firewall, il y a trop de régle. Mais meme avec un firewall désactivé (juste le masquerade) le phénoméne est identique.
Mais le « phénomène » se présente comment concrètement ? Dire que « c'est impossible ou pas top » ça ne veut pas dire grand chose en informatique. Les problèmes rencontrés sont des erreurs de résolution dans les noms (DNS), des refus de connexion, des tentatives de connexions qui n'aboutissent pas après un long temps d'attente, etc ? Le mieux serait de faire des essais de ping et de traceroute sur les machines clientes.
$ ping ip_passerelle
$ ping www.google.fr
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème et déterminer la cause du problème.
-- TiChou
pascal
On Sat, 18 Sep 2004 15:57:10 +0200, TiChou wrote:
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
[...]
Pour le firewall, il y a trop de régle. Mais meme avec un firewall désactivé (juste le masquerade) le phénoméne est identique.
Mais le « phénomène » se présente comment concrètement ? Dire que « c'est impossible ou pas top » ça ne veut pas dire grand chose en informatique.
Il est impossible aux machine clientes de faire autre chose que ce que le proxy squid peut faire.
Les problèmes rencontrés sont des erreurs de résolution dans les noms (DNS), des refus de connexion, des tentatives de connexions qui n'aboutissent pas après un long temps d'attente, etc ? Le mieux serait de faire des essais de ping et de traceroute sur les machines clientes.
La passesrelle est aussi le DNS. J'ai des résolution interne sur des applications apache/php/mysql.
$ ping ip_passerelle
Ca OK
$ ping www.google.fr
Aussi
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème et déterminer la cause du problème.
Les clients sont de type NT4/2000. traceroute n'existe pas à ma connaissance. Il faudrait que j'essai sur le serveur de fichier. Concrétement, lors de l'accés au news, Mozilla se connecte au serveur, actualise le nombre d'article, m'indique qu'un nombre d'article est à télécharger, puis la 'time out' lors de la recup des articles. Pour l'IRC, pas d'authentification possible. Pour Netmeeting, 'time out'. Et avec le firewall juste en 'masquerade'. Cette machine à un DNS, apache, postfix/apop3,squid en fonctionnement. Et jusqu'a ce crash, tout marchait bien.
On Sat, 18 Sep 2004 15:57:10 +0200, TiChou wrote:
Dans le message <news:pan.2004.09.18.13.50.33.547273@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
[...]
Pour le firewall, il y a trop de régle. Mais meme avec un firewall
désactivé (juste le masquerade) le phénoméne est identique.
Mais le « phénomène » se présente comment concrètement ? Dire que « c'est
impossible ou pas top » ça ne veut pas dire grand chose en informatique.
Il est impossible aux machine clientes de faire autre chose que ce que le
proxy squid peut faire.
Les problèmes rencontrés sont des erreurs de résolution dans les noms
(DNS), des refus de connexion, des tentatives de connexions qui
n'aboutissent pas après un long temps d'attente, etc ? Le mieux serait
de faire des essais de ping et de traceroute sur les machines clientes.
La passesrelle est aussi le DNS. J'ai des résolution interne sur des
applications apache/php/mysql.
$ ping ip_passerelle
Ca OK
$ ping www.google.fr
Aussi
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le
problème et déterminer la cause du problème.
Les clients sont de type NT4/2000. traceroute n'existe pas à ma
connaissance. Il faudrait que j'essai sur le serveur de fichier.
Concrétement, lors de l'accés au news, Mozilla se connecte
au serveur, actualise le nombre d'article, m'indique qu'un nombre
d'article est à télécharger, puis la 'time out' lors de la recup des
articles. Pour l'IRC, pas d'authentification possible.
Pour Netmeeting, 'time out'.
Et avec le firewall juste en 'masquerade'.
Cette machine à un DNS, apache, postfix/apop3,squid en fonctionnement. Et
jusqu'a ce crash, tout marchait bien.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
[...]
Pour le firewall, il y a trop de régle. Mais meme avec un firewall désactivé (juste le masquerade) le phénoméne est identique.
Mais le « phénomène » se présente comment concrètement ? Dire que « c'est impossible ou pas top » ça ne veut pas dire grand chose en informatique.
Il est impossible aux machine clientes de faire autre chose que ce que le proxy squid peut faire.
Les problèmes rencontrés sont des erreurs de résolution dans les noms (DNS), des refus de connexion, des tentatives de connexions qui n'aboutissent pas après un long temps d'attente, etc ? Le mieux serait de faire des essais de ping et de traceroute sur les machines clientes.
La passesrelle est aussi le DNS. J'ai des résolution interne sur des applications apache/php/mysql.
$ ping ip_passerelle
Ca OK
$ ping www.google.fr
Aussi
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème et déterminer la cause du problème.
Les clients sont de type NT4/2000. traceroute n'existe pas à ma connaissance. Il faudrait que j'essai sur le serveur de fichier. Concrétement, lors de l'accés au news, Mozilla se connecte au serveur, actualise le nombre d'article, m'indique qu'un nombre d'article est à télécharger, puis la 'time out' lors de la recup des articles. Pour l'IRC, pas d'authentification possible. Pour Netmeeting, 'time out'. Et avec le firewall juste en 'masquerade'. Cette machine à un DNS, apache, postfix/apop3,squid en fonctionnement. Et jusqu'a ce crash, tout marchait bien.
FrekoDing
Le 18/09/2004 20:35, pascal écrivait ceci :
Les clients sont de type NT4/2000. traceroute n'existe pas à ma connaissance. Il faudrait que j'essai sur le serveur de fichier.
il existe mais ne porte pas le meme nom... essaie tracert adresse @+
Le 18/09/2004 20:35, pascal écrivait ceci :
Les clients sont de type NT4/2000. traceroute n'existe pas à ma
connaissance. Il faudrait que j'essai sur le serveur de fichier.
il existe mais ne porte pas le meme nom...
essaie tracert adresse
@+
Les clients sont de type NT4/2000. traceroute n'existe pas à ma connaissance. Il faudrait que j'essai sur le serveur de fichier.
il existe mais ne porte pas le meme nom... essaie tracert adresse @+
TiChou
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
$ ping ip_passerelle
Ca OK
$ ping www.google.fr
Aussi
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème et déterminer la cause du problème.
Les clients sont de type NT4/2000. traceroute n'existe pas à ma connaissance.
Cette commande sous l'environnement Windows se nomme 'tracert'.
Il faudrait que j'essai sur le serveur de fichier. Concrétement, lors de l'accés au news, Mozilla se connecte au serveur, actualise le nombre d'article, m'indique qu'un nombre d'article est à télécharger, puis la 'time out' lors de la recup des articles. Pour l'IRC, pas d'authentification possible. Pour Netmeeting, 'time out'. Et avec le firewall juste en 'masquerade'. Cette machine à un DNS, apache, postfix/apop3,squid en fonctionnement. Et jusqu'a ce crash, tout marchait bien.
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
-- TiChou
Dans le message <news:pan.2004.09.18.18.35.21.184692@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
$ ping ip_passerelle
Ca OK
$ ping www.google.fr
Aussi
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le
problème et déterminer la cause du problème.
Les clients sont de type NT4/2000. traceroute n'existe pas à ma
connaissance.
Cette commande sous l'environnement Windows se nomme 'tracert'.
Il faudrait que j'essai sur le serveur de fichier.
Concrétement, lors de l'accés au news, Mozilla se connecte
au serveur, actualise le nombre d'article, m'indique qu'un nombre
d'article est à télécharger, puis la 'time out' lors de la recup des
articles. Pour l'IRC, pas d'authentification possible.
Pour Netmeeting, 'time out'.
Et avec le firewall juste en 'masquerade'.
Cette machine à un DNS, apache, postfix/apop3,squid en fonctionnement. Et
jusqu'a ce crash, tout marchait bien.
J'aurai tendance à penser que le problème vient des machines clientes,
problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface
réseau Internet (ppp0) avait un MTU de 1492.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
$ ping ip_passerelle
Ca OK
$ ping www.google.fr
Aussi
$ ping 216.239.59.147
$ traceroute 216.239.59.147
$ telnet 216.239.59.147 80
etc, bref tous les tests qui pourront concrètement diagnostiquer le problème et déterminer la cause du problème.
Les clients sont de type NT4/2000. traceroute n'existe pas à ma connaissance.
Cette commande sous l'environnement Windows se nomme 'tracert'.
Il faudrait que j'essai sur le serveur de fichier. Concrétement, lors de l'accés au news, Mozilla se connecte au serveur, actualise le nombre d'article, m'indique qu'un nombre d'article est à télécharger, puis la 'time out' lors de la recup des articles. Pour l'IRC, pas d'authentification possible. Pour Netmeeting, 'time out'. Et avec le firewall juste en 'masquerade'. Cette machine à un DNS, apache, postfix/apop3,squid en fonctionnement. Et jusqu'a ce crash, tout marchait bien.
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
-- TiChou
pascal
On Sat, 18 Sep 2004 21:39:36 +0200, TiChou wrote:
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça a donné un refus de connection de pppd, et même un plantage de pppd.
On Sat, 18 Sep 2004 21:39:36 +0200, TiChou wrote:
Dans le message <news:pan.2004.09.18.18.35.21.184692@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes,
problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface
réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça
a donné un refus de connection de pppd, et même un plantage de pppd.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça a donné un refus de connection de pppd, et même un plantage de pppd.
TiChou
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça a donné un refus de connection de pppd, et même un plantage de pppd.
Dans votre message <news: datant d'hier vous nous donniez le détail de vos interfaces réseau dont l'interface ppp0 piloté par votre pppd :
ppp0 Link encap:Point-to-Point Protocol inet addr:83.156.108.65 P-t-P:212.129.9.66 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:13983 errors:0 ^^^^^^^^
et on voit bien que celle-ci a un MTU de 1492, valeur définie dans votre configuration pppd. Je ferai de plus la remarque suivante, car à la vue de votre interface eth1 :
eth1 Link encap:Ethernet HWaddr 00:60:4C:17:A8:6E inet addr:192.168.60.30 Bcast:192.168.60.255
j'imagine alors que vous avez un modem USB Sagem qui se connecte très certainement en utilisant le protocole PPPoA et donc le MTU de votre interface ppp devrait plutôt être d'au moins 1500.
-- TiChou
Dans le message <news:pan.2004.09.19.19.25.02.86257@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes,
problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface
réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça
a donné un refus de connection de pppd, et même un plantage de pppd.
Dans votre message <news:pan.2004.09.18.13.50.33.547273@libertysurf.fr>
datant d'hier vous nous donniez le détail de vos interfaces réseau dont
l'interface ppp0 piloté par votre pppd :
ppp0 Link encap:Point-to-Point Protocol
inet addr:83.156.108.65 P-t-P:212.129.9.66
Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP
MULTICAST MTU:1492 Metric:1 RX packets:13983 errors:0
^^^^^^^^
et on voit bien que celle-ci a un MTU de 1492, valeur définie dans votre
configuration pppd.
Je ferai de plus la remarque suivante, car à la vue de votre interface eth1
:
eth1 Link encap:Ethernet HWaddr 00:60:4C:17:A8:6E
inet addr:192.168.60.30 Bcast:192.168.60.255
j'imagine alors que vous avez un modem USB Sagem qui se connecte très
certainement en utilisant le protocole PPPoA et donc le MTU de votre
interface ppp devrait plutôt être d'au moins 1500.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça a donné un refus de connection de pppd, et même un plantage de pppd.
Dans votre message <news: datant d'hier vous nous donniez le détail de vos interfaces réseau dont l'interface ppp0 piloté par votre pppd :
ppp0 Link encap:Point-to-Point Protocol inet addr:83.156.108.65 P-t-P:212.129.9.66 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:13983 errors:0 ^^^^^^^^
et on voit bien que celle-ci a un MTU de 1492, valeur définie dans votre configuration pppd. Je ferai de plus la remarque suivante, car à la vue de votre interface eth1 :
eth1 Link encap:Ethernet HWaddr 00:60:4C:17:A8:6E inet addr:192.168.60.30 Bcast:192.168.60.255
j'imagine alors que vous avez un modem USB Sagem qui se connecte très certainement en utilisant le protocole PPPoA et donc le MTU de votre interface ppp devrait plutôt être d'au moins 1500.
-- TiChou
Pascal
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça a donné un refus de connection de pppd, et même un plantage de pppd.
Dans votre message <news: datant d'hier vous nous donniez le détail de vos interfaces réseau dont l'interface ppp0 piloté par votre pppd :
ppp0 Link encap:Point-to-Point Protocol inet addr:83.156.108.65 P-t-P:212.129.9.66 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:13983 errors:0 ^^^^^^^^
et on voit bien que celle-ci a un MTU de 1492, valeur définie dans votre configuration pppd. Je ferai de plus la remarque suivante, car à la vue de votre interface eth1 :
eth1 Link encap:Ethernet HWaddr 00:60:4C:17:A8:6E inet addr:192.168.60.30 Bcast:192.168.60.255
j'imagine alors que vous avez un modem USB Sagem qui se connecte très certainement en utilisant le protocole PPPoA et donc le MTU de votre interface ppp devrait plutôt être d'au moins 1500.
Probléme régler. j'ai fait une mise à jour du pilote du modem (1.0.4 vers 1.9.9). Tous les routages nntp,irc refonctionne.
Merci.
Dans le message <news:pan.2004.09.19.19.25.02.86257@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes,
problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface
réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça
a donné un refus de connection de pppd, et même un plantage de pppd.
Dans votre message <news:pan.2004.09.18.13.50.33.547273@libertysurf.fr>
datant d'hier vous nous donniez le détail de vos interfaces réseau dont
l'interface ppp0 piloté par votre pppd :
ppp0 Link encap:Point-to-Point Protocol
inet addr:83.156.108.65 P-t-P:212.129.9.66
Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP
MULTICAST MTU:1492 Metric:1 RX packets:13983 errors:0
^^^^^^^^
et on voit bien que celle-ci a un MTU de 1492, valeur définie dans votre
configuration pppd.
Je ferai de plus la remarque suivante, car à la vue de votre interface eth1
:
eth1 Link encap:Ethernet HWaddr 00:60:4C:17:A8:6E
inet addr:192.168.60.30 Bcast:192.168.60.255
j'imagine alors que vous avez un modem USB Sagem qui se connecte très
certainement en utilisant le protocole PPPoA et donc le MTU de votre
interface ppp devrait plutôt être d'au moins 1500.
Probléme régler. j'ai fait une mise à jour du pilote du modem (1.0.4 vers
1.9.9). Tous les routages nntp,irc refonctionne.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
J'aurai tendance à penser que le problème vient des machines clientes, problème de MTU/MSS. D'ailleurs, j'ai pu remarquer que votre interface réseau Internet (ppp0) avait un MTU de 1492.
Ce ne serait pas plutôt 1460. J'ai testé 1492 sur ma config perso, et ça a donné un refus de connection de pppd, et même un plantage de pppd.
Dans votre message <news: datant d'hier vous nous donniez le détail de vos interfaces réseau dont l'interface ppp0 piloté par votre pppd :
ppp0 Link encap:Point-to-Point Protocol inet addr:83.156.108.65 P-t-P:212.129.9.66 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:13983 errors:0 ^^^^^^^^
et on voit bien que celle-ci a un MTU de 1492, valeur définie dans votre configuration pppd. Je ferai de plus la remarque suivante, car à la vue de votre interface eth1 :
eth1 Link encap:Ethernet HWaddr 00:60:4C:17:A8:6E inet addr:192.168.60.30 Bcast:192.168.60.255
j'imagine alors que vous avez un modem USB Sagem qui se connecte très certainement en utilisant le protocole PPPoA et donc le MTU de votre interface ppp devrait plutôt être d'au moins 1500.
Probléme régler. j'ai fait une mise à jour du pilote du modem (1.0.4 vers 1.9.9). Tous les routages nntp,irc refonctionne.
