Wird es von diesem Patch demnächst auch ein SuSE-update geben ?
Ich kann dem noch eins draufgeben. Bei mir ist es so, daß ich die Kanalbündelung mit einem callback out nutzen möchte. Die Probleme scheinen ähnlich.
Ich habe nach Anleitung (Suse 7.2) die mppp parameter eingestellt. Versuche ich es ohne Callback, dann funktioniert die Kanalbündelung. Stelle ich nun aber über Yast callback auf out, dann funktioniert es noch mit dem dialout (isdnctrl dial ippp0) bestens. Versuche ich nun mit isdnctrl addlink ippp0 den zweiten Kanal zuzuschalten, so erhalte ich zwar bei isdnctrl status ippp1, die Meldung ippp1 connected, allerdings ist das Routing wieder im Ursprungszustand, d.h. das Default Gateway ist weg.
Die unten aufgeführten Kommandos helfen da bei mir leider nicht, um das default Gateway wieder zu aktivieren.
Aber vielleicht hängt es ja ebenfalls mit den gefundenen Bugs zusammen ?
Ciao Lutz Suhrbier
Tietzenweg 21 12203 Berlin, Berlin Deutschland
phone: +49 (30) 843 06 966 Fax: +49 (30) 843 06 967 mobile:+49 (160) 714 30 91 email : lusu@prz.tu-berlin.de
-----Original Message----- From: kkeil@suse.de [mailto:kkeil@suse.de] Sent: Wednesday, July 18, 2001 9:13 PM To: Suse-Isdn@Suse. Com Subject: Re: [suse-isdn] MPPP und ibod loeschen default-route
On Fri, Jul 06, 2001 at 01:26:24AM +0200, Günter Niedermeier wrote:
Hallo,
ich möchte diesen thread aufgreifen, da ich dieses Problem fast genau so verifizieren kann (SuSE-7.2).
Ich betreibe hier zwei AVM A1 Karten die ich mit bis zu vier Kanaelen buendele. Mir sind ausser den hier erwaehnten Problemen noch ein paar Andere aufgefallen.
- ibod baut die ipppx slaves nicht in der Reihenfolge ab, wie sie aufgebaut wurden. Dies führt zu einem crash aller slaves, die hinter dem aufgelegten slave kommen. Dies kann man bedingt umgehen,
indem man
dem ibod ein STAYUP = 1 mitgibt, und den slaves ueber den isdnctrl eine absteigende idle hangup time mitgibt z.B. ippp1 20 ippp2 15 und ippp3 10 sekunden. Dann steuert der ibod das Aufbauen und der ipppd das Abbauen der Kanaele in der richtigen Reihenfolge.
OK bug gefunden, KERNEL :
--- linux/drivers/isdn/isdn_ppp.c.old Mon Jul 2 14:36:06 2001 +++ linux/drivers/isdn/isdn_ppp.c Mon Jul 16 18:37:39 2001 @@ -1909,8 +1912,15 @@ sdev = lp->slave; while (sdev) { isdn_net_local *mlp = (isdn_net_local *) sdev->priv;
if ((mlp->flags & ISDN_NET_CONNECTED))
if (mlp->slave) { /* find last connected link in chain */isdn_net_local *nlp = (isdn_net_local *)mlp->slave->priv;
if (!(nlp->flags & ISDN_NET_CONNECTED))break;} else if (mlp->flags & ISDN_NET_CONNECTED) break;- sdev = mlp->slave; } if (!sdev)
- sind nach einer 3 oder 4 kanaligen Verbindung beide Kanaele
der zweiten
Karte abgebaut worden, und anschliessend der zweite Kanal der ersten Karte ebenfalls, so wird, aus welchem grund auch immer vom ipppd die defaultroute geloescht, obwohl das master device ippp0 noch
online ist.
macht man waehrend dessen einen rcroute start, so ist die Verbindung wieder voll einsatzfaehig.
- wird nach einer solchen 3 oder 4 Kanalverbindung komplett aufgelegt (mit den unter 2. beschriebenen Effekten) wird das masterdevice nicht mehr zurueckgesetzt. es bleiben die vom Provider uebernommenen IP Adressen stehen. ein ifconfig ippp0 down und up hilft da nichts. erst ein rci4l restart loescht die Adressen, und setzt wieder die defaultwerte. Dieser Effekt ist sowohl mit ibod wie auch mit
manueller
Steuerung ueber isdnctrl addlink ... produzierbar.
Auch der bug (der schon immer im ipppd geschlummert hat) ist gefunden:
diff -u -r1.17 -r1.18 --- auth.c 2000/07/25 20:23:51 1.17 +++ auth.c 2001/07/18 18:51:34 1.18 @@ -221,7 +221,7 @@ else { struct link_struct *q; int i; /* bugcheck, stop after 1024 links */
for(i=1024,q=lns[unit].bundle_next;!i &&q!=&lns[unit];q=q->bundle_next,i--) {
for(i=1024,q=lns[unit].bundle_next;i &&q!=&lns[unit];q=q->bundle_next,i--) { if(q->bundle_next == &lns[unit]) break; }
-- Karsten Keil SuSE Labs ISDN development
-- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com