AW: [suse-isdn] Kein weiterleiten der Packete auf neu gesetzte Ro ute nach Verbindungsaufbau
Hi Rene, zunächst ein Dank für ein solch tolles und präzises Posting. Da macht Anworten Spaß. :-) Zu Frage 1: Bitte prüfe, ob in /etc/rc.config IP_DYNIP=YES gesetzt ist. Ansonsten z.B. mit YAST setzen, damit bei DoD und dynamischer IP-Vergabe das erste Paket nicht verloren geht. Zu Frage 2: Meines Wissens in Deiner derzeitigen Architektur nicht, da Squid direkt den DNS des Providers befragt und die notwendigen Infos im Provider-Log stehen. Daher die Empfehlung, einen Caching-Only NS bei Dir aufzusetzen. Dann kannst Du die Anfragen der Clients in /var/log/messages protokollieren lassen, wenn Du in /etc/named.boot die Option query-log setzt. Das "wer" und das "wann" bekommst Du so heraus. Das "wie lange" vermutlich aber nicht. Zu Frage 3: Die Default-Route verweist auf das Gateway, über das alle anderen Hosts potentiell erreichbar sind, die nicht im eigenen LAN liegen. Als Gateway trägst Du auf den Clients Deinen Proxy ein (wichtig, damit Dein zukünftiges Masquerading routingtechnisch klappt). Als Gateway auf dem Proxy trägst Du den Einwahlrechner Deines ISP ein bzw. eine IP aus einem anderen Netz, da diese bei DoD durch die ip-up / -down Scripte eh umgesetzt wird. Bei einer reinen Proxy-Architektur könntest Du auf ein Eintragen des Gateways auf den Clients sogar verzichten, da sich bei Dir Clients und Proxy im selben Netz befinden. Gruß Axel
-----Ursprüngliche Nachricht----- Von: René Oelke [mailto:r.oelke@jpsc.de] Gesendet am: Mittwoch, 12. Januar 2000 12:04 An: SuSE ISDN-Mailinglist Betreff: [suse-isdn] Kein weiterleiten der Packete auf neu gesetzte Route nach Verbindungsaufbau
hi, folks!
obiges problem soll zunächst noch einmal näher beschrieben werden.
konfiguration:
linux suse6.3 mit allen isdn-tools proxy: squid KEIN masquerading!!! isdn-karte - USR Sportster... netzwerkkarte - NE2000 kompat. IP -> linux-rechner: eth0 192.168.10.1 (ippp0 141.45.225.75) IP -> win95-rechner: Nr.1 192.168.10.2 Nr.2 192.168.10.3 Nr.3 192.168.10.4 Netmask - 255.255.255.0 Netscape (win95) geht über proxy: 192.168.10.1
datei - /etc/resolve.conf - --- schnipp --- hosts,bind (oder so ähnlich) nameserver 141.45.1.1 nameserver 141.45.100.5 --- schnapp ---
datei - /etc/route.conf - --- schnipp --- 192.168.10.1 0.0.0.0 255.255.255.0 eth0 // ne2000-karte 141.45.1.1 0.0.0.0 255.255.255.255 ippp0 // isdn-karte default 141.45.1.1 // 1. name-server des ISP --- schnapp ---
die isdn-verbindung klappt soweit. gebe ich eine fremde ip-adresse oder www-adresse in netscape (auf win95-rechnerX) ein, so wird die isdn-karte angesprochen und die verbindung aufgebaut.
PROBLEM: jedoch erscheint die html-seite nicht sofort im browser. erst, wenn ich die suche stoppe (ESC) und die adresse noch einmal eingebe (einfach wieder ENTER), dann kommt der html-text. ich vermute, daß die neu route (über ippp0) zwar gesetzt ist, aber die datenpakete beim ersten mal (also direkt nach dem verbindungsaufbau) nicht über diese gesendet werden. ich weiß dann imer nicht, ob die verbindung tatsächlich geklappt hat oder nicht. ich muß manchmal die suche mehrmals neu starten (ESC -> ENTER), da u.U. beim ISP besetzt ist.
FRAGE 1: wie schaffe ich es, daß auch gleich nach dem ersten eingeben der www-seite, deren inhalt bei erfolgreichem verbindungsaufbau angezeigt wird? (wenn dies dann nach einer weile nicht geschieht, weiß ich, daß u.U. ständig besetzt ist)
FRAGE 2: wo kann ich sehen (im proxy oder isdnctrl), welcher win95-rechner den eigentlichen verbindungsaufbau angestoßen hat? (also dessen IP) ich will die einzelnen verbindungszeiten mitprotokollieren (wer, wann, wie lange).
FRAGE 3: warum geht die default-route über ippp0? ich will diese default im eigenen netz haben (eth0). ich habe schon default 192.168.10.1 eingetragen, doch da kam beim starten des rechners eine fehlermeldung (irgendwas mit httpd ???)
danke im voraus!!!
tschö, rene
ps: ich stelle bald auf masquerading um und hörte, daß es probleme mit suse6.3 gibt oder auch nicht. wie ist der stand der dinge? was sollte ich beachten?
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com
Hallo Liste, da ich in letzter Zeit immer mal wieder in unterschiedlichen Zusammenhängen die Frage gelesen habe, warum die erste Seite nach einem Verbindungsaufbau nicht kommt, und darauf auch immer wieder die völlig richtige Antwort gelesen habe, auf jeden Fall IP_DYNIP=YES zu setzen (wurde früher mal als dynip-Patch bezeichnet), wollte ich auch mal meine Erfahrung hier weitergeben, nämlich: Der IP_DYNIP=YES Schalter funktionierte bei mir mit dem 2.2.13 Kernel NICHT. Ich habe das Problem nach der Umstellung auf SuSE 6.3 gehabt; in der SuSE Version ist 2.2.13 standardmäßig eingerichtet. Anscheinend wurde im IPV4 Code des Kernels noch etwas hinzugefügt, dass meiner Meinung nach das offene-Socket-Problem lösen soll. Diese Änderung bewirkt in /var/log/messages Meldungen mit dem Schlüsselwort »zapping«. Die bekannten, durch IP_DYNIP=YES bewirkten, Meldungen mit dem Schlüsselwort »ip_shift_addr« (oder so ähnlich) traten allerdings nicht mehr auf. Ich schließe daraus, dass die Änderungen in 2.2.13 dazu geführt haben, dass nach der dynamischen IP-Zuweisung das erste TCP-Paket als ungültig markiert und verworfen wird, bevor der IP_DYNIP Patch seine Wirkung zeigen kann. Seit einigen Tagen ist der Kernel 2.2.14 verfügbar, der nach meinen bisherigen Erfahrungen die beschriebenen Probleme nicht hat. Ich hoffe, das hilft weiter. Gruß Christoph
>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 13.01.00, 08:26:06, schrieb "Burghardt, Axel"
Hi Rene,
zunächst ein Dank für ein solch tolles und präzises Posting. Da macht Anworten Spaß. :-)
Zu Frage 1:
Bitte prüfe, ob in /etc/rc.config IP_DYNIP=YES gesetzt ist. Ansonsten z.B. mit YAST setzen, damit bei DoD und dynamischer IP-Vergabe das erste Paket nicht verloren geht.
Zu Frage 2:
Meines Wissens in Deiner derzeitigen Architektur nicht, da Squid direkt den DNS des Providers befragt und die notwendigen Infos im Provider-Log stehen. Daher die Empfehlung, einen Caching-Only NS bei Dir aufzusetzen.
Dann kannst Du die Anfragen der Clients in /var/log/messages protokollieren lassen, wenn Du in /etc/named.boot die Option query-log setzt. Das "wer" und das "wann" bekommst Du so heraus. Das "wie lange" vermutlich aber nicht.
Zu Frage 3:
Die Default-Route verweist auf das Gateway, über das alle anderen Hosts potentiell erreichbar sind, die nicht im eigenen LAN liegen. Als Gateway trägst Du auf den Clients Deinen Proxy ein (wichtig, damit Dein zukünftiges Masquerading routingtechnisch klappt). Als Gateway auf dem Proxy trägst Du den Einwahlrechner Deines ISP ein bzw. eine IP aus einem anderen Netz, da diese bei DoD durch die ip-up / -down Scripte eh umgesetzt wird.
Bei einer reinen Proxy-Architektur könntest Du auf ein Eintragen des Gateways auf den Clients sogar verzichten, da sich bei Dir Clients und Proxy im selben Netz befinden.
Gruß Axel
-----Ursprüngliche Nachricht----- Von: René Oelke [mailto:r.oelke@jpsc.de] Gesendet am: Mittwoch, 12. Januar 2000 12:04 An: SuSE ISDN-Mailinglist Betreff: [suse-isdn] Kein weiterleiten der Packete auf neu gesetzte Route nach Verbindungsaufbau
hi, folks!
obiges problem soll zunächst noch einmal näher beschrieben werden.
konfiguration:
linux suse6.3 mit allen isdn-tools proxy: squid KEIN masquerading!!! isdn-karte - USR Sportster... netzwerkkarte - NE2000 kompat. IP -> linux-rechner: eth0 192.168.10.1 (ippp0 141.45.225.75) IP -> win95-rechner: Nr.1 192.168.10.2 Nr.2 192.168.10.3 Nr.3 192.168.10.4 Netmask - 255.255.255.0 Netscape (win95) geht über proxy: 192.168.10.1
datei - /etc/resolve.conf - --- schnipp --- hosts,bind (oder so ähnlich) nameserver 141.45.1.1 nameserver 141.45.100.5 --- schnapp ---
datei - /etc/route.conf - --- schnipp --- 192.168.10.1 0.0.0.0 255.255.255.0 eth0 // ne2000-karte 141.45.1.1 0.0.0.0 255.255.255.255 ippp0 // isdn-karte default 141.45.1.1 // 1. name-server des ISP --- schnapp ---
die isdn-verbindung klappt soweit. gebe ich eine fremde ip-adresse oder www-adresse in netscape (auf win95-rechnerX) ein, so wird die isdn-karte angesprochen und die verbindung aufgebaut.
PROBLEM: jedoch erscheint die html-seite nicht sofort im browser. erst, wenn ich die suche stoppe (ESC) und die adresse noch einmal eingebe (einfach wieder ENTER), dann kommt der html-text. ich vermute, daß die neu route (über ippp0) zwar gesetzt ist, aber die datenpakete beim ersten mal (also direkt nach dem verbindungsaufbau) nicht über diese gesendet werden. ich weiß dann imer nicht, ob die verbindung tatsächlich geklappt hat oder nicht. ich muß manchmal die suche mehrmals neu starten (ESC -> ENTER), da u.U. beim ISP besetzt ist.
FRAGE 1: wie schaffe ich es, daß auch gleich nach dem ersten eingeben der www-seite, deren inhalt bei erfolgreichem verbindungsaufbau angezeigt wird? (wenn dies dann nach einer weile nicht geschieht, weiß ich, daß u.U. ständig besetzt ist)
FRAGE 2: wo kann ich sehen (im proxy oder isdnctrl), welcher win95-rechner den eigentlichen verbindungsaufbau angestoßen hat? (also dessen IP) ich will die einzelnen verbindungszeiten mitprotokollieren (wer, wann, wie lange).
FRAGE 3: warum geht die default-route über ippp0? ich will diese default im eigenen netz haben (eth0). ich habe schon default 192.168.10.1 eingetragen, doch da kam beim starten des rechners eine fehlermeldung (irgendwas mit httpd ???)
danke im voraus!!!
tschö, rene
ps: ich stelle bald auf masquerading um und hörte, daß es probleme mit suse6.3 gibt oder auch nicht. wie ist der stand der dinge? was sollte ich beachten?
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com
On Thu, 13 Jan 2000, Christoph Poliwoda wrote:
völlig richtige Antwort gelesen habe, auf jeden Fall IP_DYNIP=YES zu setzen (wurde früher mal als dynip-Patch bezeichnet), wollte ich auch mal meine Erfahrung hier weitergeben, nämlich:
Der IP_DYNIP=YES Schalter funktionierte bei mir mit dem 2.2.13 Kernel NICHT.
Ich habe das Problem nach der Umstellung auf SuSE 6.3 gehabt; in der SuSE Version ist 2.2.13 standardmäßig eingerichtet. Anscheinend wurde
Hallo Christoph, hallo Liste mehr durch Zufall lese ich das ... geht es um SuSE_kernel_2.2.13 oder kernel_org_2.2.13 ... oder beide? Koennte _das_ mein Problem sein? siehe ==>> ISDN loeppt und loeppt nich Sollte ich den kernel mal down_graden? => 2.2.10 ? Oder up 2.2.14 ? ;-) Zum 1. Mal will ich eine Kiste mit dyn_IPs zum Rennen bringen, es klappt nicht; aber immer ist einer der genannten kernels 2.2.13 im Spiel. mal SuSE.2.2.13 mal org.2.2.13 (z.Zt.) Wie sind denn sonst so die Erfahrungen mit 2.2.13 und dyn IPs hier im Hause? -- mit freundlichen Grüßen Hajo C Jeske u. Tux
On Thu, 13 Jan 2000, Christoph Poliwoda wrote:
völlig richtige Antwort gelesen habe, auf jeden Fall IP_DYNIP=YES zu setzen (wurde früher mal als dynip-Patch bezeichnet), wollte ich auch mal meine Erfahrung hier weitergeben, nämlich:
Der IP_DYNIP=YES Schalter funktionierte bei mir mit dem 2.2.13 Kernel NICHT.
Ich habe das Problem nach der Umstellung auf SuSE 6.3 gehabt; in der SuSE Version ist 2.2.13 standardmäßig eingerichtet. Anscheinend wurde
Hallo Christoph, hallo Liste
mehr durch Zufall lese ich das ... geht es um SuSE_kernel_2.2.13 oder kernel_org_2.2.13 ... oder beide?
Ich habe einfach einen der vorkompilierten Kernel der SuSE 6.3 installiert; also gehe ich mal davon aus, dass es sich um den SuSE_kernel_2.2.13 handelt. Allerdings hatte ich nicht den Eindruck, dass sich die Kernel-Sourcen (SuSE oder kernel.org) an der entscheidenden Stelle unterscheiden... Ausprobiert hab' ich es aber nicht.
Koennte _das_ mein Problem sein? siehe ==>> ISDN loeppt und loeppt nich Sollte ich den kernel mal down_graden? => 2.2.10 ? Oder up 2.2.14 ? ;-)
Laut SuSE SDB gibt es mit den 2.2 Kernels das »ISDN-wird-immer-langsamer-Problem« oder auch »PING-Zeiten-werden-immer-größer-Problem«, dass erst mit 2.2.13 gelöst ist. Also empfehle ich den 2.2.14-Kernel, der wie erwähnt, nach meiner bisherigen Erfahrung (2.2.14 läuft bei mir aber erst seit drei Tagen) weder das immer-langsamer-Problem noch das DYNIP-Problem hat. Gruß Christoph
participants (3)
-
Burghardt, Axel -
Christoph Poliwoda -
Hajo C Jeske