[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-isdn
Subject:    Re: [suse-isdn] Netscape & dial on demand
From:       "Rainer Koch" <koch () kapp-coburg ! de>
Date:       2000-01-31 6:47:15
[Download RAW message or body]

>On Sat, Jan 29, 2000 at 09:52 +0100, Dieter Kluenter wrote:
>>
>> das ist mir schon klar, trotzdem gehen die ersten Pakete verloren.
>>
>> dkluenter@pink:~ > ping -c 5 news.cis.dfn.de
>> PING news.cis.dfn.de (130.133.1.4): 56 data bytes
>> ping: sendto: Das Netzwerk ist nicht erreichbar
>> ping: wrote news.cis.dfn.de 64 chars, ret=-1
>> 64 bytes from 130.133.1.4: icmp_seq=3 ttl=247 time=94.749 ms
>> 64 bytes from 130.133.1.4: icmp_seq=4 ttl=247 time=91.735 ms
>
>Nein, sie kommen nur nicht schnell genug raus bzw die Antworten
>kommen nicht schnell genug.  Mehr kannst Du mit einem ping IMO
>nicht "nachweisen".  Dass dazwischen "network unreachable" kommt,
>hat mit dem Routen-Umstellen in /etc/ppp/ip-up zu tun und ist ein
>voellig anderen Problem.

Kann man IMHO so nicht sagen - auf einer Verbindung mit festen IP-
Adressen (RAW IP) kommen auch alle Pakete zurück, egal wie lange
der Verbindungsaufbau dauert. IMO sollte sich auch eine dyn IP-Ver-
bindung genauso benehmen, d.h. die Pakete solange zurückhalten
bis die Verbindung steht, dann die (mitlerweile geänderte) IP-Adresse
des sendenden Interfaces in den Paketen eintragen und schliesslich
die Pakete versenden... Genau das sollte der dyn_ip-Patch eigentlich
auch tun. Meldungen wie "shifting ..." im log kommen aber mit viel
Verspätung (so zwischen 3 und 15 Sekunden !), dann funktioniert
die Verbindung aber auch plötzlich, oder auch  gar nicht. Kann es
sein, das das shifting erst vom nächsten eintreffenden Paket ausgelöst
wird ??

Die Ergebnisse da oben (sind identisch mit denen, die auch ich habe)
zeigen aber ein ganz anderes Verhalten:
1. Paket wird auf das Interface geroutet, löst Dial on Demand aus, wird
   verschickt (mit geänderter Absender-Adresse ?) (an wen eigentlich -
   an das richtige Gateway ? Kann sich ja auch geändert haben !)
2. Paket wird verworfen, da zwischenzeitlich durch die Neuinitialisierung
    des Interfaces die routen gelöscht wurden, die neuen im ip-up aber
    noch nicht gesetzt wurden (timing !)
3. Paket - ??? Paket : Interface und routes stehen - alles OK

So - und wie verhindern wir jetzt (1) und (2) ???? Der dyn_ip patch tut es
auf jeden Fall nicht - zumindest gegen (2) kann er IMHO nichts machen.
Ich kann mich entsinnen, das im Patch ein Kommentar in der Art
"funktionert nur mit SLIP und (async) PPP" stand (oder noch steht).
Könnte das was damit zu tun haben, das da ein user-level Programm mit
dem Verbindungsaufbau zu tun hat, während bei ISDN ja alles im Kernel
abläuft (just guessing) ??

MfG
Rainer Koch.



[prev in list] [next in list] [prev in thread] [next in thread]