FritzCARD-Classic unter Kernel 2.4.4 wählt nur ein Mal
Hallo,
zuerst dachte ich, die Karte sei nur defekt, aber jetzt ist es schon beim
zweiten Router so:
Das System: SuSE 7.2, Kernel 2.4.4
ippp0: FritzCARD Classic, normal unter YaST eingerichtet, I/O + Int OK
(IP: 172.16.0.1, PtP: 172.16.0.8, dynamisch)
eth0: RTL 8129 (läuft auch prima)
(IP: 10.0.0.1)
Proxy: Squid 2.3 (angepasste Standard-Installation - noch)
Firewall: deaktiviert
Routing:2 x 192.168-er Segm. über eth0 und ein Gateway (10.0.0.128) - OK
default über ippp0 an 172.16.0.8, dynamisch
BTW: Alle Routing innerhalb des lokalen Netzes funxen problemlos, Zugriff
auf den Indianer auch problemlos, ebenso auf gecachte Seiten (Squid)
Beim Aufruf einer neuen URL im Internet wird sauber die FritzCARD
aktiviert, die Verbindung hergestellt, DNS und IP angepasst und der
Traffic läuft wunderbar.
Aber: Wehe, die Verbindung wird durch Timeout getrennt. /etc/ip-down
schreibt alles wieder ordentlich zurück. Doch bei einer erneuten
Anforderung einer entfernten URL baut FritzCARD keine Verbindung mehr
auf. Nicht mal beim direkten Pingen auf eine entfernte IP-Adresse. Die
FritzCARD reagiert erst wieder nach einem Neustart (Selbst ein Restart
von i4l bewirkt nichts). Ich bin am Ende. Mit ISA-Teles_Karten hat es
immer Prima geklappt, aber hier ... ?????
Wer kennt hier den Haken und den Trick?
--
Mit besten Grüßen / With kind regards \\|//
(o -)
/-------------------------------------------oOOo---(_)---oOOo-\
| Matthias Houdek /// |
|
Hallo Matthias, ich hatte mal ein ähnliches Problem. Da hat der ipppd nach dem Beenden der Verbindung die Defaultroute nicht wieder auf die Adresse des ippp0 gesetzt. Ich habe das Problem nur durch einen Work-Around gelöst, in dem ich die Defaultroute im ip-down Script von Hand wieder gesetzt habe. Frank Eyermann
On Wed, Oct 03, 2001 at 07:24:07PM +0200, Frank Eyermann wrote:
Hallo Matthias,
ich hatte mal ein ähnliches Problem. Da hat der ipppd nach dem Beenden der Verbindung die Defaultroute nicht wieder auf die Adresse des ippp0 gesetzt. Ich habe das Problem nur durch einen Work-Around gelöst, in dem ich die Defaultroute im ip-down Script von Hand wieder gesetzt habe.
Das ist unnoetig wenn in der /etc/route.conf die entsprechenden Eintraege 4 Felder haben: netz gateway maske device z.B: default 192.168.1.1 0.0.0.0 ippp0 Hintergrund: ip-down ruft rcroute start ippp0 auf, was alle routes neu setzt die mit ippp0 verbunden sind, fehlt der Eintrag ippp0, wird die route nur bei "rcroute start" gesetzt, nicht bei "rcroute start <device>". Frueher wurden generell alle routen neu gesetzt, was aber zu Problemen fuehrt, wenn man mehr als eine Verbindung hat. Yast sollte das eigentlich richtig machen, nur bei updates gibt es Probleme, root hat aber bei der Installation der isdn utils eine Mail mit entsprechenden Hinweisen bekommen. -- Karsten Keil SuSE Labs ISDN development
Hi Karsten,
Ich habe das Problem nur durch einen Work-Around gelöst, in dem ich die Defaultroute im ip-down Script von Hand wieder gesetzt habe.
Das ist unnoetig wenn in der /etc/route.conf die entsprechenden Eintraege 4 Felder haben:
root hat aber bei der Installation der isdn utils eine Mail mit entsprechenden Hinweisen bekommen.
stimmt ja alles, doch statt eines Hinweises per Mail wäre es wohl auch kein größeres Problem gewesen, die route.conf anzupassen?! Ich mu0 jedenfalls zu meiner Schande gestehen, die Mail erst gelesen zu haben, als ich das Problem nach einigen Analysen selbst gelöst hatte ;-) Ein SDB-Eintrag, der klipp und klar darauf hinweist, daß nach einem Update auf 7.2 unbedingt route.conf anzupassen ist, wäre sicher hilfreich. cu, Knut
Am Donnerstag, 4. Oktober 2001 08:31 schrieb Knut Petersen:
Hi Karsten,
stimmt ja alles, doch statt eines Hinweises per Mail wäre es wohl auch kein größeres Problem gewesen, die route.conf anzupassen?! Ich mu0 jedenfalls zu meiner Schande gestehen, die Mail erst gelesen zu haben, als ich das Problem nach einigen Analysen selbst gelöst hatte ;-)
Ein SDB-Eintrag, der klipp und klar darauf hinweist, daß nach einem Update auf 7.2 unbedingt route.conf anzupassen ist, wäre sicher hilfreich.
cu, Knut
ACK!
Ich habe zu Hause meine Server mit 7.2 total neu aufgesetzt (war auch
ganz gut so, auch Linux freut sich über einen "Frühjahrsputz"), hatte
also kein Problem mit diesem Routing.
Der eine Kommunikationsserver in der Firma war mit Suse 7.0 aufgebaut.
Hier lief auch eine Teles-Karte, wie bei mir zu Hause. Jetzt haben wir
einen zweiten Kommunikationsserver für einen anderen Standort (aber mit
fast identischem LAN) gebraucht. Alles neu, aber Arbeit sparen und die
*.conf-Ddateien für Mail, Squid, route usw. einfach kopieren. Lief auch
alles Prima - bis auf ISDN. Also lag der Verdacht nahe, das es an der
Hardware liegt.
BTW - die root-Mail hatten wir natürlich nicht (gefunden), da kein Update
(eigentlich).
BTW-2: Die Wartung des Linux läuft zum großen Teil über Webmin. Webmin
meldet auch nach der Abwahl ordnungsgemäße Routen (?) >:-o
--
Mit besten Grüßen / With kind regards \\|//
(o -)
/-------------------------------------------oOOo---(_)---oOOo-\
| Matthias Houdek /// |
|
On Wed, Oct 03, 2001 at 05:18:28PM +0200, Matthias Houdek wrote:
Hallo,
zuerst dachte ich, die Karte sei nur defekt, aber jetzt ist es schon beim zweiten Router so:
Das System: SuSE 7.2, Kernel 2.4.4 ippp0: FritzCARD Classic, normal unter YaST eingerichtet, I/O + Int OK (IP: 172.16.0.1, PtP: 172.16.0.8, dynamisch) eth0: RTL 8129 (läuft auch prima) (IP: 10.0.0.1) Proxy: Squid 2.3 (angepasste Standard-Installation - noch) Firewall: deaktiviert Routing:2 x 192.168-er Segm. über eth0 und ein Gateway (10.0.0.128) - OK default über ippp0 an 172.16.0.8, dynamisch BTW: Alle Routing innerhalb des lokalen Netzes funxen problemlos, Zugriff auf den Indianer auch problemlos, ebenso auf gecachte Seiten (Squid)
Beim Aufruf einer neuen URL im Internet wird sauber die FritzCARD aktiviert, die Verbindung hergestellt, DNS und IP angepasst und der Traffic läuft wunderbar. Aber: Wehe, die Verbindung wird durch Timeout getrennt. /etc/ip-down schreibt alles wieder ordentlich zurück. Doch bei einer erneuten Anforderung einer entfernten URL baut FritzCARD keine Verbindung mehr auf. Nicht mal beim direkten Pingen auf eine entfernte IP-Adresse. Die FritzCARD reagiert erst wieder nach einem Neustart (Selbst ein Restart von i4l bewirkt nichts). Ich bin am Ende. Mit ISA-Teles_Karten hat es immer Prima geklappt, aber hier ... ?????
Hat damit nichts zu tun. Wahrscheinlich ist der Eintrag in der /etc/route.conf falsch, es fehlt ippp0 in der default Zeile, z.B: default 172.16.0.8 0.0.0.0 ippp0 -- Karsten Keil SuSE Labs ISDN development
participants (4)
-
Frank Eyermann -
Karsten Keil -
Knut Petersen -
Matthias Houdek