Kai Gülzau wrote:

Hallo!

Bin dabei ein Linux-Rechner (Suse 6.2 mit 2.2.10) als ISDN-Internet-Gateway einzurichten. Ich teste jetzt seit 1-2 Tagen den Zugang erstmal lokal...und dabei sind ein paar Unklarheiten aufgetaucht...

Ich mache ein telnet auf z.B. 141.22.10.10 (FH-HH) ...wegen DoD wird dann ne Verbindung aufgebaut...wunderbar!

Nach dem timeout (60sec.) wird die Verbindung wieder getrennt. Versuche ich aber das noch offene telnet wieder zu benutzen wird eine neue Anfrage mit der alten Dyn. IP auf die 141.22.10.10 gemacht...von dort kommt anscheinend nix zurück und telnet hängt und warten und schickt regelmäßig die gleiche Anfrage, selbst wennn der Prozess gekillt wird.

Ich dachte das Problem ist mit dem RST-provoking mode gelöst, der ja in Suse 6.2 mit IP_DYNIP=yes aktiviert werden soll.

Der RST-provoking Patch hält das erste Paket zurück, bis Du die dyn. IP bekommen hast, da sonst das erste Paket verloren geht.

Wie kann ich überprüfen, ob der wirklich aktiviert wurde!?

cat /proc/sys/net/ipv4/ip_dynaddr, der Wert sollte größer als 0 sein.

Wäre gut, wenn das Problem lösbar wäre...schließlich soll der Rechner wirklich mal alleine im Keller stehen und keinen Gebühren-GAU verursachen ;)

Für Verbindungen, die über den Router maskiert werden, gibts da ein kleines Programm, daß die beim Verbindungsabbau noch aktiven Verbindungen per Firewall geblockt werden. Such mal in der SDB nach "dynamisch".

route -n (offline): 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ipp0 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ipp0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UH 0 0 0 ipp0

Da ist wohl ein Eintrag in der /etc/route.conf doppelt. Gruß Thomas -- Marciniak Online Service fon: (0231) 58 90 154 Thomas Marciniak fax: (0231) 58 90 155 Schachtstrasse 1 http://www.marciniak.de 44149 Dortmund e-mail: tmarcin@marciniak.de

On Thu, Sep 30, 1999 at 11:58 +0200, Kai Gülzau wrote:

Ich mache ein telnet auf z.B. 141.22.10.10 (FH-HH) ...wegen DoD wird dann ne Verbindung aufgebaut...wunderbar!

Nach dem timeout (60sec.) wird die Verbindung wieder getrennt. Versuche ich aber das noch offene telnet wieder zu benutzen wird eine neue Anfrage mit der alten Dyn. IP auf die 141.22.10.10 gemacht...von dort kommt anscheinend nix zurück und telnet hängt und warten und schickt regelmäßig die gleiche Anfrage, selbst wennn der Prozess gekillt wird.

Was Du willst, ist eine telnet Session mit der einen IP aufzubauen und mit einer anderen fortzusetzen. Das gibt das Protokoll einfach nicht her. Du kannst - telnet (den Server und den Client) so bearbeiten, dass ein Adresswechsel "verhandelt" und beachtet wird oder - Dich nach Alternativen umsehen, die mit ueber die (logische) Verbindungsdauer wechselnden Adressen klarkommen Ich kenne weder zum einen noch zum anderen Punkt eine Loesung (wenn Du noch die alte IP hast und die Daten fliessen, weisst Du nicht welche IP Du spaeter kriegen wirst; und wenn Du die neue IP hast, kannst Du keine Daten mehr mit der alten transportieren, um der Gegenstelle von der neuen IP zu berichten). Vielleicht hilft Dir ein Blick auf screen(1) weiter. Ich kenne und benutze es zwar nicht, aber IIRC kann es Sitzungen "wieder aufnehmen". Ob das mit dynip klappt, weiss ich nicht. Oder Du suchst Dir einen Provider mit statischen Adressen oder derart ertraeglichen Preisen, dass Du die Verbindung offenhalten kannst. Und Du willst mit Sicherheit nicht sowas wie telnet benutzen, wenn Du ueber das Telefonnetz gehst (erzaehlen die Dir sowas nicht, wenn Du ein Login im URZ kriegst?). Nimm ssh(1) oder sowas.

Wäre gut, wenn das Problem lösbar wäre...schließlich soll der Rechner wirklich mal alleine im Keller stehen und keinen Gebühren-GAU verursachen ;)

Das ist ein komplett anderes Thema, dass man mit dem Ungueltigkeitwerden der alten dynamischen IP (also beim Auflegen) die entsprechenden Pakete unterdrueckt. Loesungen dafuer hast Du hier gekriegt und findest die auch tausendfach in der SDB und DeJaNews (de.alt.comm.isdn4linux). virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.