Tach Ihr, seit ich Linux, DoD und DynIP kenne plagt mich eine Sache: Bei einem Verbindungaufbau via DoD gehen die ersten Pakete noch mit der vorkonfigurierten Sourceadresse des Inteerfaces raus. Erst nach ca. 3 Paketen tragen selbige die vom Provider zugeordnete. Jetzt erscheint auch die shifting-Meldung im Kernel-Log. Lässt sich mit "tcpdump -i ipppX -nqtl" und einem "ping 141.1.1.1" auf andere Konsole recht einfach feststellen. Setzt man nun den bind als Nameserver ein, verursachen die die NS-Pakete den DoD. (wenn nicht im Cache) Die fehlenden Pakete verursachen den bind8.1.2 erst mal 60s zu ruhen und die Clientanwendung hängen zu lassen. Mein Netscap ist das besonders anfällig und hängt dann für 60s. Trage ich nun in named.conf 20 mal den selben forward NS ein, geht es bereits nach 3s weiter. D.h der named schaltet auf den nächsten NS, die Verbindung ist ordentlich etabliert und mein Netscape bekommt nach 3s seine Antwort vom Bind. Mit neueren Bind-Versionen (bind9.x) läuft das ganze auch ohne 20 Forward-NS. Das eigentliche Problem sind aber die ersten paar Pakete. Um der Sache auf den Grund zu gehen habe folgendes unternommen: - SuSE 6.3 Default-Installation hochgezogen und mich dem SuSE-Support anvertraut. Antwort: echo "7" > /proc.. - Mandrake 7.1 installiert. - LinuxFromScratch (www.linuxfromscratch.org) hochgezogen, neuste i4l-utils - Einen Cisco als Dialin-Server besorgt, um TOnline zu entlasten. - Kernel 2.4.1 installiert. - Diverse ISDN-Karten, und verschiedenen Rechner (586, P3). - pppd mit rp-pppoe für ADSL Ich habe es noch nicht geschafft, dass mein System die Pakete zurückhält, bis die dyn.IP des Providers meinem Interface zugeordnet ist. In diversen Mailinglisten wurde die Problematik zur genüge diskutiert, jedoch ohne eine zufriedenstellende Lösung. Für ältere Kernelversionen gibt es einen Kernelpatch von Michael Müller, aber mit 2.0.x will ich auch nicht mehr anfangen und den Inhalt des Patches verstehe ich nicht. In der iptables Liste wurde der Fehler reportet, mit der Antwort, dass der Fehler an die Kernelentwickler weitergegeben wird. Vielleich hat ja noch jemand 'ne Idee oder gar ein Kernelimage, bei dem selbiges Problem nicht auftritt. Oder bin jetzt mit meinem Problem an die Grenzen der freien Softwareentwicklung gestoßen? Horrido Michael