dyn. IP, i4l: shifting saddr from ... to ... geht nicht.
Hallo Leute, "shifting saddr from %s to ..." geht hier nicht und wird auch nicht in /var/log/messages angezeigt. Das in einigen Quellen beschriebene Verhalten, dasz das erste Paket bei einem Verbindungsaufbau wg. nicht angepaszter IPs verloren geht bzw. falsch gehandhabt wird, tritt hier wohl auch auf, obwohl ich echo 7 > /proc/sys/net/ipv4/ip_dynaddr, in /etc/sysconfig/sysctl: IP_DYNIP=yes, echo 1 > /proc/sys/net/ipv4/ip_forward gesetzt habe. Der automatische Verbindungsaufbau funktioniert, sobald ich z.B. ein ping auf einen host auszerhalb meines privaten Netzes absetze; ist in .../messages gut zu verfolgen (ebenso der Verbindungsabbau nach einiger Zeit Inaktivitaet). Nach dem (oder waehrend? des) Verdingusaufbau(s) erhalte ich die Meldung "ping: sendmsg: Network unreachable". Wenn ich den ersten ping noch einmal absetze funktioniert alles, wie man es erwartet. Es fehlt allerdings die besagte Meldung in .../messages: ip_rewrite_addrs(): shifting saddr from ... to ... Mir scheint es, dasz die route im ersten Moment nicht richtig gesetzt ist ("Network unreachable"), aber gerade das sollen doch die o.a. Masznahmen beseitigen!? Irgendwie komme ich nicht so recht weiter; vielleicht weisz jemand Rat. SuSE 8.0 2.4.18-4GB i586 -- Gruesze Michael e-mail: Michael.Gens@TU-Berlin.DE
On Fri, Sep 27, 2002 at 12:04:01PM +0200, Michael Gens wrote:
Hallo Leute,
"shifting saddr from %s to ..." geht hier nicht und wird auch nicht in /var/log/messages angezeigt.
Das in einigen Quellen beschriebene Verhalten, dasz das erste Paket bei einem Verbindungsaufbau wg. nicht angepaszter IPs verloren geht bzw. falsch gehandhabt wird, tritt hier wohl auch auf, obwohl ich
echo 7 > /proc/sys/net/ipv4/ip_dynaddr,
in /etc/sysconfig/sysctl: IP_DYNIP=yes,
echo 1 > /proc/sys/net/ipv4/ip_forward
gesetzt habe.
Der automatische Verbindungsaufbau funktioniert, sobald ich z.B. ein ping auf einen host auszerhalb meines privaten Netzes absetze; ist in .../messages gut zu verfolgen (ebenso der Verbindungsabbau nach einiger Zeit Inaktivitaet).
Nach dem (oder waehrend? des) Verdingusaufbau(s) erhalte ich die Meldung "ping: sendmsg: Network unreachable".
Wenn ich den ersten ping noch einmal absetze funktioniert alles, wie man es erwartet.
Es fehlt allerdings die besagte Meldung in .../messages: ip_rewrite_addrs(): shifting saddr from ... to ...
Mir scheint es, dasz die route im ersten Moment nicht richtig gesetzt ist ("Network unreachable"), aber gerade das sollen doch die o.a. Masznahmen beseitigen!?
Nur bei tcp Verbindungen, nicht bei udp.
Irgendwie komme ich nicht so recht weiter; vielleicht weisz jemand Rat.
Meistens erfolgt die Anwahl durch ein udp packet (nameserver Abfrage). Leider sind die fest eigestellten timeouts (glibc) fuer eine Einwahl zu einen zu niedrig zum anderen ist das Ganze nicht fuer dynamische IPs die sich waehrend der Anfrage aendern gedacht. Helfen kann hier eventuell mindestens 2 Nameserver (oder einen 2*) in die resolve.conf einzutragen. -- Karsten Keil SuSE Labs ISDN development
Karsten Keil wrote:
On Fri, Sep 27, 2002 at 12:04:01PM +0200, Michael Gens wrote:
Hallo Leute,
"shifting saddr from %s to ..." geht hier nicht und wird auch nicht in /var/log/messages angezeigt.
Das in einigen Quellen beschriebene Verhalten, dasz das erste Paket bei einem Verbindungsaufbau wg. nicht angepaszter IPs verloren geht bzw. falsch gehandhabt wird, tritt hier wohl auch auf, obwohl ich
echo 7 > /proc/sys/net/ipv4/ip_dynaddr,
in /etc/sysconfig/sysctl: IP_DYNIP=yes,
echo 1 > /proc/sys/net/ipv4/ip_forward
gesetzt habe.
Der automatische Verbindungsaufbau funktioniert, sobald ich z.B. ein ping auf einen host auszerhalb meines privaten Netzes absetze; ist in .../messages gut zu verfolgen (ebenso der Verbindungsabbau nach einiger Zeit Inaktivitaet).
Nach dem (oder waehrend? des) Verdingusaufbau(s) erhalte ich die Meldung "ping: sendmsg: Network unreachable".
Wenn ich den ersten ping noch einmal absetze funktioniert alles, wie man es erwartet.
Es fehlt allerdings die besagte Meldung in .../messages: ip_rewrite_addrs(): shifting saddr from ... to ...
Mir scheint es, dasz die route im ersten Moment nicht richtig gesetzt ist ("Network unreachable"), aber gerade das sollen doch die o.a. Masznahmen beseitigen!?
Nur bei tcp Verbindungen, nicht bei udp.
Irgendwie komme ich nicht so recht weiter; vielleicht weisz jemand Rat.
Meistens erfolgt die Anwahl durch ein udp packet (nameserver Abfrage). Leider sind die fest eigestellten timeouts (glibc) fuer eine Einwahl zu einen zu niedrig zum anderen ist das Ganze nicht fuer dynamische IPs die sich waehrend der Anfrage aendern gedacht. Helfen kann hier eventuell mindestens 2 Nameserver (oder einen 2*) in die resolve.conf einzutragen.
-- Karsten Keil SuSE Labs ISDN development
-- 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 Karsten! In der /etc/resolv.conf stehen bereits 2 (sogar verschiedene) Nameserver des providers; habe ich extra nachgesehen. Zwischenzeitlich habe ich gehört, dasz es bei früheren Kernels funktioniert haben soll. Kann das zur Lösungsfindung beitragen? Denn so wie das jetzt arbeitet, ist die von mir aufgebaute Linux-Maschine nicht als dailout-server geeignet. Habe z.Zt. einen 2.4.18-4GB im Einsatz und würde ungerne downgraden (z.B. möchte ich gerne iptables weiterverwenden). -- Mit freundlichen Grueszen Michael Gens Tel: 030 314 26965 Fax: 030 314 24160 e-mail: Michael.Gens@TU-Berlin.DE
On Fri, Oct 04, 2002 at 08:02:09AM +0200, Michael Gens wrote:
In der /etc/resolv.conf stehen bereits 2 (sogar verschiedene) Nameserver des providers; habe ich extra nachgesehen.
Zwischenzeitlich habe ich gehört, dasz es bei früheren Kernels funktioniert haben soll. Kann das zur Lösungsfindung beitragen? Denn so wie das jetzt arbeitet, ist die von mir aufgebaute Linux-Maschine nicht als dailout-server geeignet.
Habe z.Zt. einen 2.4.18-4GB im Einsatz und würde ungerne downgraden (z.B. möchte ich gerne iptables weiterverwenden).
Probiermal andere dummy Adressen als "0.0.0.0" zu verwenden (z.B 192.168.1.1 und 192.168.1.2). Am einfachsten direkt /etc/sysconfig/isdn/cfg-net0 editieren und anschliessend SuSEconfig --module isdn aufrufen, dann ein rcnetwork restart -o type=ippp -- Karsten Keil SuSE Labs ISDN development
Karsten Keil wrote:
On Fri, Oct 04, 2002 at 08:02:09AM +0200, Michael Gens wrote:
In der /etc/resolv.conf stehen bereits 2 (sogar verschiedene) Nameserver des providers; habe ich extra nachgesehen.
Zwischenzeitlich habe ich gehört, dasz es bei früheren Kernels funktioniert haben soll. Kann das zur Lösungsfindung beitragen? Denn so wie das jetzt arbeitet, ist die von mir aufgebaute Linux-Maschine nicht als dailout-server geeignet.
Habe z.Zt. einen 2.4.18-4GB im Einsatz und würde ungerne downgraden (z.B. möchte ich gerne iptables weiterverwenden).
Probiermal andere dummy Adressen als "0.0.0.0" zu verwenden (z.B 192.168.1.1 und 192.168.1.2). Am einfachsten direkt /etc/sysconfig/isdn/cfg-net0 editieren und anschliessend SuSEconfig --module isdn aufrufen, dann ein
rcnetwork restart -o type=ippp
-- Karsten Keil SuSE Labs ISDN development
-- 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 Karsten!
Antwort nach einem ping
From <IP>: icmp_seq=7 Destination Host Unreachable From <IP>: icmp_seq=7 Destination Host Unreachable From <IP>: icmp_seq=8 Destination Host Unreachable From <IP>: icmp_seq=9 Destination Host Unreachable
23 packets transmitted, 0 received + 4 errors, 100% loss, time 22070ms
icmp_seq=1...6 wurde nicht ausgegeben, dafür icmp_seq=7 doppelt.
Hat das was mit dem Verbindungsaufbau zu tun?
Das o.a. Verhalten ist allerdings instabil, machmal auch
folgende Ausgabe:
ping: sendmsg: Network is down.
Oder es wird auch sehr viel Zeit benötigt, um das GW zu setzen
(überwacht mit route -n).
Auch das ist vorgefallen:
GW ist recht zügig gesetzt worden (lt. route -n), aber
ping reagiert überhaupt nicht; d.h. es steht nur der Befehl
ping
Karsten Keil wrote:
On Fri, Oct 04, 2002 at 08:02:09AM +0200, Michael Gens wrote:
In der /etc/resolv.conf stehen bereits 2 (sogar verschiedene) Nameserver des providers; habe ich extra nachgesehen.
Zwischenzeitlich habe ich gehört, dasz es bei früheren Kernels funktioniert haben soll. Kann das zur Lösungsfindung beitragen? Denn so wie das jetzt arbeitet, ist die von mir aufgebaute Linux-Maschine nicht als dailout-server geeignet.
Habe z.Zt. einen 2.4.18-4GB im Einsatz und würde ungerne downgraden (z.B. möchte ich gerne iptables weiterverwenden).
Probiermal andere dummy Adressen als "0.0.0.0" zu verwenden (z.B 192.168.1.1 und 192.168.1.2). Am einfachsten direkt /etc/sysconfig/isdn/cfg-net0 editieren und anschliessend SuSEconfig --module isdn aufrufen, dann ein
rcnetwork restart -o type=ippp
-- Karsten Keil SuSE Labs ISDN development
-- 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 Karsten!
Antwort nach einem ping
From <IP>: icmp_seq=7 Destination Host Unreachable From <IP>: icmp_seq=7 Destination Host Unreachable From <IP>: icmp_seq=8 Destination Host Unreachable From <IP>: icmp_seq=9 Destination Host Unreachable
23 packets transmitted, 0 received + 4 errors, 100% loss, time 22070ms
icmp_seq=1...6 wurde nicht ausgegeben, dafür icmp_seq=7 doppelt.
Hat das was mit dem Verbindungsaufbau zu tun?
Das o.a. Verhalten ist allerdings instabil, machmal auch
folgende Ausgabe:
ping: sendmsg: Network is down.
Oder es wird auch sehr viel Zeit benötigt, um das GW zu setzen
(überwacht mit route -n).
Auch das ist vorgefallen:
GW ist recht zügig gesetzt worden (lt. route -n), aber
ping reagiert überhaupt nicht; d.h. es steht nur der Befehl
ping
participants (2)
-
Karsten Keil -
Michael Gens