Dial on Demand

[Annette]

Hi!

Ich hab Suse Linux 7.3 Kernel 2.4 und wähle mich über T-DSL ins Internet ein. Der Linuxrechner dient als Router und ist vernetzt mit einem Windows-Rechner. Immer nach der ersten und auch nur nach der ersten Einwahl ins Internet tritt sowohl vom Server als auch vom Client folgendes Problem beim Pinging auf:


ping –c5 216.xx.xxx.xx
PING 216.xx.xxx.xx (2xx.xx.xxx.xx) from 192.168.99.1 : 56(84) bytes of data.
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument

Beim nächsten Ping ist wieder alles okay und die 192.168.99.1 ist durch die IP ersetzt, die mir dynamisch zugewiesen wurde.

Die IP der T-DSL Netzwerkkarte ist 192.168.22.1, die der internen Netzwerkarte 192.168.3.1, also weit und breit nichts zu sehen von 192.168.99.1.

Auf der Suche nach 192.168.99.1 habe ich herausgefunden, daß
sie die IP ist, die nach der Aktivierung von Dial on Demand in '/etc/ppp/peers/demand' eingetragen wurde.

/etc/ppp/peers/demand:

192.168.99.1:192.168.99.99

ipcp-accept-local
ipcp-accept-remote


Kann mir jemand sagen woran das liegt und ob und in was ich das ändern muß? Bitte um Hilfe.


Gruß,
Annette

[pitu]

mach bitte mal ein route -n nach dem verbindungsaufbau und schock das ergebniss her.

pitu

[Annette]

vor dem ersten ping:

route -n ------->

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.99.99 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.22.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.99.99 0.0.0.0 UG 0 0 0 ppp0


nach dem ersten ping:

route -n --------->

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
217.5.114.229 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.22.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.5.114.229 0.0.0.0 UG 0 0 0 ppp0


192.168.99.99 wurde also ersetzt durch die Adresse des Nameservers, der unter Dial on Demand von mir angegeben wurde.

Aber nochmal meine Frage: Warum wird 192.168.99.1:192.168,99.99 in '/etc/ppp/peers/demand' eingetragen?

Gruß,
Annette

[pitu]

Also, warum die 99.1, weil so nun mall das ppp0 device aufgesetzt wurde, dein thh-device ist vollkommen egal, auch welche adresse das hat. du kannst eben nicht zwei devices di gleiche adresse geben.

zu 2 ... mus ich noch ueberlegen, hate ich auch schon mal, aber da war das problem ein anderes (routen...)

pitu

[Annette]

Ok, warum ist eigentlich auch vollkommen wurscht. Wichtig ist nur, wie ich es anstelle, daß er gleich über die IP des Nameservers versucht ins Internet zu kommen und nicht über die 192.168.99.1.

Gruß,
Annette

[kberger]

Hallo Anette,
der pppd setzt bei der Einwahl die Adresse der ethx und das Routing neu. Anschliessend wird die vom Provider vergebene IP-Adresse für ethx verwendet.
Also kein Problem.

Beim zweiten ping sind erst die Werte richtig gesetzt und der Weg ins Internet frei. Das ist häufig ein Problem mit den Nameservern, die evtl etwas verzögern.

Hast Du eien Firewall installiert?
Hier könnte auch eine kleine Verzögerung eintreten (bei der Einwahl).

Gruß Klaus

[pitu]

Das problem ist ein anderes.

Wenn du einen ping auf die Adresse schickst, so ist in diesem Ping, sowie in jedem anderen TCP-Paket die ursprungsadresse mit drin. Da du den Ping aber losschickst, bevor die Verbindung steht, steht dort auch die private adresse dirn. bevor das paket zurueck kommt hat sich aber deine adresse geaendert. Das problem wird dadurch verschlimmert, dass Adressen aus dem privaten bereich nicht geroutet werden, ergo, du kriegst nie eine Antwort.

Wenn du nun abbrichst und wieder einen ping losschickst, dann wird das paket mit der aktuellen Adresse abgeschickt und kann daher zurueckkommen.

Fuer das Problem gibt es den sogenannten DYN-IP-Patch, bei SuSE gibt es in der rc.config dafuer die Variable IP_DYNIP in der rc.config, die du auf "yes" setzten solltest.

Ich vermute aber, das das schon pasiert ist und daher das Problem woanders liegt. Wenn nicht, setzt die Variable auf yes und boote neu.

Booten ist natuerlich eigentlich nicht notwendig, aber da ich gerade nicht die "echo" zeile im Kopf habe mit der man an den Kernel uebergibt, dass er das machen soll, und ich auch keine lust habe nachzuschauen, boote einfach neu.

pitu

[Annette]

Danke pitu. Hab IP_DYNIP auf yes gesetzt und jetzt funzt es. :) :) :)

Gruß,
Annette