Hallo Liste, habe vor ein paar Tagen auf 6.3 umgestellt und habe seitdem (wie wohl jeder hier) ein paar kleine Probleme. Masquerading will ich erstmal nicht dikutieren. Viel mehr beschaeftig mich die Frage warum der Verbindungsaufbau offensichtlich 'irgendein' Routingproblem hat. Jedesmal wenn ich einen Verbindungsaufbau per WWW-Aufruf im Browser eines Clients initiiere wird zwar sofort eine Verbindung aufgebaut, ich bekomme auch sofort (nach ca. 1Sek) folgende Meldung: =================== schnipp ================== While trying to retrieve the URL: http://www.irgendwas.com? The following error was encountered: Connection Failed The system returned: (101) Network is unreachable The remote host or network may be down. Please try the request again. =============== schnapp ======================= Aehnliches passiert mit 'fetchmail': fetchmail: POP3 connection to mail.xxx.de failed: Network is unreachable fetchmail: Query status=2 Wenn bereits eine Verbindung steht ist Alles ok. Hat jemand eine Idee? Gruss, L@rs
Lars Mueller wrote:
habe vor ein paar Tagen auf 6.3 umgestellt und habe seitdem (wie wohl jeder hier) ein paar kleine Probleme.
Masquerading will ich erstmal nicht dikutieren. Viel mehr beschaeftig mich die Frage warum der Verbindungsaufbau offensichtlich 'irgendein' Routingproblem hat. Jedesmal wenn ich einen Verbindungsaufbau per WWW-Aufruf im Browser eines Clients initiiere wird zwar sofort eine Verbindung aufgebaut, ich bekomme auch sofort (nach ca. 1Sek) folgende Meldung:
=================== schnipp ==================
While trying to retrieve the URL: http://www.irgendwas.com?
The following error was encountered:
Connection Failed The system returned:
(101) Network is unreachable The remote host or network may be down. Please try the request again.
=============== schnapp =======================
Aehnliches passiert mit 'fetchmail':
fetchmail: POP3 connection to mail.xxx.de failed: Network is unreachable fetchmail: Query status=2
Wenn bereits eine Verbindung steht ist Alles ok. Hat jemand eine Idee?
(/etc/rc.config:) # Do you want the "dynamic IP patch" to be enabled at bootup? # (yes/no) # IP_DYNIP="yes" Hast du das nicht eingestellt? Infos dazu stehen in der SDB (suche nach IP_DYNADDR). christian -- No courtesy copy (CC:), please. I'm reading here!
Hallo,
ich habe das gleiche Problem allerdings ist
DynIP bei mir schon immer auf yes gestellt??
Ich hatte dies hier vor längerer Zeit mal gepostet
und auch diese Antwort erhalten.
Nun traue ich mich gar nicht mehr dies hier nochmal zu fragen
aber es nervt noch immer.
Auch ein ping schlägt zunächst fehl obwohl die Verbindung dann
steht und ein anschließender ping funktioniert einwandfei????
Ciao
Frank
------------------------------------------------------------------------
--------------------
Frank Wagner
Esters Elektronik GmbH
Abt. Entwicklung
63110 Rodgau
Tel.: 06106 / 3040 Fax: 06106 / 18192
Email: f.wagner@esters.de
Web: http://www.esters.de
------------------------------------------------------------------------
--------------------
-----Ursprüngliche Nachricht-----
Von: Christian Schult
Lars Mueller wrote:
habe vor ein paar Tagen auf 6.3 umgestellt und habe seitdem (wie wohl jeder hier) ein paar kleine Probleme.
Masquerading will ich erstmal nicht dikutieren. Viel mehr beschaeftig mich die Frage warum der Verbindungsaufbau offensichtlich 'irgendein' Routingproblem hat. Jedesmal wenn ich einen Verbindungsaufbau per WWW-Aufruf im Browser eines Clients initiiere wird zwar sofort eine Verbindung aufgebaut, ich bekomme auch sofort (nach ca. 1Sek) folgende Meldung:
=================== schnipp ==================
While trying to retrieve the URL: http://www.irgendwas.com?
The following error was encountered:
Connection Failed The system returned:
(101) Network is unreachable The remote host or network may be down. Please try the request again.
=============== schnapp =======================
Aehnliches passiert mit 'fetchmail':
fetchmail: POP3 connection to mail.xxx.de failed: Network is unreachable fetchmail: Query status=2
Wenn bereits eine Verbindung steht ist Alles ok. Hat jemand eine Idee?
(/etc/rc.config:) # Do you want the "dynamic IP patch" to be enabled at bootup? # (yes/no) # IP_DYNIP="yes"
Hast du das nicht eingestellt? Infos dazu stehen in der SDB (suche nach IP_DYNADDR).
christian
-- No courtesy copy (CC:), please. I'm reading here!
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
Hallo Liste,
habe vor ein paar Tagen auf 6.3 umgestellt und habe seitdem (wie wohl jeder hier) ein paar kleine Probleme. Masquerading will ich erstmal nicht dikutieren. Viel mehr beschaeftig mich die Frage warum der Verbindungsaufbau offensichtlich 'irgendein' Routingproblem hat. Jedesmal wenn ich einen Verbindungsaufbau
Sorry, habe vergessen zu erwaehnen, dass IP_DYNIP=yes in rc.config natuerlich gesetzt ist ----- Original Message ----- From: Lars Mueller per WWW-Aufruf
im Browser eines Clients initiiere wird zwar sofort eine Verbindung aufgebaut, ich bekomme auch sofort (nach ca. 1Sek) folgende Meldung:
=================== schnipp ==================
While trying to retrieve the URL: http://www.irgendwas.com?
The following error was encountered:
Connection Failed The system returned:
(101) Network is unreachable The remote host or network may be down. Please try the request again.
=============== schnapp =======================
Aehnliches passiert mit 'fetchmail':
fetchmail: POP3 connection to mail.xxx.de failed: Network is unreachable fetchmail: Query status=2
Wenn bereits eine Verbindung steht ist Alles ok. Hat jemand eine Idee?
Hallo Lars, auch ich habe dieses Problem. An alle Mitleser die Bitte, jetzt keine Ratschlaege wie Nameserver aufsetzen, oder ip-up Regeln lesen usw. Das Problem liegt darin, dass eine Verbindung hergestellt wird, die dynamischen Adressen vergeben werden, die neue Adresse in die Routing Tabelle gewchrieben wird. Bevor diese neue Route gestzt wird, versucht der Resolver noch ueber die alte Adresse eine Verbindung herzustellen, was natuerlich nicht mehr funktioniert. Nach etwa 2-3 S ekunden, wenn naemlich der Resolver seinen zweiten Versuch startet, steht das Routing und die Verbindung kann hergestellt werden. On 15-Dec-99 Lars Mueller wrote:
Hallo Liste,
habe vor ein paar Tagen auf 6.3 umgestellt und habe seitdem (wie wohl jeder hier) ein paar kleine Probleme. Masquerading will ich erstmal nicht dikutieren. Viel mehr beschaeftig mich die Frage warum der Verbindungsaufbau offensichtlich 'irgendein' Routingproblem hat. Jedesmal wenn ich einen Verbindungsaufbau per WWW-Aufruf im Browser eines Clients initiiere wird zwar sofort eine Verbindung aufgebaut, ich bekomme auch sofort (nach ca. 1Sek) folgende Meldung:
Meine Erlaeterungen zu dem Problem stehen weiter oben, ich bitte um
Vergebung, das ich die Gepflogenheiten nicht gewahrt habe. Ich bitte
mal jeden, der dieses Problem hat, in der Datei /etc/resolv.conf
unterhalb der Zeile nameserver eine weitere Zeile einzufuegen mit
options debug
Dadurch werden die Fehlermeldungen des Resolvers in die
/var/log/messages geschrieben. Frage an SuSE: ist der Resolver von
BIND8 mit DEBUG kompiliert worden ?
Gruss
Dieter
--
E-Mail: Dieter Kluenter
Hi Dieter Dieter Kluenter schrieb:
Hallo Lars, auch ich habe dieses Problem. An alle Mitleser die Bitte, jetzt keine Ratschlaege wie Nameserver aufsetzen, oder ip-up Regeln lesen usw. Das Problem liegt darin, dass eine Verbindung hergestellt wird, die dynamischen Adressen vergeben werden, die neue Adresse in die Routing Tabelle gewchrieben wird. Bevor diese neue Route gestzt wird, versucht der Resolver noch ueber die alte Adresse eine Verbindung herzustellen, was natuerlich nicht mehr funktioniert. Nach etwa 2-3 S ekunden, wenn naemlich der Resolver seinen zweiten Versuch startet, steht das Routing und die Verbindung kann hergestellt werden.
Ja das wird einem eigendlich in jedem Linux-Forum gesagt aber gibt es abhilfe? Ich hab für Sandmail z.B. ein Script schreiben müssen das erst den Provider Anpingt um die Verbindung auf zu machen, dann 5sec Pause macht und erst dann werden die Dienste startet. Ist zwar ne meiner Meinung nach unsaubere Methode aber es geht. Aber ne richtige Abhilfe ist das nicht.
On 15-Dec-99 Lars Mueller wrote:
Hallo Liste,
habe vor ein paar Tagen auf 6.3 umgestellt und habe seitdem (wie wohl jeder hier) ein paar kleine Probleme. Masquerading will ich erstmal nicht dikutieren. Viel mehr beschaeftig mich die Frage warum der Verbindungsaufbau offensichtlich 'irgendein' Routingproblem hat. Jedesmal wenn ich einen Verbindungsaufbau per WWW-Aufruf im Browser eines Clients initiiere wird zwar sofort eine Verbindung aufgebaut, ich bekomme auch sofort (nach ca. 1Sek) folgende Meldung:
Meine Erlaeterungen zu dem Problem stehen weiter oben, ich bitte um Vergebung, das ich die Gepflogenheiten nicht gewahrt habe. Ich bitte mal jeden, der dieses Problem hat, in der Datei /etc/resolv.conf unterhalb der Zeile nameserver eine weitere Zeile einzufuegen mit options debug Dadurch werden die Fehlermeldungen des Resolvers in die /var/log/messages geschrieben. Frage an SuSE: ist der Resolver von BIND8 mit DEBUG kompiliert worden ? Gruss Dieter
-- E-Mail: Dieter Kluenter
Date: 16-Dec-99 Time: 18:45:32 This message was sent by XFMail ----------------------------------
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
-- mfg Sascha Haupt **************************************************************** * _ _ _____ ____ ____ * * | \ |\ | | \ | | | | | |\ | | | / * * |_/ | \ | | \ __ | |__ | |___| | \ | | |_/ * * | \ | \ | | / | | | | | | \ | | | \ * * |_/ | \| |_/ | |____ |____ | | | \| | | \ * * * ****************************************************************
On 16-Dec-99 Sascha Haupt wrote:
Hi Dieter
Dieter Kluenter schrieb:
Hallo Lars, auch ich habe dieses Problem. An alle Mitleser die Bitte, jetzt keine Ratschlaege wie Nameserver aufsetzen, oder ip-up Regeln lesen usw. Das Problem liegt darin, dass eine Verbindung hergestellt wird, die dynamischen Adressen vergeben werden, die neue Adresse in die Routing Tabelle gewchrieben wird. Bevor diese neue Route gestzt wird, versucht der Resolver noch ueber die alte Adresse eine Verbindung herzustellen, was natuerlich nicht mehr funktioniert. Nach etwa 2-3 S ekunden, wenn naemlich der Resolver seinen zweiten Versuch startet, steht das Routing und die Verbindung kann hergestellt werden.
Ja das wird einem eigendlich in jedem Linux-Forum gesagt aber gibt es abhilfe? Ich hab f�r Sandmail z.B. ein Script schreiben m�ssen das erst den Provider Anpingt um die Verbindung auf zu machen, dann 5sec Pause macht und erst dann werden die Dienste startet. Ist zwar ne meiner Meinung nach unsaubere Methode aber es geht. Aber ne richtige Abhilfe ist das nicht.
Hallo Sascha,
da muss ich dir vollkommen Recht geben, aber eine andere Loesung habe
ich bisher auch nicht. Seit ueber zwei Wochen korrespondiere ich mict
support bei SuSE, aber konstruktive Beitraege leisten die auch nicht.
Gut, das kann ich verstehen, bei hunderten von support-Anfragen pro
Tag, da kann man nur noch in den Satzbaukasten greifen und Standard
Saetze uebermitteln. Nun, wir wollen sachlich bleiben.
Zur Zeit sehe ich mir die Quellen von named und von resolv an, es
muss doch moeglich, sein, Die Wartezeiten zu verlaengern, bevor die
Meldung 'network unreachabel' ausgeloest wird.
Gruss
Dieter
--
E-Mail: Dieter Kluenter
Dieter Kluenter wrote:
On 16-Dec-99 Sascha Haupt wrote:
Dieter Kluenter schrieb:
Das Problem liegt darin, dass eine Verbindung hergestellt wird, die dynamischen Adressen vergeben werden, die neue Adresse in die Routing Tabelle gewchrieben wird. Bevor diese neue Route gestzt wird, versucht der Resolver noch ueber die alte Adresse eine Verbindung herzustellen, was natuerlich nicht mehr funktioniert. Nach etwa 2-3 S ekunden, wenn naemlich der Resolver seinen zweiten Versuch startet, steht das Routing und die Verbindung kann hergestellt werden.
[...] Zur Zeit sehe ich mir die Quellen von named und von resolv an, es muss doch moeglich, sein, Die Wartezeiten zu verlaengern, bevor die Meldung 'network unreachabel' ausgeloest wird.
Eigentlich, denke ich, muesste der Loesungsansatz im ipppd liegen. Das Problem ist schlieszlich, dass zwischen Umsetzen der IP-Adresse INNERHALB des ipppd und dem Setzen der neuen Route AUSZERHALB des (i)pppd, naemlich im ip-up-Script, eine gewisse Zeit vergeht. Loesen laesst sich das nur, indem das IP-Adresse-Aendern und das Neue-Route-Setzen in einem Vorgang im Kernel zusammengefasst wird, so dass niemals ein anderer Prozess zwischen diese beiden Vor- gaenge gelangen kann. Leider stecke ich nicht so weit in den Details, dass ich mich haette ueberwinden koennen, mich durch die Quellen von ipppd und ppp-relevantem Kernel-Code zu wuehlen. Aber vielleicht koennen sich die Insider doch einmal dem Problem annehmen, obwohl ich befuerchte, die haben alle Standleitungen, und kennen das Problem gar nicht aus eigener Erfahrung... Jochen
participants (6)
-
Christian Schult
-
Dieter Kluenter
-
Frank Wagner
-
Jochen Roedenbeck
-
Lars Mueller
-
Sascha Haupt