Routing Probleme 7.2 Prof.
Hallo, ich versuche seit ca. 2 Wochen 7.2 Prof. als Router zu laufen zu bekommen. Leider friert der Rechner (nachvollziehbar) ein. Ich habe 7.2 mit den Einstellungen Netzwerk und KDE (komplett) installiert. In dem Rechner befinden sich nur 2 Netzwerkkarten und eine Grafikkarte. Zuerst habe ich die beiden Netzwerkkarten konfiguriert (eth0 192.168.0.10, eth1 192.168.22.1) Dann habe ich DSL installiert T-Online über yast2. Geht auch soweit. Dann habe ich in der rc.config START_FW und IP_FORWARDING auf yes gesetzt. Dann in /etc/rc.config.d die Datei firewall.rc.config folgendermaßen geändert: FW_DEV_WORLD = "ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24" FW_PROTECT_FROM_INTERNAL="no" Das ist ALLES was ich geändert habe, ansonsten handelt es sich um ein frisch installiertes System (zum x-ten mal). Die DSL-Verbindung starte ich dann mit rcpppoed start. Zum testen hängt nur ein Windows 2000 (sp2) Rechner am Linuxrechner. Der hat die IP 192.168.0.1 und Gateway ist 192.168.22.1. Nameserver ist 194.25.0.X (habe ich nicht mehr genau im Kopf, ist aber ein T-Online Nameserver) (Ich habe die Rechner sowohl einen HUB/Switch als auch über ein gedrehtes Kabel verbunden) Ich komme problemlos vom Windows2000 Rechner, als auch von Linux-Rechner ins Netz, kann surfen, mails abfragen usw. Dummerweise stürzt der Linuxrechner nach 5 - 30 sek. ab, wenn ich Bearshare (Gnutella Client) starte. Das passiert manchmal auch, wenn ICQ läuft oder ich von innen (über die zugewiesene IP von T-Online) auf den Apache zugreife (über 192.168.0.10 oder 192.168.22.1 nicht). Das ist aber selten (alle 2-3 Stunden). Wenn ich auf der Console bin, bleibt der Rechner einfach stehen (Cursor hört auch zu blinken, ping geht nicht mehr). Ich kann keine Taste mehr drücken, NUM-LOCK reagiert nicht. Wenn ich mich im KDE (Bildschirm) befinde werden die Farben etwas dunkler (oder verschieben sich) und es hängt. Es liegt NICHT am Linuxrechner selbst (PII 266 LX Chipsatz, 160MB RAM, 2*Realtek 8139, Matrox G200) Ich habe 4 Netzwerkkarten und habe alle durchprobiert (alle Realtek). Genauso habe ich eine G200, G400, Mystique und eine GeForce2 MX (3D Beschleunigung immer abgeschaltet) getestet. Der Fehler tritt trotzdem auf. Auch am Board/Prozessor kann es nicht liegen, da ich das gleiche Spiel an einem K6-2 500 mit MSI Board betrieben habe (auch alle Graka - Netzwerkkarten durchprobiert, ja, der Rechner hat auch anderes RAM genauso wie eine andere Festplatte) aber der geleiche Fehler. Ich kämpfe damit jetzt schon seit fast einem Monat. Hat jemand BITTE eine Idee? Was mache ich falsch ? Vielen Dank, Christian
Christian Rousselle schrieb:
Hallo,
Hallo Christian!
ich versuche seit ca. 2 Wochen 7.2 Prof. als Router zu laufen zu bekommen. Leider friert der Rechner (nachvollziehbar) ein.
Ähnliche, wenn nicht die selben Symptome habe ich auch bei mir bei zwei völlig unterschiedlich ausgestatteten Servern. Siehe dazu mein Threat "[suse-isdn] CAPI4Linux mit Fritz!PCI bringt Server zum Absturz". Ich vermutete, dass es an der AVM CAPI liegt, die ich hier installiert habe. Diese hast du vermutlich nicht installiert - also muss es nicht unbedingt an der CAPI liegen. Mein Bruder beschwert sich auch immer, dass Bearshare nicht funktioniert bzw. beschwere ich mich da, dass der Server dann abschmiert... Ich benutze auch ICQ (über Dante Socks5 Proxy). Ich benutze auch noch NAT/Masquerading über iptables (SuSEfirewall2). Seit dem ich die 7.2 habe, ist das alles so. Ich möchte aber auch nicht wieder auf die 7.1 zurück gehen (7.2 is einfacher aktuell zu halten). Davon mal abgesehen, dass ich die 7.1er CDs auch gar nicht mehr hab ;-( Vor ein paar Wochen habe ich auch mal einen Threat gestartet, in dem es darum ging, dass Samba, welcher auch auf dem Server läuft, alle paar Minuten die Netzwerkverbindung trennt. Das ist jedoch nur bei einem meiner beiden Server so. Beide laufen unter SuSE 7.2. Ich vermute da aber trotzdem auch einen Zusammenhang zu unserem gemeinsamen Problem der Instabilität.
Dann in /etc/rc.config.d die Datei firewall.rc.config folgendermaßen geändert:
FW_DEV_WORLD = "ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24" FW_PROTECT_FROM_INTERNAL="no"
Habe ich auch so.
Das ist aber selten (alle 2-3 Stunden).
Ja, manchmal läuft der Server bei mir auch 1-2 Tage durch, bis das wieder passiert.
Wenn ich auf der Console bin, bleibt der Rechner einfach stehen (Cursor hört auch zu blinken, ping geht nicht mehr). Ich kann keine Taste mehr drücken, NUM-LOCK reagiert nicht. Wenn ich mich im KDE (Bildschirm) befinde werden die Farben etwas dunkler (oder verschieben sich) und es hängt.
Ich habe auf den Server (antürlich!) kein KDE oder derartiges laufen, aber auf der Konsole kann ich es genauso nachvollziehen. Vielleicht sollte ich noch hinzufügen, dass mein Monitor am Server, der sich normalerweise im Stand-By-Mosu befindet, einschaltet, sobald sich der Server aufgehängt hat. Ich habe also schon quasi ein optisches Signal *fg*
Es liegt NICHT am Linuxrechner selbst (PII 266 LX Chipsatz, 160MB RAM, 2*Realtek 8139, Matrox G200)
Hm, ich hatte bei mir auch schon die Hardware vermutet (AMD Duron 750, Board mit VIA-KT133 Chip; da ist/war doch mal so ein Fehler drin...). Aber wenn du Intel hast, scheint es auch daran nicht zu liegen.
Ich kämpfe damit jetzt schon seit fast einem Monat. Hat jemand BITTE eine Idee? Was mache ich falsch ?
Sei froh - seit Erscheinen der 7.2 habe ich Probs damit... *grr* Auch ich bitte alle Leser _auf Knien_, zu helfen! Gruß Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
* Freitag, 10. August 2001 um 10:49 (+0200) schrieb Christian Rousselle:
[ T-DSL-Konfiguration ]
Dummerweise stürzt der Linuxrechner nach 5 - 30 sek. ab, wenn ich Bearshare (Gnutella Client) starte. [ ... ] Was mache ich falsch ?
Wahrscheinlich nichts, wenn du SuSEFirewall2 (iptables) benutzt. Es
gibt einen Bug im netfilter-Code im Zusammnehang mit
(Kernel-)PPPoE/MSSClamping der Kernel ab 2.4.3|4, der das von dir
beschriebene Verhalten auslöst.
Abhilfen:
[1] Upgrade auf einen aktuellen 2.4.7-ac*- oder 2.4.8-pre*-Kernel.
oder
[2] Umstieg auf SuSEFirewall(1) mit 'ipchains' und dem mssclampfw-Modul.
oder
[2] Downgrade auf Kernel 2.2.19 (erfordert [2]).
oder
[3] Umstieg auf den Userland-PPPoE-Client 'rp-pppoe'.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke schrieb:
* Freitag, 10. August 2001 um 10:49 (+0200) schrieb Christian Rousselle:
[ T-DSL-Konfiguration ]
Dummerweise stürzt der Linuxrechner nach 5 - 30 sek. ab, wenn ich Bearshare (Gnutella Client) starte. [ ... ] Was mache ich falsch ?
Wahrscheinlich nichts, wenn du SuSEFirewall2 (iptables) benutzt. Es gibt einen Bug im netfilter-Code im Zusammnehang mit (Kernel-)PPPoE/MSSClamping der Kernel ab 2.4.3|4, der das von dir beschriebene Verhalten auslöst.
Abhilfen:
[1] Upgrade auf einen aktuellen 2.4.7-ac*- oder 2.4.8-pre*-Kernel. oder [2] Umstieg auf SuSEFirewall(1) mit 'ipchains' und dem mssclampfw-Modul. oder [2] Downgrade auf Kernel 2.2.19 (erfordert [2]). oder [3] Umstieg auf den Userland-PPPoE-Client 'rp-pppoe'.
Mit anderen Worten: Es genügt, wenn ich den aktuellen SuSE-Kernel (AFAIK 2.4.7aa1 mit Patches vom 2.4.8pre, siehe ftp://ftp.suse.de/pub/mantel/next/lx_sus24.changes) installiere? Habe bei einem meiner Server erst vor 1-2 Wochen einen damals relativ aktuellen 2.4.7er von SuSE installiert. Wenn ich also auf den jetzt neuesten update, gehts? Eine Frage noch: Es benutzen doch sicherlich viele iptables - wieso wurde solch ein gravierender Fehler erst so spät bemerkt bzw. gefixt? Hoffnungsvoll Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
Hallo, ersteinmal scheint ja Hoffung zu bestehen ;-)
[1] Upgrade auf einen aktuellen 2.4.7-ac*- oder 2.4.8-pre*-Kernel. oder [2] Umstieg auf SuSEFirewall(1) mit 'ipchains' und dem mssclampfw-Modul. oder [2] Downgrade auf Kernel 2.2.19 (erfordert [2]). oder [3] Umstieg auf den Userland-PPPoE-Client 'rp-pppoe'.
Das wäre wunderbar. Mir fällt noch ein, dass ich auch mal die SuSe Persoanl Firewall nur mit masq konfiguriert hatte und die Probleme auch auftraten. Deckt die Erklärung auch diesen Fall ab, ich bin mir nicht ganz so sicher.
Mit anderen Worten: Es genügt, wenn ich den aktuellen SuSE-Kernel (AFAIK 2.4.7aa1 mit Patches vom 2.4.8pre, siehe ftp://ftp.suse.de/pub/mantel/next/lx_sus24.changes) installiere? Habe bei einem meiner Server erst vor 1-2 Wochen einen damals relativ aktuellen 2.4.7er von SuSE installiert. Wenn ich also auf den jetzt neuesten update, geht's?
Eine Frage noch: Es benutzen doch sicherlich viele iptables - wieso wurde solch ein gravierender Fehler erst so spät bemerkt bzw. gefixt?
Das verwundert mich auch etwas. Ich würde erwarten, dass dies dann eine FAQ wäre ?!? Christian
Christian Rousselle schrieb:
Hallo,
Bitte lass mich als Vorredner leben.
ersteinmal scheint ja Hoffung zu bestehen ;-)
Julian Pawlowski schrieb:
[1] Upgrade auf einen aktuellen 2.4.7-ac*- oder 2.4.8-pre*-Kernel. oder [2] Umstieg auf SuSEFirewall(1) mit 'ipchains' und dem mssclampfw-Modul. oder [2] Downgrade auf Kernel 2.2.19 (erfordert [2]). Oder [3] Umstieg auf den Userland-PPPoE-Client 'rp-pppoe'.
Das wäre wunderbar. Mir fällt noch ein, dass ich auch mal die SuSe Persoanl Firewall nur mit masq konfiguriert hatte und die Probleme auch auftraten. Deckt die Erklärung auch diesen Fall ab, ich bin mir nicht ganz so sicher.
Ich glaube nicht, dass das auch abgedeckt wird (oder?). Jedenfalls ist mir gerade noch eingefallen, dass ich noch einen Server bei uns hier im Jugendzentrum hingestellt habe, der jetzt auch auf SuSE 7.2 läuft. Abstürze hatte ich da aber noch nicht (trotz iptables/SuSEfirewall2/CAPI4Linux).
Eine Frage noch: Es benutzen doch sicherlich viele iptables - wieso wurde solch ein gravierender Fehler erst so spät bemerkt bzw. gefixt?
Das verwundert mich auch etwas. Ich würde erwarten, dass dies dann eine FAQ wäre ?!?
Meine Rede. Gruß Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
* Freitag, 10. August 2001 um 12:05 (+0200) schrieb Julian Pawlowski:
Mit anderen Worten: Es genügt, wenn ich den aktuellen SuSE-Kernel (AFAIK 2.4.7aa1 mit Patches vom 2.4.8pre, siehe ftp://ftp.suse.de/pub/mantel/next/lx_sus24.changes) installiere? Habe bei einem meiner Server erst vor 1-2 Wochen einen damals relativ aktuellen 2.4.7er von SuSE installiert. Wenn ich also auf den jetzt neuesten update, gehts?
Mit den SuSE-Kerneln kenne ich mich nicht aus. Evtl. lassen sie sich nicht problemlos mit den "Vanilla"-pre-Patches patchen. AFAIK sind die Netfilter-Patches auch "separat erhältlich" (für Kernel-2.4.7), bei Bedarf "einfach" mal das Archiv der Netfilter-Mailinglisten durchsuchen (Ende Juli/Anfang August).
Eine Frage noch: Es benutzen doch sicherlich viele iptables - wieso wurde solch ein gravierender Fehler erst so spät bemerkt bzw. gefixt?
Das hat IMHO mehrere Gründe:
1.) Der Fehler tritt erst in Kerneln >= 2.4.3|4 auf.
2.) Der Fehler zeigt sich wohl nur mit bestimmten Client-Programmen
und dabei scheint es auch noch von der Prozessor-Leistung
abzuhängen, ob es zum "Einfrieren" des Systems bzw. zum
Kernel-Oops führt. AFAIR war der "kräftigste" Prozessor ein
Celeron@400MHz.
3.) Nur wenige Distributionen nutzen z.Zt. standardmäßig Kernel-PPPoE
und iptables.
4.) Nur (noch) wenige "User" sind bereit/in der Lage (PPPoE ist ein
Privatkunden-"Protokoll") solchen Fehler nachzugehen und die
verantwortlichen Maintainer zu informieren. Stattdessen werden die
Probleme umgangen, mit Userland-PPPoE oder Kernel-Downgrade (siehe
auch "http://sdb.suse.de/de/sdb/html/hvogel_tbraza_dsl72.html").
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke schrieb:
* Freitag, 10. August 2001 um 12:05 (+0200) schrieb Julian Pawlowski:
Mit anderen Worten: Es genügt, wenn ich den aktuellen SuSE-Kernel (AFAIK 2.4.7aa1 mit Patches vom 2.4.8pre, siehe ftp://ftp.suse.de/pub/mantel/next/lx_sus24.changes) installiere? Habe bei einem meiner Server erst vor 1-2 Wochen einen damals relativ aktuellen 2.4.7er von SuSE installiert. Wenn ich also auf den jetzt neuesten update, gehts?
Mit den SuSE-Kerneln kenne ich mich nicht aus. Evtl. lassen sie sich nicht problemlos mit den "Vanilla"-pre-Patches patchen.
Ja, das ist der fall. Patchen geht ohne genaue Kenntnisse über den Stand/Aufbau der SuSE-Kernels nicht. Nur mit original Kernel. Da ich mir das dauernde Neukompilieren und Ärgern, wenn wenn etwas nicht richtig funktioniert, ersparen möchte, bevorzuge ich seit längerem die pre-RPMs von SuSE, die immer recht aktuell gehalten sind.
AFAIK sind die Netfilter-Patches auch "separat erhältlich" (für Kernel-2.4.7), bei Bedarf "einfach" mal das Archiv der Netfilter-Mailinglisten durchsuchen (Ende Juli/Anfang August).
Hm, also laut der letzten Meldung im change-Log des neuesten SuSE-Kernels sollte der Fehler ja da bejoben sein: ---schnipp--- Wed Aug 8 17:19:18 CEST 2001 - mantel@suse.de - fix masquerading oops - fix problem with reiserfs corrupting files under high load when filling holes in files ---schnapp--- Das Problem mit ReiserFS hatte ich auch schon mehrmals. Wolln ma schaun, was es bringt ;-)
Eine Frage noch: Es benutzen doch sicherlich viele iptables - wieso wurde solch ein gravierender Fehler erst so spät bemerkt bzw. gefixt? Das hat IMHO mehrere Gründe:
1.) Der Fehler tritt erst in Kerneln >= 2.4.3|4 auf.
Axo. Da haben die also mitten im Kernel-Realise mist gebaut ;-)
2.) Der Fehler zeigt sich wohl nur mit bestimmten Client-Programmen und dabei scheint es auch noch von der Prozessor-Leistung abzuhängen, ob es zum "Einfrieren" des Systems bzw. zum Kernel-Oops führt. AFAIR war der "kräftigste" Prozessor ein Celeron@400MHz.
Achso... Wie sieht denn da die Regel aus? Je mehr Rechenpower, desto geringer die Chance, dass der Rechner einfriert? Also bei meinem 750er duron ist das genauso, wie bei dem 233er p-mmx...
3.) Nur wenige Distributionen nutzen z.Zt. standardmäßig Kernel-PPPoE und iptables.
Von Standard kann ja bei SuSE keine Rede sein - auf iptables habe ich selbst umgestellt.
4.) Nur (noch) wenige "User" sind bereit/in der Lage (PPPoE ist ein Privatkunden-"Protokoll") solchen Fehler nachzugehen und die verantwortlichen Maintainer zu informieren. Stattdessen werden die Probleme umgangen, mit Userland-PPPoE oder Kernel-Downgrade (siehe auch "http://sdb.suse.de/de/sdb/html/hvogel_tbraza_dsl72.html").
War das ein Kompliment/Danke an Andreas und mich, dass wir/ich uns/mich da auch noch hinterklemme/n? ,-) Gruß Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
* Freitag, 10. August 2001 um 14:26 (+0200) schrieb Julian Pawlowski:
Andreas Koenecke schrieb:
2.) Der Fehler zeigt sich wohl nur mit bestimmten Client-Programmen und dabei scheint es auch noch von der Prozessor-Leistung abzuhängen, ob es zum "Einfrieren" des Systems bzw. zum Kernel-Oops führt. AFAIR war der "kräftigste" Prozessor ein Celeron@400MHz.
Achso... Wie sieht denn da die Regel aus? Je mehr Rechenpower, desto geringer die Chance, dass der Rechner einfriert?
Ja, das war meine Hypothese...
Also bei meinem 750er duron ist das genauso, wie bei dem 233er p-mmx...
..., die jetzt "gestorben" ist. ;-) (Kannst du das "Einfrieren" (mit PPPoE) reproduzierbar erzeugen? Wenn ja, mit welchem Client-Programm bei welchem Dienst?)
4.) Nur (noch) wenige "User" sind bereit/in der Lage (PPPoE ist ein [ ... ]
War das ein Kompliment/Danke an Andreas und mich, dass wir/ich uns/mich da auch noch hinterklemme/n? ,-)
Sozusagen ;-)
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke schrieb:
* Freitag, 10. August 2001 um 14:26 (+0200) schrieb Julian Pawlowski:
Andreas Koenecke schrieb:
2.) Der Fehler zeigt sich wohl nur mit bestimmten Client-Programmen und dabei scheint es auch noch von der Prozessor-Leistung abzuhängen, ob es zum "Einfrieren" des Systems bzw. zum Kernel-Oops führt. AFAIR war der "kräftigste" Prozessor ein Celeron@400MHz.
Achso... Wie sieht denn da die Regel aus? Je mehr Rechenpower, desto geringer die Chance, dass der Rechner einfriert?
Ja, das war meine Hypothese...
Also bei meinem 750er duron ist das genauso, wie bei dem 233er p-mmx...
..., die jetzt "gestorben" ist. ;-)
Sorry, wollte dir doch nicht deine Träume nehmen! ;-)
(Kannst du das "Einfrieren" (mit PPPoE) reproduzierbar erzeugen? Wenn ja, mit welchem Client-Programm bei welchem Dienst?)
Ich habe hier kein DSL. Ich glaube, du verwechselst den Threat oder so... Jedenfalls läuft bei mir hier kein PPPoE, aber bei einem Server im Jugendzentrum, den ich betreue, ab Mittwoch wohl. Reproduzieren kann ich nur (bei ISDN mit C4L) ein Hängenbleiben mit Bearshare. Habe allerding grad den neuesten SuSE-Kernel installiert, wo laut changes.log der entsprechende Fix mit drin sein soll. Bearshare geht jetzt wieder ohne Absturz - hoffentlich is das im allgemeinen jetzt auch so ;-) Die nächsten Tage werden es zeigen. Gruß Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
From: "Julian Pawlowski"
Andreas Koenecke schrieb:
* Freitag, 10. August 2001 um 14:26 (+0200) schrieb Julian Pawlowski:
Andreas Koenecke schrieb:
2.) Der Fehler zeigt sich wohl nur mit bestimmten Client-Programmen und dabei scheint es auch noch von der
(Kannst du das "Einfrieren" (mit PPPoE) reproduzierbar erzeugen? Wenn ja, mit welchem Client-Programm bei welchem Dienst?)
Ich habe hier kein DSL. Ich glaube, du verwechselst den Threat oder so...
Ich habe in meiner (vor)letzen Mail geschrieben, wie ich es nachvollziehen kann. (wahlweise mit ICQ, BearShear, wobei jeder andere Gnutella Client funktionieren sollte oder sogar nur mit ein paar http zugriffen.) War das gemeint?
Jedenfalls läuft bei mir hier kein PPPoE, aber bei einem Server im Jugendzentrum, den ich betreue, ab Mittwoch wohl. Reproduzieren kann ich nur (bei ISDN mit C4L) ein Hängenbleiben mit Bearshare. Habe allerding grad den neuesten SuSE-Kernel installiert, wo laut changes.log der entsprechende Fix mit drin sein soll. Bearshare geht jetzt wieder ohne Absturz - hoffentlich is das im allgemeinen jetzt auch so ;-) Die nächsten Tage werden es zeigen.
Woher hast du den Kernel Patch und wie installierst du ihn? Christian
* Freitag, 10. August 2001 um 16:31 (+0200) schrieb Christian Rousselle:
Ich habe in meiner (vor)letzen Mail geschrieben, wie ich es nachvollziehen kann. (wahlweise mit ICQ, BearShear, wobei jeder andere Gnutella Client funktionieren
OK, ich werde es diese Wochenende mal mit BearShear probieren. Tritt das "Einfrieren" bei allen Gnutella-Servern auf oder nur bei bestimmten. Wie lange nach dem Zugriff friert der Router (spätestens) ein?
War das gemeint?
Ja.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
From: "Andreas Koenecke"
* Freitag, 10. August 2001 um 16:31 (+0200) schrieb Christian Rousselle:
Ich habe in meiner (vor)letzen Mail geschrieben, wie ich es
nachvollziehen
kann. (wahlweise mit ICQ, BearShear, wobei jeder andere Gnutella Client funktionieren
OK, ich werde es diese Wochenende mal mit BearShear probieren. Tritt das "Einfrieren" bei allen Gnutella-Servern auf oder nur bei bestimmten. Wie lange nach dem Zugriff friert der Router (spätestens) ein?
Es tritt nach 1-10 sek auf, nachdem eine Verbindung zu (irgend)einem Host besteht. Christian
From: "Christian Rousselle"
From: "Andreas Koenecke"
Sent: Friday, August 10, 2001 4:43 PM Subject: Re: Routing Probleme 7.2 Prof. * Freitag, 10. August 2001 um 16:31 (+0200) schrieb Christian Rousselle:
OK, ich werde es diese Wochenende mal mit BearShear probieren. Tritt das "Einfrieren" bei allen Gnutella-Servern auf oder nur bei bestimmten. Wie lange nach dem Zugriff friert der Router (spätestens) ein?
Es tritt nach 1-10 sek auf, nachdem eine Verbindung zu (irgend)einem Host besteht.
Nachdem ich das default Kernel rpm von ftp://ftp.suse.com/pub/people/mantel/next/rpm/ installiert habe, läuft alles *ohne* Probleme, ICQ, BearShare, Mail und Netz :) Juchuu ! Danke an Andreas und Julian :) Christian
Christian Rousselle schrieb:
Nachdem ich das default Kernel rpm von ftp://ftp.suse.com/pub/people/mantel/next/rpm/ installiert habe, läuft alles *ohne* Probleme, ICQ, BearShare, Mail und Netz :) Juchuu !
Geht mir genauso! Es scheint zu wirken ,-)
Danke an Andreas und Julian :)
Nichts du danken - reiner Egoismus *fg* Gruß Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
Christian Rousselle schrieb:
Julian Pawlowski
schrieb: Andreas Koenecke schrieb:
* Freitag, 10. August 2001 um 14:26 (+0200) schrieb Julian Pawlowski:
Andreas Koenecke schrieb:
2.) Der Fehler zeigt sich wohl nur mit bestimmten Client-Programmen und dabei scheint es auch noch von der
(Kannst du das "Einfrieren" (mit PPPoE) reproduzierbar erzeugen? Wenn ja, mit welchem Client-Programm bei welchem Dienst?)
Ich habe hier kein DSL. Ich glaube, du verwechselst den Threat oder so...
Ich habe in meiner (vor)letzen Mail geschrieben, wie ich es nachvollziehen kann. (wahlweise mit ICQ, BearShear, wobei jeder andere Gnutella Client funktionieren sollte oder sogar nur mit ein paar http zugriffen.) War das gemeint?
Nein. Ich weiß nur nicht, warum du mich in diesem Threat nach dem PPPoE fragst. Jedenfalls kann ich mit deiner Aussage oben nichts anfangen.
Jedenfalls läuft bei mir hier kein PPPoE, aber bei einem Server im Jugendzentrum, den ich betreue, ab Mittwoch wohl. Reproduzieren kann ich nur (bei ISDN mit C4L) ein Hängenbleiben mit Bearshare. Habe allerding grad den neuesten SuSE-Kernel installiert, wo laut changes.log der entsprechende Fix mit drin sein soll. Bearshare geht jetzt wieder ohne Absturz - hoffentlich is das im allgemeinen jetzt auch so ;-) Die nächsten Tage werden es zeigen.
Woher hast du den Kernel Patch und wie installierst du ihn?
Kein Patch - einen komplett neuen Kernel (inklusive Patch halt). Findest du immer aktuell unter ftp://ftp.suse.com/pub/people/mantel/next/rpm/. SuSE gibt allerdings keine Garantie darauf. Nach dem Update des RPMs musst du nich ein "mk_initrc" und dann ein "lilo" machen (sonst startet dein rechner nicht mehr). Gruß Julian -- ______ JP solution Net Services / \ D-31655 Stadthagen, Germany / /___/ Visit: www.JP-solution.de \__/
* Freitag, 10. August 2001 um 16:09 (+0200) schrieb Julian Pawlowski:
Andreas Koenecke schrieb:
(Kannst du das "Einfrieren" (mit PPPoE) reproduzierbar erzeugen? Wenn ja, mit welchem Client-Programm bei welchem Dienst?)
Ich habe hier kein DSL. Ich glaube, du verwechselst den Threat oder so...
Ich? ;-) Im Ursprungsposting ging es zumindest um DSL...
Das der MASQ-Fehler auch bei ISDN auftritt, ist IMHO neu. Es betrifft
dann wohl auch nur die CAPI-Treiber...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (4)
-
Andreas Koenecke
-
Christian Rousselle
-
Christian Rousselle
-
Julian Pawlowski