Ne devrait pas être backporté en 3.6, mais bon c'est enfin intégré au
cvs :)
Éric Masson
--
Je dirais, à voir sortir les noms de nouveaux groupes, que la
hiérarchie fr. est celle qui évolue le moins et le moins vite. Sans
doûte pour favoriser la pénétration d'Internet dans les foyers...
-+- ALG in: <http://www.le-gnu.net> - La stratégie fufer -+-
Ne devrait pas être backporté en 3.6, mais bon c'est enfin intégré au cvs :)
Quelqu'un à testé sur une connexion nerim ? Plus assez de machines...
Xav
Eric Masson
"Xav" == Xav writes:
'Lut,
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et reconnections (L'isp est Teaser qui utilise les services de Nerim pour l'adsl)
A+
Éric
-- B > Ah ben bravo ! a quand l'html dans les entetes ? CB> Hein ? tu lis pas l'iso-8859-1 dans le champ approved ?? Elle répond. Comment veux-tu qu'en plus elle ait le temps de lire ? -+- SJ in <http://www.le-gnu.net> : Les joyeuses commères d'Usenet -+-
"Xav" == Xav <xavier@toutafon.org.NOSPAM> writes:
'Lut,
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de
Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous
cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et
reconnections (L'isp est Teaser qui utilise les services de Nerim pour
l'adsl)
A+
Éric
--
B > Ah ben bravo ! a quand l'html dans les entetes ?
CB> Hein ? tu lis pas l'iso-8859-1 dans le champ approved ??
Elle répond. Comment veux-tu qu'en plus elle ait le temps de lire ?
-+- SJ in <http://www.le-gnu.net> : Les joyeuses commères d'Usenet -+-
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et reconnections (L'isp est Teaser qui utilise les services de Nerim pour l'adsl)
A+
Éric
-- B > Ah ben bravo ! a quand l'html dans les entetes ? CB> Hein ? tu lis pas l'iso-8859-1 dans le champ approved ?? Elle répond. Comment veux-tu qu'en plus elle ait le temps de lire ? -+- SJ in <http://www.le-gnu.net> : Les joyeuses commères d'Usenet -+-
Xav
Le 2004-12-01, Eric Masson a tapoté :
"Xav" == Xav writes:
'Lut,
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et reconnections (L'isp est Teaser qui utilise les services de Nerim pour l'adsl)
Oups, en fait je pensais au patch pour le support ipv6. Vraiment difficile ce matin (c'est pour ça que je faisais référence à nerim).
Xav
Le 2004-12-01, Eric Masson a tapoté :
"Xav" == Xav <xavier@toutafon.org.NOSPAM> writes:
'Lut,
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de
Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous
cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et
reconnections (L'isp est Teaser qui utilise les services de Nerim pour
l'adsl)
Oups, en fait je pensais au patch pour le support ipv6. Vraiment
difficile ce matin (c'est pour ça que je faisais référence à nerim).
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et reconnections (L'isp est Teaser qui utilise les services de Nerim pour l'adsl)
Oups, en fait je pensais au patch pour le support ipv6. Vraiment difficile ce matin (c'est pour ça que je faisais référence à nerim).
Xav
Eric Masson
"Xav" == Xav writes:
Xav> Oups, en fait je pensais au patch pour le support ipv6.
Pas vu passer, tu aurais une url ?
Éric
-- AB> Pourquoi proposer une réforme si c'est pour affirmer qu'elle ne AB> changera rien ? Pour mettre un frein définitif à l'immobilisme. -+-SP in http://www.le-gnu.net - Tout changer pour que rien ne bouge-+-
"Xav" == Xav <xavier@toutafon.org.NOSPAM> writes:
Xav> Oups, en fait je pensais au patch pour le support ipv6.
Pas vu passer, tu aurais une url ?
Éric
--
AB> Pourquoi proposer une réforme si c'est pour affirmer qu'elle ne
AB> changera rien ?
Pour mettre un frein définitif à l'immobilisme.
-+-SP in http://www.le-gnu.net - Tout changer pour que rien ne bouge-+-
Xav> Oups, en fait je pensais au patch pour le support ipv6.
Pas vu passer, tu aurais une url ?
Éric
-- AB> Pourquoi proposer une réforme si c'est pour affirmer qu'elle ne AB> changera rien ? Pour mettre un frein définitif à l'immobilisme. -+-SP in http://www.le-gnu.net - Tout changer pour que rien ne bouge-+-
Xav
Le 2004-12-01, Eric Masson a tapoté :
"Xav" == Xav writes:
Xav> Oups, en fait je pensais au patch pour le support ipv6.
Xav> Ce qui n'a plus beaucoup de rapport avec le kernel pppoe.
Ben là, pas testé du tout :
Ici la passerelle est en Free/mpd et ipv6 est désactivé (pas le temps de refaire une machine en RELENG_4 pour pouvoir changer la conf, ça attendra la bascule en RELENG_5).
Chez le client qui est passé en kernel pppoe (précédemment en pppoe via ppp(8)), ipv6 est désactivé dans la config des noyaux (Je sais c'est mal de ne pas utiliser GENERIC).
Éric
-- Bonjour je sais qu il existe un prog pour faire des cartes bancaires puis je l avoir par mail pas pour en fabriquer mais par curiosite merci a tous -+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+-
Xav> Ce qui n'a plus beaucoup de rapport avec le kernel pppoe.
Ben là, pas testé du tout :
Ici la passerelle est en Free/mpd et ipv6 est désactivé (pas le temps
de refaire une machine en RELENG_4 pour pouvoir changer la conf, ça
attendra la bascule en RELENG_5).
Chez le client qui est passé en kernel pppoe (précédemment en pppoe via
ppp(8)), ipv6 est désactivé dans la config des noyaux (Je sais c'est mal
de ne pas utiliser GENERIC).
Éric
--
Bonjour je sais qu il existe un prog pour faire des cartes bancaires
puis je l avoir par mail pas pour en fabriquer mais par curiosite
merci a tous
-+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+-
Xav> Ce qui n'a plus beaucoup de rapport avec le kernel pppoe.
Ben là, pas testé du tout :
Ici la passerelle est en Free/mpd et ipv6 est désactivé (pas le temps de refaire une machine en RELENG_4 pour pouvoir changer la conf, ça attendra la bascule en RELENG_5).
Chez le client qui est passé en kernel pppoe (précédemment en pppoe via ppp(8)), ipv6 est désactivé dans la config des noyaux (Je sais c'est mal de ne pas utiliser GENERIC).
Éric
-- Bonjour je sais qu il existe un prog pour faire des cartes bancaires puis je l avoir par mail pas pour en fabriquer mais par curiosite merci a tous -+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+-
Olivier Cherrier
On 2004-12-01, Xav wrote:
Le 2004-12-01, Eric Masson a tapoté :
"Xav" == Xav writes:
'Lut,
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et reconnections (L'isp est Teaser qui utilise les services de Nerim pour l'adsl)
Oups, en fait je pensais au patch pour le support ipv6. Vraiment difficile ce matin (c'est pour ça que je faisais référence à nerim).
On 2004-12-01, Xav <xavier@toutafon.org.NOSPAM> wrote:
Le 2004-12-01, Eric Masson a tapoté :
"Xav" == Xav <xavier@toutafon.org.NOSPAM> writes:
'Lut,
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de
Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous
cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et
reconnections (L'isp est Teaser qui utilise les services de Nerim pour
l'adsl)
Oups, en fait je pensais au patch pour le support ipv6. Vraiment
difficile ce matin (c'est pour ça que je faisais référence à nerim).
Xav> Quelqu'un à testé sur une connexion nerim ? Plus assez de Xav> machines...
Le patch initial sur une 3.5 stable, aucun problème à signaler, en tous cas beaucoup plus fiable que ppp(8) pour la gestion des déconnections et reconnections (L'isp est Teaser qui utilise les services de Nerim pour l'adsl)
Oups, en fait je pensais au patch pour le support ipv6. Vraiment difficile ce matin (c'est pour ça que je faisais référence à nerim).
Ne devrait pas être backporté en 3.6, mais bon c'est enfin intégré au cvs :)
Ca marche, comme le prouve ce message.
Je me suis juste fait avoir au debut par le fait qu'il fallait mettre les deux couches d'interface reseau a up pour que la synchro se fasse.
Mon hostname.pppoe0 ressemble a ca:
pppoedev ep1 !ifconfig ep1 up !spppcontrol $if myauthproto=pap myauthname= myauthkey !ifconfig $if inet 0.0.0.0 0.0.0.1 netmask 255.255.255.255 up
(apres avoir enleve myauthkey, bien sur)
plus un mygate a 0.0.0.1
Bien lire la doc de spppcontrol pour le caractere eminement magique de 0.0.0.0 et 0.0.0.1 (c'est un peu kludge comme adresse, d'ailleurs).
Penser a changer d'interface pour le nat dans pf, je me suis fait avoir.
Un truc a corriger par contre, c'est que pf ne comprend pas le 0.0.0.1 comme magique... heureusement que chez nerim j'ai une adresse fixe....
Eric Masson
"Marc" == Marc Espie writes:
'Lut,
Marc> Ca marche, comme le prouve ce message.
Je n'en doutais point, l'ayant expérimenté en 3.5 ;)
Marc> Je me suis juste fait avoir au debut par le fait qu'il fallait Marc> mettre les deux couches d'interface reseau a up pour que la Marc> synchro se fasse.
Effectivement.
Marc> Bien lire la doc de spppcontrol pour le caractere eminement Marc> magique de 0.0.0.0 et 0.0.0.1 (c'est un peu kludge comme adresse, Marc> d'ailleurs).
Du même ordre que celle utilisée par ppp(8)
Marc> Un truc a corriger par contre, c'est que pf ne comprend pas le Marc> 0.0.0.1 comme magique... heureusement que chez nerim j'ai une Marc> adresse fixe....
Une solution serait de régénérer pf.conf avec la bonne adresse et de recharcher icelui lors d'un changement de configuration de l'interface pppoe.
Pour monitorer les changements de configuration, j'ai utilisé l'ifwatchd de NetBSD qui n'a pas posé de problème particulier lors de la compilation. (Euh, je viens de voir que je n'ai pas fait de PR, désolé)
En tous cas, c'est vraiment une bonne nouvelle et pour l'instant c'est plus fiable que ne l'était la combinaison ppp(8) + pppoe(8)
Éric
-- ha bon donc dés qu'on ose faire la promotion de l'annonymitée on deviens un criminel et un filtre de plus -+- Y63 in: GNU - Faf, con, trouillard et fier de l'être -+-
"Marc" == Marc Espie <espie@tetto.gentiane.org> writes:
'Lut,
Marc> Ca marche, comme le prouve ce message.
Je n'en doutais point, l'ayant expérimenté en 3.5 ;)
Marc> Je me suis juste fait avoir au debut par le fait qu'il fallait
Marc> mettre les deux couches d'interface reseau a up pour que la
Marc> synchro se fasse.
Effectivement.
Marc> Bien lire la doc de spppcontrol pour le caractere eminement
Marc> magique de 0.0.0.0 et 0.0.0.1 (c'est un peu kludge comme adresse,
Marc> d'ailleurs).
Du même ordre que celle utilisée par ppp(8)
Marc> Un truc a corriger par contre, c'est que pf ne comprend pas le
Marc> 0.0.0.1 comme magique... heureusement que chez nerim j'ai une
Marc> adresse fixe....
Une solution serait de régénérer pf.conf avec la bonne adresse et de
recharcher icelui lors d'un changement de configuration de l'interface
pppoe.
Pour monitorer les changements de configuration, j'ai utilisé l'ifwatchd
de NetBSD qui n'a pas posé de problème particulier lors de la
compilation. (Euh, je viens de voir que je n'ai pas fait de PR, désolé)
En tous cas, c'est vraiment une bonne nouvelle et pour l'instant c'est
plus fiable que ne l'était la combinaison ppp(8) + pppoe(8)
Éric
--
ha bon donc dés qu'on ose faire la promotion de l'annonymitée on
deviens un criminel
et un filtre de plus
-+- Y63 in: GNU - Faf, con, trouillard et fier de l'être -+-
Je n'en doutais point, l'ayant expérimenté en 3.5 ;)
Marc> Je me suis juste fait avoir au debut par le fait qu'il fallait Marc> mettre les deux couches d'interface reseau a up pour que la Marc> synchro se fasse.
Effectivement.
Marc> Bien lire la doc de spppcontrol pour le caractere eminement Marc> magique de 0.0.0.0 et 0.0.0.1 (c'est un peu kludge comme adresse, Marc> d'ailleurs).
Du même ordre que celle utilisée par ppp(8)
Marc> Un truc a corriger par contre, c'est que pf ne comprend pas le Marc> 0.0.0.1 comme magique... heureusement que chez nerim j'ai une Marc> adresse fixe....
Une solution serait de régénérer pf.conf avec la bonne adresse et de recharcher icelui lors d'un changement de configuration de l'interface pppoe.
Pour monitorer les changements de configuration, j'ai utilisé l'ifwatchd de NetBSD qui n'a pas posé de problème particulier lors de la compilation. (Euh, je viens de voir que je n'ai pas fait de PR, désolé)
En tous cas, c'est vraiment une bonne nouvelle et pour l'instant c'est plus fiable que ne l'était la combinaison ppp(8) + pppoe(8)
Éric
-- ha bon donc dés qu'on ose faire la promotion de l'annonymitée on deviens un criminel et un filtre de plus -+- Y63 in: GNU - Faf, con, trouillard et fier de l'être -+-
naddy
Eric Masson wrote:
Marc> Un truc a corriger par contre, c'est que pf ne comprend pas le Marc> 0.0.0.1 comme magique... heureusement que chez nerim j'ai une Marc> adresse fixe....
Une solution serait de régénérer pf.conf avec la bonne adresse et de recharcher icelui lors d'un changement de configuration de l'interface pppoe.
Marc se trompe. Il ne faut pas utiliser l'adresse distante de l'interface PPP (représenté par l'adresse magique 0.0.0.1) pour la NAT, mais l'adresse locale.
Une adresse dynamique ne pose pas de problème. Dans une règle pf, si on met l'interface réseau entre parenthèses, pf mettra ses règles à jour en cas de changement de l'adresse IP affectée à l'interface en question.
Donc:
nat on $ext_if from $int_if:network to any -> ($ext_if)
En tous cas, c'est vraiment une bonne nouvelle et pour l'instant c'est plus fiable que ne l'était la combinaison ppp(8) + pppoe(8)
pppoe(4) prend moins de CPU, mais la couche sppp(4) qui gère le PPP est beaucoup moins configurable que ppp(8). Par exemple, Jason McIntyre était bien étonné quand il a remarqué que sa machine transmet un LCP echo request toutes les dix secondes. spppcontrol(8) ne permet pas de changer ce type de détail.
Une autre chose à laquelle il faut faire attention : Par défaut, ppp(8) fait du "MSS clamping" (option mssfixup). On perd ce truc avec pppoe(4)/sppp(4) et il faut ajouter une directive comme celle-ci
scrub out on pppoe0 all max-mss 1440
à pf.conf.
-- Christian "naddy" Weisgerber
Eric Masson <emss@free.fr> wrote:
Marc> Un truc a corriger par contre, c'est que pf ne comprend pas le
Marc> 0.0.0.1 comme magique... heureusement que chez nerim j'ai une
Marc> adresse fixe....
Une solution serait de régénérer pf.conf avec la bonne adresse et de
recharcher icelui lors d'un changement de configuration de l'interface
pppoe.
Marc se trompe. Il ne faut pas utiliser l'adresse distante de
l'interface PPP (représenté par l'adresse magique 0.0.0.1) pour la
NAT, mais l'adresse locale.
Une adresse dynamique ne pose pas de problème. Dans une règle pf,
si on met l'interface réseau entre parenthèses, pf mettra ses règles
à jour en cas de changement de l'adresse IP affectée à l'interface
en question.
Donc:
nat on $ext_if from $int_if:network to any -> ($ext_if)
En tous cas, c'est vraiment une bonne nouvelle et pour l'instant c'est
plus fiable que ne l'était la combinaison ppp(8) + pppoe(8)
pppoe(4) prend moins de CPU, mais la couche sppp(4) qui gère le PPP
est beaucoup moins configurable que ppp(8). Par exemple, Jason
McIntyre était bien étonné quand il a remarqué que sa machine
transmet un LCP echo request toutes les dix secondes. spppcontrol(8)
ne permet pas de changer ce type de détail.
Une autre chose à laquelle il faut faire attention : Par défaut,
ppp(8) fait du "MSS clamping" (option mssfixup). On perd ce truc
avec pppoe(4)/sppp(4) et il faut ajouter une directive comme celle-ci
scrub out on pppoe0 all max-mss 1440
à pf.conf.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
Marc> Un truc a corriger par contre, c'est que pf ne comprend pas le Marc> 0.0.0.1 comme magique... heureusement que chez nerim j'ai une Marc> adresse fixe....
Une solution serait de régénérer pf.conf avec la bonne adresse et de recharcher icelui lors d'un changement de configuration de l'interface pppoe.
Marc se trompe. Il ne faut pas utiliser l'adresse distante de l'interface PPP (représenté par l'adresse magique 0.0.0.1) pour la NAT, mais l'adresse locale.
Une adresse dynamique ne pose pas de problème. Dans une règle pf, si on met l'interface réseau entre parenthèses, pf mettra ses règles à jour en cas de changement de l'adresse IP affectée à l'interface en question.
Donc:
nat on $ext_if from $int_if:network to any -> ($ext_if)
En tous cas, c'est vraiment une bonne nouvelle et pour l'instant c'est plus fiable que ne l'était la combinaison ppp(8) + pppoe(8)
pppoe(4) prend moins de CPU, mais la couche sppp(4) qui gère le PPP est beaucoup moins configurable que ppp(8). Par exemple, Jason McIntyre était bien étonné quand il a remarqué que sa machine transmet un LCP echo request toutes les dix secondes. spppcontrol(8) ne permet pas de changer ce type de détail.
Une autre chose à laquelle il faut faire attention : Par défaut, ppp(8) fait du "MSS clamping" (option mssfixup). On perd ce truc avec pppoe(4)/sppp(4) et il faut ajouter une directive comme celle-ci
