Hi! Ich habe hier eine SuSE 7.0 (Kernel 2.2.16) als ISDN-Dial-on-Demand-Router mit Masquerading und SuSEfirewall laufen. Klappt soweit auch ziemlich gut. Wenn ich aber von meiner Windows-Kiste mit Outlook ein POP3-Postfach abfragen will, und die ISDN-Verbindung steht gerade nicht, kriege ich einen Timeout. Wenn ich's dann gleich nochmal probiere, geht's. Mir fallen zwei mögliche Gründe dafür ein, und zu beiden habe ich 'ne Frage. a) der POP3-Request (oder vielleicht sogar die DNS-Anfrage für den POP3-Server kurz davor?) geht verloren. Kann das sein? Wenn ja - was kann man dagegen tun? b) der Router ist ein alter 486DX2/66. Das Script ip-up braucht ewig - ungefähr 16 Sekunden. Könnte das Problem ein schlichter Time-Out sein? Die Fehlermeldung von Outlook kommt allerdings erst etliche Sekunden, nachdem das Script fertig ist. Die allermeiste Zeit geht in ip-up für SuSEfirewall drauf. Frage: gibt es eine Möglichkeit, SuSEfirewall nicht in ip-up, sondern einmal beim Booten laufen zu lassen? Der Versuch, es bei ip-up einfach rauszunehmen (natürlich auch für ip-down) und vorher "zu Fuß" aufzurufen, hat nicht funktioniert. Ganz so einfach isses also wohl nicht. Kann mir jemand helfen? Falls SuSEfirewall unbedingt in ip-up laufen muss - kann man Teile davon auslagern? Ich meine, müssen z.B. die ip_masq-Module wirklich jedesmal neu geladen werden? Welche Teile brauchen eigentlich die meiste Zeit? Ich fürchte ja fast, es verteilt sich ziemlich gleichmäßig über das Skript... Vielen Dank im Voraus Daniel
Hi, * On Sunday, February 18, 2001 at 01:09, Daniel Schroeder wrote:
Ich habe hier eine SuSE 7.0 (Kernel 2.2.16) als ISDN-Dial-on-Demand-Router mit Masquerading und SuSEfirewall laufen.
Klappt soweit auch ziemlich gut. Wenn ich aber von meiner Windows-Kiste mit Outlook ein POP3-Postfach abfragen will, und die ISDN-Verbindung steht gerade nicht, kriege ich einen Timeout. Wenn ich's dann gleich nochmal probiere, geht's. Mir fallen zwei mögliche Gründe dafür ein, und zu beiden habe ich 'ne Frage.
a) der POP3-Request (oder vielleicht sogar die DNS-Anfrage für den POP3-Server kurz davor?) geht verloren. Kann das sein? Wenn ja - was kann man dagegen tun?
Ist der RST-provoking mode aktiviert? Was liefert cat /proc/sys/net/ipv4/ip_dynaddr für eine Ausgabe? Beim Verbindungsaufbau müssten in /var/log/messages ungefähr solche Meldungen kommen: ip_rewrite_addrs(): shifting saddr from 1.1.1.1 to 149.228.142.50 (state 2) Adalbert
hi!
Ist der RST-provoking mode aktiviert? Was liefert cat /proc/sys/net/ipv4/ip_dynaddr für eine Ausgabe?
Das liefert eine 7. Aber:
Beim Verbindungsaufbau müssten in /var/log/messages ungefähr solche Meldungen kommen: ip_rewrite_addrs(): shifting saddr from 1.1.1.1 to 149.228.142.50 (state 2)
Da ist das ähnlichste, was ich finden kann, ein: kernel: IP_MASQ:ip_fw_masquerade(): change masq.addr from 192.168.250 to 62.158.202.21 Meinst Du das? Oder ist das was ganz anderes? Ich habe, wie gesagt, eine SuSE 7.0 mit Kernel 2.2.16. Cheers Daniel
Daniel Schroeder wrote:
..
Meinst Du das? Oder ist das was ganz anderes? Ich habe, wie gesagt, eine SuSE 7.0 mit Kernel 2.2.16.
Hallo! Welchen DNS nutzt du? Ich hab auch 7.0 & 2.2.16. Wenn ich bind4 nehme, "vergisst" er auch die erste Anfrage (egal ob pop, http,...), mit bind8 hab ich das Problem nicht. Noch 'ne andere Vermutung: Vielleicht ist dein Provider zulangsam (in der Anmeldung). (Ich wähl mich über die Hochschule ein) Bei dem Server von einem Kumpel mit Suse 6.3 über t-online funktioniert es trotz Patch und bind8 nicht. Ralf
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
participants (4)
-
Adalbert Michelic
-
Daniel Schroeder
-
Michael Mock
-
Ralf Lieb