Netscape & dial on demand

Thomas Ebenbichler wrote:

...

...

...

René Oelke 01/20/00 03:32am >>> Hi!

auch hai! ;-)

...

................................................ Wenn ich den ersten Request verschicke, bleibt mir der in der Leitung haengen. Bei einem Reload kommt dann die Antwort auch, weil dann die Verbindung schon hergestellt ist. Damit wuerde ich ja zurecht kommen. Allerdings will ich eigentlich nach recht kurzer Zeit <10s die Leitung unterbrechen, da ich ueber TelDaFax sekundengenau abgerechnet werde und es sich deshalb lohnt. Dann wird der Fehler doch ziemlich nervig.

...

a) wer kann mir helfen b) ich weiss zwar, dass das PRoblem bekannt ist, die Loesung finde ich nicht, weil ich keine Suchfunktion fuer diese Liste gefunden habe. Gibts also eine Suchmaschine fuer diese Liste?

zu a) ich leider nicht! :-( ich habe naemlich das gleiche problem (auch schon in dieser mailing-list gepostet), aber kein tip hat geholfen. der grund ist irgendwie bei den versendeten IP-paketen zu suchen. wenn man noch keine verbindung hat, wird (so wie es sein soll OnDemand) eine isdn-verbindung aufgebaut und die anfragen gehen wohl auch raus. nur die gesendeten antworten (html-seiten) erreichen nicht ihr ziel.

sieht bei mir jetzt gerade so aus, als ob es gelost sei. In meiner boot.local habe ich: echo 2 > /proc/sys/net/ipv4/ip_dynaddr eingefuegt. So wie ich das sehe, schaltet es den Kernel-Support fuer dyn.IP an. Damit funzts bei mir. Kann allerdings weder sagen, was jetzt genau passiert, noch dass es sicher passiert, da ich einfach nur die Mailingliste durchsucht habe und das eben mal kurz versucht habe. So wie ich kurz den Kernel gescannt habe, scheint er bei aktiviertem ip_dynaddr das paket nochmal zu schicken.

ich habe hier irgendwas von IP_DYNIP-PATCH gelesen (geht bis auf die ebene des kernels zurueck): in der /etc/rc.config gibt es eine variable IP_DYNIP, die wohl auf yes gesetzt werden muss. (schau mal in dieser mailingliste unter dem posting "AW: [suse-isdn] Kein weiterleiten der Packete auf neu gesetzte Route nach Verbindungsaufbau" nach!) aber, wie gesagt, bei mir funktionierte auch das nicht. da es mich weiterhin nicht stoert, mache ich immer ein reload der seitenach dem ersten mal. das ist nur nervig, wenn beim provider

gerade besetzt ist.

das bekommst du naemlich dann nicht mit.

Was ich in den alten Mailinglisten Beitraegen gefunden habe zu IP-DYNIP-PATCH hat sich noch auf Kernel Version ~ 2.0.30 bezogen. Inzwischen scheint der Patch im 2.2.14er drin zu sein. IP_DYNIP habe ich nicht in rc.config gesetzt, ich schaus mir nochmal an.

eine vielversprechende loesung waere wohl ein neuer kernel. die version 2.2.14 ist wohl die am meisten beliebteste (und aktuelle) hier. da soll dieses problem behoben sein. ich hatte noch keine zeit dazu. wenn du dich dafuer entschliesst, kannst de ja mal berichten.

tja, ich hab´s mit dem 2.2.14 Kernel probiert, allerdings ohne Erfolg. Beim Hochstarten kommt sogar die Meldung ´Enabling Dynamic IP

Patch - done´, aber trotzdem will´s nicht so richtig funktionieren!! Auch die Meldungen im /var/log/messages mit ´ip_shift_address´ bleiben aus.

Hat es sonst noch jemand mit der 2.2.14 Version probiert?????

Si, aber eben mit eintrag in boot.local und nicht in rc.config. s.o.

zu 2) www.deja.com ist ne echt gute adresse. ist zwar in englisch, aber du kannst auch in deutschen news suchen bzw. es werden auch deutsche ergebnisse angezeigt. man kann hier alles moegliche suchen und finden. kann ich nur empfehlen.

hat mir nicht gefallen. Habe schliesslich das komplette suse-isdn archiv per wget gezogen und dann per grep gesucht. Nicht unbedingt die elegante Methode, aber hat gefunzt. Kurze Zeiten zum ISDN-Abwaehlen (<10s) haben den Nachteil, dass lange dauernde Antworten von Web-Servern ev. den Weg zurueck nicht mehr finden: 1) request an Web-Server 2) t>10s kein Traffic 3) i4l haengt die LEitung ab 4) antwort kommt von Web-Server 5) Antwort kommt nicht mehr vom Provider zum i4l. Abhilfe: a) PRovider waehlt an (meiner leider nicht) b) nebenbei Traffic schaffen. ISt aber gegen meine Idee, mit einem timeout von 3 s bei sekundengenauer Abrechnung Gebuehren zu sparen.

danke, und noch ne menge spass mit linux!

no problem. rgds, Rainer