A peine deux jours après avoir mis en service mon nouveau routeur ADSL,
je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en
mode 'persist' après une déconnexion (celle des 24h de FT) :
pppd[398]: LCP terminated by peer
pppoe[400]: Session terminated -- received PADT from peer
pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25)
pppd[398]: tcflush failed: Input/output error
pppd[398]: Exit.
J'ai retrouvé le fil de discussion de février 2004 dans lequel Tichou
disait que le bug était bien connu mais sans solution probante. Après
quelques recherches, je n'ai rien trouvé d'autre que des scripts plus ou
moins crades qui surveillent et redémarrent pppd. Y aurait-t-il eu du
nouveau depuis ?
Ce qui est curieux, c'est que j'ai essayé de reproduire le bug avec une
connexion à un serveur pppoe-server sur une autre machine du LAN, mais
quelle que soit la façon dont j'ai arrêté la connexion (kill pppd ou
pppoe, poff, câble débranché), il ne s'est jamais produit.
La configuration : Pentium MMX, Debian 3.0 Woody avec les paquets
stables pppd 2.4.1 et pppoe 3.3, noyau 2.4.18 compilé à partir des
sources Debian. Si ça peut servir, je peux aussi donner les options de
pppd et pppoe mais je n'ai rien vu dans ce que j'ai lu qui relie ce bug
à l'une ou l'autre de ces options.
PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d
marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à
ce sujet.
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
Olivier COLIN
Annie D. wrote:
: A peine deux jours après avoir mis en service mon nouveau routeur ADSL, : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en : mode 'persist' après une déconnexion (celle des 24h de FT) : : : pppd[398]: LCP terminated by peer : pppoe[400]: Session terminated -- received PADT from peer : pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25) : pppd[398]: tcflush failed: Input/output error : pppd[398]: Exit.
C' est un modem-routeur dont il s' agit ? Si oui pourquoi ne pas le laisser se connecter lui-même ? Donc renseigner les champs concernant ton compte adsl (username / password) dans la page "WAN" de ton routeur. Cocher "Automatic Reconnect" si option il y a.. Donc plus besoin de pppd et pppoe :)
-- Slackware RuleZ ;)
Annie D. <annie.demur@free.fr> wrote:
: A peine deux jours après avoir mis en service mon nouveau routeur ADSL,
: je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en
: mode 'persist' après une déconnexion (celle des 24h de FT) :
:
: pppd[398]: LCP terminated by peer
: pppoe[400]: Session terminated -- received PADT from peer
: pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25)
: pppd[398]: tcflush failed: Input/output error
: pppd[398]: Exit.
C' est un modem-routeur dont il s' agit ? Si oui pourquoi ne pas le
laisser se connecter lui-même ? Donc renseigner les champs concernant
ton compte adsl (username / password) dans la page "WAN" de ton
routeur. Cocher "Automatic Reconnect" si option il y a.. Donc plus
besoin de pppd et pppoe :)
: A peine deux jours après avoir mis en service mon nouveau routeur ADSL, : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en : mode 'persist' après une déconnexion (celle des 24h de FT) : : : pppd[398]: LCP terminated by peer : pppoe[400]: Session terminated -- received PADT from peer : pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25) : pppd[398]: tcflush failed: Input/output error : pppd[398]: Exit.
C' est un modem-routeur dont il s' agit ? Si oui pourquoi ne pas le laisser se connecter lui-même ? Donc renseigner les champs concernant ton compte adsl (username / password) dans la page "WAN" de ton routeur. Cocher "Automatic Reconnect" si option il y a.. Donc plus besoin de pppd et pppoe :)
-- Slackware RuleZ ;)
Annie D.
Olivier COLIN wrote:
Annie D. wrote:
: A peine deux jours après avoir mis en service mon nouveau routeur ADSL, : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en : mode 'persist' après une déconnexion (celle des 24h de FT) :
C' est un modem-routeur dont il s' agit ?
Non, c'est un simple modem Alcatel STH en mode pont.
Si oui pourquoi ne pas le laisser se connecter lui-même ?
Même en le trafiquant pour le transformer en routeur, ce que je ne tiens pas à faire, je ne pense pas qu'il supporte l'IPv6 ou qu'il permette une souplesse aussi grande qu'un routeur Linux.
Olivier COLIN wrote:
Annie D. <annie.demur@free.fr> wrote:
: A peine deux jours après avoir mis en service mon nouveau routeur ADSL,
: je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en
: mode 'persist' après une déconnexion (celle des 24h de FT) :
C' est un modem-routeur dont il s' agit ?
Non, c'est un simple modem Alcatel STH en mode pont.
Si oui pourquoi ne pas le laisser se connecter lui-même ?
Même en le trafiquant pour le transformer en routeur, ce que je ne tiens
pas à faire, je ne pense pas qu'il supporte l'IPv6 ou qu'il permette une
souplesse aussi grande qu'un routeur Linux.
: A peine deux jours après avoir mis en service mon nouveau routeur ADSL, : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en : mode 'persist' après une déconnexion (celle des 24h de FT) :
C' est un modem-routeur dont il s' agit ?
Non, c'est un simple modem Alcatel STH en mode pont.
Si oui pourquoi ne pas le laisser se connecter lui-même ?
Même en le trafiquant pour le transformer en routeur, ce que je ne tiens pas à faire, je ne pense pas qu'il supporte l'IPv6 ou qu'il permette une souplesse aussi grande qu'un routeur Linux.
Olivier COLIN
Annie D. wrote:
:> : A peine deux jours après avoir mis en service mon nouveau routeur ADSL, :> : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en :> : mode 'persist' après une déconnexion (celle des 24h de FT) : :> :> C' est un modem-routeur dont il s' agit ? : : Non, c'est un simple modem Alcatel STH en mode pont.
J' en ai eu un en location pour débuter en adsl et je ne me rapèle pas avoir eu des pbs de déco avec rp-pppoe.
-- Slackware RuleZ ;)
Annie D. <annie.demur@free.fr> wrote:
:> : A peine deux jours après avoir mis en service mon nouveau routeur ADSL,
:> : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en
:> : mode 'persist' après une déconnexion (celle des 24h de FT) :
:>
:> C' est un modem-routeur dont il s' agit ?
:
: Non, c'est un simple modem Alcatel STH en mode pont.
J' en ai eu un en location pour débuter en adsl et je ne me rapèle
pas avoir eu des pbs de déco avec rp-pppoe.
:> : A peine deux jours après avoir mis en service mon nouveau routeur ADSL, :> : je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en :> : mode 'persist' après une déconnexion (celle des 24h de FT) : :> :> C' est un modem-routeur dont il s' agit ? : : Non, c'est un simple modem Alcatel STH en mode pont.
J' en ai eu un en location pour débuter en adsl et je ne me rapèle pas avoir eu des pbs de déco avec rp-pppoe.
-- Slackware RuleZ ;)
Annie D.
Olivier COLIN wrote:
: Non, c'est un simple modem Alcatel STH en mode pont.
J' en ai eu un en location pour débuter en adsl et je ne me rapèle pas avoir eu des pbs de déco avec rp-pppoe.
Que ce soit clair : je suis persuadée qu'une majorité d'utilisateurs ayant une configuration similaire à la mienne n'ont jamais rencontré ce bug, mais voilà : il existe, on en trouve de nombreux témoignages, et il n'est pas spécifique à Debian. Il n'est pas systématique, pour le moment il s'est produit un fois sur 4 déconnexions des 24 heures. C'est une fois de trop. Avant j'ai utilisé pendant presque deux ans une mini-distribution sur disquette pour routeur (Coyote Linux) avec le couple pppd+rp-pppoe et à ma connaissance ce bug ne s'est jamais produit. C'était très bien pour débuter, mais avec son noyau 2.2 (donc pas de support Netfilter/iptables) et son absence de support des disques durs et d'IPv6, il était devenu un peu limité et j'ai voulu passer à quelque chose de plus moderne et extensible.
Tout ce que je demande, c'est si la cause de ce bug a été identifiée et s'il a été corrigé ou au moins si une façon fiable d'empêcher qu'il se produise a été trouvée. Je n'ai rien trouvé, mais j'ai très bien pu passer à côté, n'étant pas une assidue des forums et sites dédiés à Linux.
Olivier COLIN wrote:
: Non, c'est un simple modem Alcatel STH en mode pont.
J' en ai eu un en location pour débuter en adsl et je ne me rapèle
pas avoir eu des pbs de déco avec rp-pppoe.
Que ce soit clair : je suis persuadée qu'une majorité d'utilisateurs
ayant une configuration similaire à la mienne n'ont jamais rencontré ce
bug, mais voilà : il existe, on en trouve de nombreux témoignages, et il
n'est pas spécifique à Debian. Il n'est pas systématique, pour le moment
il s'est produit un fois sur 4 déconnexions des 24 heures. C'est une
fois de trop. Avant j'ai utilisé pendant presque deux ans une
mini-distribution sur disquette pour routeur (Coyote Linux) avec le
couple pppd+rp-pppoe et à ma connaissance ce bug ne s'est jamais
produit. C'était très bien pour débuter, mais avec son noyau 2.2 (donc
pas de support Netfilter/iptables) et son absence de support des disques
durs et d'IPv6, il était devenu un peu limité et j'ai voulu passer à
quelque chose de plus moderne et extensible.
Tout ce que je demande, c'est si la cause de ce bug a été identifiée et
s'il a été corrigé ou au moins si une façon fiable d'empêcher qu'il se
produise a été trouvée. Je n'ai rien trouvé, mais j'ai très bien pu
passer à côté, n'étant pas une assidue des forums et sites dédiés à
Linux.
: Non, c'est un simple modem Alcatel STH en mode pont.
J' en ai eu un en location pour débuter en adsl et je ne me rapèle pas avoir eu des pbs de déco avec rp-pppoe.
Que ce soit clair : je suis persuadée qu'une majorité d'utilisateurs ayant une configuration similaire à la mienne n'ont jamais rencontré ce bug, mais voilà : il existe, on en trouve de nombreux témoignages, et il n'est pas spécifique à Debian. Il n'est pas systématique, pour le moment il s'est produit un fois sur 4 déconnexions des 24 heures. C'est une fois de trop. Avant j'ai utilisé pendant presque deux ans une mini-distribution sur disquette pour routeur (Coyote Linux) avec le couple pppd+rp-pppoe et à ma connaissance ce bug ne s'est jamais produit. C'était très bien pour débuter, mais avec son noyau 2.2 (donc pas de support Netfilter/iptables) et son absence de support des disques durs et d'IPv6, il était devenu un peu limité et j'ai voulu passer à quelque chose de plus moderne et extensible.
Tout ce que je demande, c'est si la cause de ce bug a été identifiée et s'il a été corrigé ou au moins si une façon fiable d'empêcher qu'il se produise a été trouvée. Je n'ai rien trouvé, mais j'ai très bien pu passer à côté, n'étant pas une assidue des forums et sites dédiés à Linux.
TiChou
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
A peine deux jours après avoir mis en service mon nouveau routeur ADSL, je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en mode 'persist' après une déconnexion (celle des 24h de FT) :
pppd[398]: LCP terminated by peer pppoe[400]: Session terminated -- received PADT from peer pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25) pppd[398]: tcflush failed: Input/output error pppd[398]: Exit.
J'ai retrouvé le fil de discussion de février 2004 dans lequel Tichou disait que le bug était bien connu mais sans solution probante.
Je rencontre toujours le même problème, de façon irrégulière comme le montre les logs à l'URL suivante :
http://magnolia.tichou.org/~tichou/pppd_log
et qui se traduit à chaque fois par un arrêt du daemon pppd. Cette erreur c'est toujours produit après la réception et l'envoi d'un paquet PADT et jamais dans un autre cas.
Après quelques recherches, je n'ai rien trouvé d'autre que des scripts plus ou moins crades qui surveillent et redémarrent pppd.
Voici les deux scripts maisons que j'utilise sur une Gentoo, celui qui lance les services adsl au démarrage de la machine :
$ cat /etc/init.d/adsl.easynet #!/sbin/runscript
LINK=${myservice#adsl.}
depend() { need net }
checkconfig() { if [ ! -f /etc/ppp/peers/${LINK} ] then eerror "No /etc/ppp/peers/${LINK} file exists!" return 1 fi }
et celui qui gère le lancement du daemon pppd et de son relancement en cas d'arrêt de celui-ci :
$ cat /root/bin/adsl #!/bin/sh
while [ true ] do /usr/bin/setsid /usr/sbin/pppd call $1 & wait sleep 5 done
Y aurait-t-il eu du nouveau depuis ?
A l'époque non, car aucune nouvelle version de pppd corrigeant ce problème n'était disponible et aucun patch correctif. Votre post m'a fait replonger sur ce problème et j'ai pu m'apercevoir que depuis février était disponible une nouvelle version de pppd, la 2.4.2. Le ChangeLog ne fait état que de très peu de changements ou de corrections, on a le droit à un :
* Fixed several bugs
C'est maigre...
Mais en analysant les nouvelles sources, je remarque que la partie du code responsable de cette erreur a été réécrite et semble prendre en compte de nouvelles choses.
J'en ai donc profité pour installer cette nouvelle version de pppd et j'attends de voir si le problème se manifeste toujours ou pas. Pour l'instant la dernière déconnexion s'est produite sans erreur. Je vous tiens au courant pour les prochaines déconnexions.
Ce qui est curieux, c'est que j'ai essayé de reproduire le bug avec une connexion à un serveur pppoe-server sur une autre machine du LAN, mais quelle que soit la façon dont j'ai arrêté la connexion (kill pppd ou pppoe, poff, câble débranché), il ne s'est jamais produit.
Comme je l'ai déjà dis, le problème s'est toujours manifesté uniquement sur une connexion PPPoE et après le dialogue PADT/PADT qui signifie la fin d'une session PPPoE.
La configuration : Pentium MMX, Debian 3.0 Woody avec les paquets stables pppd 2.4.1 et pppoe 3.3, noyau 2.4.18 compilé à partir des sources Debian.
Il serait intéressant de voir si le problème se manifeste en utilisant pppd avec le plugin rp-pppoe.so ou bien avec le module kernel pppoe.
Si ça peut servir, je peux aussi donner les options de pppd et pppoe mais je n'ai rien vu dans ce que j'ai lu qui relie ce bug à l'une ou l'autre de ces options.
Voici les options en rapport avec les déconnexion et reconnexions que j'utilise :
Par contre il existe des options asyncmap qui je ne sais pas si elles sont en rapport ou non avec notre problème et je ne sais pas exactement comment paramétrer ces options.
PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à ce sujet.
A l'occasion, publiez les, ça peut être intéressant. :)
-- TiChou
Dans le message <news:40CB63DD.52622A18@free.fr>,
*Annie D.* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
A peine deux jours après avoir mis en service mon nouveau routeur ADSL,
je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en
mode 'persist' après une déconnexion (celle des 24h de FT) :
pppd[398]: LCP terminated by peer
pppoe[400]: Session terminated -- received PADT from peer
pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25)
pppd[398]: tcflush failed: Input/output error
pppd[398]: Exit.
J'ai retrouvé le fil de discussion de février 2004 dans lequel Tichou
disait que le bug était bien connu mais sans solution probante.
Je rencontre toujours le même problème, de façon irrégulière comme le montre
les logs à l'URL suivante :
http://magnolia.tichou.org/~tichou/pppd_log
et qui se traduit à chaque fois par un arrêt du daemon pppd.
Cette erreur c'est toujours produit après la réception et l'envoi d'un
paquet PADT et jamais dans un autre cas.
Après quelques recherches, je n'ai rien trouvé d'autre que des scripts
plus ou moins crades qui surveillent et redémarrent pppd.
Voici les deux scripts maisons que j'utilise sur une Gentoo, celui qui lance
les services adsl au démarrage de la machine :
$ cat /etc/init.d/adsl.easynet
#!/sbin/runscript
LINK=${myservice#adsl.}
depend() {
need net
}
checkconfig() {
if [ ! -f /etc/ppp/peers/${LINK} ]
then
eerror "No /etc/ppp/peers/${LINK} file exists!"
return 1
fi
}
et celui qui gère le lancement du daemon pppd et de son relancement en cas
d'arrêt de celui-ci :
$ cat /root/bin/adsl
#!/bin/sh
while [ true ]
do
/usr/bin/setsid /usr/sbin/pppd call $1 &
wait
sleep 5
done
Y aurait-t-il eu du nouveau depuis ?
A l'époque non, car aucune nouvelle version de pppd corrigeant ce problème
n'était disponible et aucun patch correctif.
Votre post m'a fait replonger sur ce problème et j'ai pu m'apercevoir que
depuis février était disponible une nouvelle version de pppd, la 2.4.2.
Le ChangeLog ne fait état que de très peu de changements ou de corrections,
on a le droit à un :
* Fixed several bugs
C'est maigre...
Mais en analysant les nouvelles sources, je remarque que la partie du code
responsable de cette erreur a été réécrite et semble prendre en compte de
nouvelles choses.
J'en ai donc profité pour installer cette nouvelle version de pppd et
j'attends de voir si le problème se manifeste toujours ou pas. Pour
l'instant la dernière déconnexion s'est produite sans erreur. Je vous tiens
au courant pour les prochaines déconnexions.
Ce qui est curieux, c'est que j'ai essayé de reproduire le bug avec une
connexion à un serveur pppoe-server sur une autre machine du LAN, mais
quelle que soit la façon dont j'ai arrêté la connexion (kill pppd ou
pppoe, poff, câble débranché), il ne s'est jamais produit.
Comme je l'ai déjà dis, le problème s'est toujours manifesté uniquement sur
une connexion PPPoE et après le dialogue PADT/PADT qui signifie la fin d'une
session PPPoE.
La configuration : Pentium MMX, Debian 3.0 Woody avec les paquets
stables pppd 2.4.1 et pppoe 3.3, noyau 2.4.18 compilé à partir des
sources Debian.
Il serait intéressant de voir si le problème se manifeste en utilisant pppd
avec le plugin rp-pppoe.so ou bien avec le module kernel pppoe.
Si ça peut servir, je peux aussi donner les options de pppd et pppoe mais
je n'ai rien vu dans ce que j'ai lu qui relie ce bug à l'une ou l'autre de
ces options.
Voici les options en rapport avec les déconnexion et reconnexions que
j'utilise :
Par contre il existe des options asyncmap qui je ne sais pas si elles sont
en rapport ou non avec notre problème et je ne sais pas exactement comment
paramétrer ces options.
PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d
marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à
ce sujet.
A l'occasion, publiez les, ça peut être intéressant. :)
Dans le message <news:, *Annie D.* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
A peine deux jours après avoir mis en service mon nouveau routeur ADSL, je constate qu'il est atteint du bug qui provoque l'arrêt de pppd en mode 'persist' après une déconnexion (celle des 24h de FT) :
pppd[398]: LCP terminated by peer pppoe[400]: Session terminated -- received PADT from peer pppd[398]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25) pppd[398]: tcflush failed: Input/output error pppd[398]: Exit.
J'ai retrouvé le fil de discussion de février 2004 dans lequel Tichou disait que le bug était bien connu mais sans solution probante.
Je rencontre toujours le même problème, de façon irrégulière comme le montre les logs à l'URL suivante :
http://magnolia.tichou.org/~tichou/pppd_log
et qui se traduit à chaque fois par un arrêt du daemon pppd. Cette erreur c'est toujours produit après la réception et l'envoi d'un paquet PADT et jamais dans un autre cas.
Après quelques recherches, je n'ai rien trouvé d'autre que des scripts plus ou moins crades qui surveillent et redémarrent pppd.
Voici les deux scripts maisons que j'utilise sur une Gentoo, celui qui lance les services adsl au démarrage de la machine :
$ cat /etc/init.d/adsl.easynet #!/sbin/runscript
LINK=${myservice#adsl.}
depend() { need net }
checkconfig() { if [ ! -f /etc/ppp/peers/${LINK} ] then eerror "No /etc/ppp/peers/${LINK} file exists!" return 1 fi }
et celui qui gère le lancement du daemon pppd et de son relancement en cas d'arrêt de celui-ci :
$ cat /root/bin/adsl #!/bin/sh
while [ true ] do /usr/bin/setsid /usr/sbin/pppd call $1 & wait sleep 5 done
Y aurait-t-il eu du nouveau depuis ?
A l'époque non, car aucune nouvelle version de pppd corrigeant ce problème n'était disponible et aucun patch correctif. Votre post m'a fait replonger sur ce problème et j'ai pu m'apercevoir que depuis février était disponible une nouvelle version de pppd, la 2.4.2. Le ChangeLog ne fait état que de très peu de changements ou de corrections, on a le droit à un :
* Fixed several bugs
C'est maigre...
Mais en analysant les nouvelles sources, je remarque que la partie du code responsable de cette erreur a été réécrite et semble prendre en compte de nouvelles choses.
J'en ai donc profité pour installer cette nouvelle version de pppd et j'attends de voir si le problème se manifeste toujours ou pas. Pour l'instant la dernière déconnexion s'est produite sans erreur. Je vous tiens au courant pour les prochaines déconnexions.
Ce qui est curieux, c'est que j'ai essayé de reproduire le bug avec une connexion à un serveur pppoe-server sur une autre machine du LAN, mais quelle que soit la façon dont j'ai arrêté la connexion (kill pppd ou pppoe, poff, câble débranché), il ne s'est jamais produit.
Comme je l'ai déjà dis, le problème s'est toujours manifesté uniquement sur une connexion PPPoE et après le dialogue PADT/PADT qui signifie la fin d'une session PPPoE.
La configuration : Pentium MMX, Debian 3.0 Woody avec les paquets stables pppd 2.4.1 et pppoe 3.3, noyau 2.4.18 compilé à partir des sources Debian.
Il serait intéressant de voir si le problème se manifeste en utilisant pppd avec le plugin rp-pppoe.so ou bien avec le module kernel pppoe.
Si ça peut servir, je peux aussi donner les options de pppd et pppoe mais je n'ai rien vu dans ce que j'ai lu qui relie ce bug à l'une ou l'autre de ces options.
Voici les options en rapport avec les déconnexion et reconnexions que j'utilise :
Par contre il existe des options asyncmap qui je ne sais pas si elles sont en rapport ou non avec notre problème et je ne sais pas exactement comment paramétrer ces options.
PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à ce sujet.
A l'occasion, publiez les, ça peut être intéressant. :)
-- TiChou
Olivier COLIN
TiChou wrote:
: Voici les options en rapport avec les déconnexion et reconnexions que : j'utilise : : : persist : maxfail 0 : holdoff 10 : nodetach : lcp-echo-interval 8 : lcp-echo-failure 2 : : Par contre il existe des options asyncmap qui je ne sais pas si elles sont : en rapport ou non avec notre problème et je ne sais pas exactement comment : paramétrer ces options. : :> PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d :> marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à :> ce sujet. : : A l'occasion, publiez les, ça peut être intéressant. :)
: Voici les options en rapport avec les déconnexion et reconnexions que
: j'utilise :
:
: persist
: maxfail 0
: holdoff 10
: nodetach
: lcp-echo-interval 8
: lcp-echo-failure 2
:
: Par contre il existe des options asyncmap qui je ne sais pas si elles sont
: en rapport ou non avec notre problème et je ne sais pas exactement comment
: paramétrer ces options.
:
:> PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d
:> marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à
:> ce sujet.
:
: A l'occasion, publiez les, ça peut être intéressant. :)
: Voici les options en rapport avec les déconnexion et reconnexions que : j'utilise : : : persist : maxfail 0 : holdoff 10 : nodetach : lcp-echo-interval 8 : lcp-echo-failure 2 : : Par contre il existe des options asyncmap qui je ne sais pas si elles sont : en rapport ou non avec notre problème et je ne sais pas exactement comment : paramétrer ces options. : :> PS: par contre les scripts ip*tables dans ip*-up.d et ip*-down.d :> marchent tip-top, j'en profite pour remercier tous ceux qui m'ont aidé à :> ce sujet. : : A l'occasion, publiez les, ça peut être intéressant. :)
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Y aurait-t-il eu du nouveau depuis ?
A l'époque non, car aucune nouvelle version de pppd corrigeant ce problème n'était disponible et aucun patch correctif. Votre post m'a fait replonger sur ce problème et j'ai pu m'apercevoir que depuis février était disponible une nouvelle version de pppd, la 2.4.2. Le ChangeLog ne fait état que de très peu de changements ou de corrections, on a le droit à un :
* Fixed several bugs
C'est maigre...
Mais en analysant les nouvelles sources, je remarque que la partie du code responsable de cette erreur a été réécrite et semble prendre en compte de nouvelles choses.
J'en ai donc profité pour installer cette nouvelle version de pppd et j'attends de voir si le problème se manifeste toujours ou pas. Pour l'instant la dernière déconnexion s'est produite sans erreur. Je vous tiens au courant pour les prochaines déconnexions.
Cela fait donc quatre jours que j'ai installé la version 2.4.2 de ppp et il semble que cette version ne soit plus affecté par le bug qui nous concerne. En effet mes quatre déconnexions quotidiennes se sont passées sans soucis, le daemon pppd ne s'est pas interrompu.
-- TiChou
Dans le message <news:pwet.20040612221712@florizarre.tichou.org>,
*TiChou* tapota sur f.c.o.l.configuration :
Y aurait-t-il eu du nouveau depuis ?
A l'époque non, car aucune nouvelle version de pppd corrigeant ce
problème n'était disponible et aucun patch correctif.
Votre post m'a fait replonger sur ce problème et j'ai pu m'apercevoir que
depuis février était disponible une nouvelle version de pppd, la 2.4.2.
Le ChangeLog ne fait état que de très peu de changements ou de
corrections, on a le droit à un :
* Fixed several bugs
C'est maigre...
Mais en analysant les nouvelles sources, je remarque que la partie du
code responsable de cette erreur a été réécrite et semble prendre en
compte de nouvelles choses.
J'en ai donc profité pour installer cette nouvelle version de pppd et
j'attends de voir si le problème se manifeste toujours ou pas. Pour
l'instant la dernière déconnexion s'est produite sans erreur. Je vous
tiens au courant pour les prochaines déconnexions.
Cela fait donc quatre jours que j'ai installé la version 2.4.2 de ppp et il
semble que cette version ne soit plus affecté par le bug qui nous concerne.
En effet mes quatre déconnexions quotidiennes se sont passées sans soucis,
le daemon pppd ne s'est pas interrompu.
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Y aurait-t-il eu du nouveau depuis ?
A l'époque non, car aucune nouvelle version de pppd corrigeant ce problème n'était disponible et aucun patch correctif. Votre post m'a fait replonger sur ce problème et j'ai pu m'apercevoir que depuis février était disponible une nouvelle version de pppd, la 2.4.2. Le ChangeLog ne fait état que de très peu de changements ou de corrections, on a le droit à un :
* Fixed several bugs
C'est maigre...
Mais en analysant les nouvelles sources, je remarque que la partie du code responsable de cette erreur a été réécrite et semble prendre en compte de nouvelles choses.
J'en ai donc profité pour installer cette nouvelle version de pppd et j'attends de voir si le problème se manifeste toujours ou pas. Pour l'instant la dernière déconnexion s'est produite sans erreur. Je vous tiens au courant pour les prochaines déconnexions.
Cela fait donc quatre jours que j'ai installé la version 2.4.2 de ppp et il semble que cette version ne soit plus affecté par le bug qui nous concerne. En effet mes quatre déconnexions quotidiennes se sont passées sans soucis, le daemon pppd ne s'est pas interrompu.
-- TiChou
Annie D.
TiChou wrote:
Cela fait donc quatre jours que j'ai installé la version 2.4.2 de ppp et il semble que cette version ne soit plus affecté par le bug qui nous concerne. En effet mes quatre déconnexions quotidiennes se sont passées sans soucis, le daemon pppd ne s'est pas interrompu.
Tant mieux. Toutefois, c'est loin d'être une preuve absolue car en une semaine et un redémarrage (merci EDF) le bug ne s'est pas reproduit non plus chez moi alors que je n'ai rien changé. Et on trouve dans votre log des périodes de plus de 4 jours sans message d'erreur. Merci d'avoir fait l'essai et continuez de nous tenir au courant.
Concernant les conditions de survenue du bug, vous disiez, en réponse à mes essais infructueux de le reproduire avec un serveur PPPoE local :
Cette erreur c'est toujours produit après la réception et l'envoi d'un paquet PADT et jamais dans un autre cas.
Les logs montrent que dans mon unique (pour le moment) cas d'erreur et mes essais, il y a toujours eu un PADT envoyé ou reçu selon la façon dont la déconnexion est provoquée. Par contre, la ligne "LCP terminated by peer" n'apparaît que dans ma connexion internet, y compris la fois ou l'erreur s'est produite.
TiChou wrote:
Cela fait donc quatre jours que j'ai installé la version 2.4.2 de ppp et il
semble que cette version ne soit plus affecté par le bug qui nous concerne.
En effet mes quatre déconnexions quotidiennes se sont passées sans soucis,
le daemon pppd ne s'est pas interrompu.
Tant mieux. Toutefois, c'est loin d'être une preuve absolue car en une
semaine et un redémarrage (merci EDF) le bug ne s'est pas reproduit non
plus chez moi alors que je n'ai rien changé. Et on trouve dans votre log
des périodes de plus de 4 jours sans message d'erreur. Merci d'avoir
fait l'essai et continuez de nous tenir au courant.
Concernant les conditions de survenue du bug, vous disiez, en réponse à
mes essais infructueux de le reproduire avec un serveur PPPoE local :
Cette erreur c'est toujours produit après la réception et l'envoi d'un
paquet PADT et jamais dans un autre cas.
Les logs montrent que dans mon unique (pour le moment) cas d'erreur et
mes essais, il y a toujours eu un PADT envoyé ou reçu selon la façon
dont la déconnexion est provoquée. Par contre, la ligne "LCP terminated
by peer" n'apparaît que dans ma connexion internet, y compris la fois ou
l'erreur s'est produite.
Cela fait donc quatre jours que j'ai installé la version 2.4.2 de ppp et il semble que cette version ne soit plus affecté par le bug qui nous concerne. En effet mes quatre déconnexions quotidiennes se sont passées sans soucis, le daemon pppd ne s'est pas interrompu.
Tant mieux. Toutefois, c'est loin d'être une preuve absolue car en une semaine et un redémarrage (merci EDF) le bug ne s'est pas reproduit non plus chez moi alors que je n'ai rien changé. Et on trouve dans votre log des périodes de plus de 4 jours sans message d'erreur. Merci d'avoir fait l'essai et continuez de nous tenir au courant.
Concernant les conditions de survenue du bug, vous disiez, en réponse à mes essais infructueux de le reproduire avec un serveur PPPoE local :
Cette erreur c'est toujours produit après la réception et l'envoi d'un paquet PADT et jamais dans un autre cas.
Les logs montrent que dans mon unique (pour le moment) cas d'erreur et mes essais, il y a toujours eu un PADT envoyé ou reçu selon la façon dont la déconnexion est provoquée. Par contre, la ligne "LCP terminated by peer" n'apparaît que dans ma connexion internet, y compris la fois ou l'erreur s'est produite.
