Re:merkwürdiges Routing Problem
Am Donnerstag, 16. Mai 2002 19:58 schrieben Sie:
1.) hast du ip_resend mit installiert??
Habe die Minimalinstallation ohne X von SuSE 8 gemacht, da wars nicht dabei. Habs jetzt nachinstalliert. Es klappt leider immernoch nicht. Denke aber dass das die Lösung dür mein Problem sein kann. Wie aktivier ich es dann, damit er das auch nutzt?
2.) meine default route sieht etwas anders aus:
Dest gatew genmask flag iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ippp0
ich würde die default route einfach mal abändern.
Wie mach ich das und worauf? Danke Olli
On Fri, May 17, 2002 at 02:06:21PM +0200, Oliver Bohlen wrote:
Am Donnerstag, 16. Mai 2002 19:58 schrieben Sie:
1.) hast du ip_resend mit installiert??
Habe die Minimalinstallation ohne X von SuSE 8 gemacht, da wars nicht dabei. Habs jetzt nachinstalliert. Es klappt leider immernoch nicht. Denke aber dass das die Lösung dür mein Problem sein kann. Wie aktivier ich es dann, damit er das auch nutzt?
Einfach in /etc/sysconfig/isdn/cfg-net0 IP_RESEND="yes" Wenn Du ip_resend noch Parameter uebergeben willst geht das mit: IP_RESEND_PARAMETER="optionale parameter" Danach: SuSEconfig --module isdn rcnetwork restart -o type=ippp
2.) meine default route sieht etwas anders aus:
Dest gatew genmask flag iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ippp0
ich würde die default route einfach mal abändern.
Wie mach ich das und worauf?
Die Route ist richtig. (Es ist eine device route, das heisst unabhaengig von der Adresse, das ist eine sauberere Loesung als mit Dummy Adressen zu arbeiten). -- Karsten Keil SuSE Labs ISDN development
Am Freitag, 17. Mai 2002 16:05 schrieb Karsten Keil:
1.) hast du ip_resend mit installiert??
Habe die Minimalinstallation ohne X von SuSE 8 gemacht, da wars nicht dabei. Habs jetzt nachinstalliert. Es klappt leider immernoch nicht. Denke aber dass das die Lösung für mein Problem sein kann. Wie aktivier ich es dann, damit er das auch nutzt?
Einfach in /etc/sysconfig/isdn/cfg-net0 IP_RESEND="yes" Wenn Du ip_resend noch Parameter uebergeben willst geht das mit: IP_RESEND_PARAMETER="optionale parameter"
Danach:
SuSEconfig --module isdn rcnetwork restart -o type=ippp
O.K. ich habs so gemacht. Der Eintrag stand da noch nicht drin. Hab ihn also komplett neu reingeschrieben. Dannach: -- schnipp -- utopia:~ # SuSEconfig --module isdn Starting SuSEconfig, the SuSE Configuration Tool... Running module isdn only Reading /etc/rc.config and updating the system... Executing /sbin/conf.d/SuSEconfig.isdn... Reading cfg-contr0 ... Modify /etc/isdn/isdnlog.options.contr0 Modify isdn.conf Reading cfg-net0 ... Writing ifcfg-ippp0 ... options.ippp0 ...pap-secrets... chap-secrets... done Finished. utopia:~ # rcnetwork restart -o type=ippp Shutting down network interfaces: ippp0 done eth0 done Setting up network interfaces: lo done eth0 done ippp0 done utopia:~ # utopia:~ # isdnctrl status ippp0 ippp0 is not connected utopia:~ # ping suse.de ping: unknown host suse.de utopia:~ # ping suse.de PING suse.de (213.95.15.200) from 217.86.236.207 : 56(84) bytes of data. 64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=1 ttl=245 time=46.4 ms --- suse.de ping statistics --- 2 packets transmitted, 1 received, 50% loss, time 1018ms rtt min/avg/max/mdev = 46.436/46.436/46.436/0.000 ms utopia:~ # isdnctrl hangup ippp0 ippp0 hung up utopia:~ # isdnctrl status ippp0 ippp0 is not connected utopia:~ # ping 213.95.15.200 PING 213.95.15.200 (213.95.15.200) from 192.168.0.99 : 56(84) bytes of data. ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument --- 213.95.15.200 ping statistics --- 3 packets transmitted, 0 received, 100% loss, time 2023ms utopia:~ # -- schnapp -- Woran kann es liegen? Hier nochmal meine /etc/sysconfig/isdn/cfg-net0 -- schnipp -- utopia:~ # cat /etc/sysconfig/isdn/cfg-net0 CALLBACK="off" CHARGEHUP="on" COMPRESSION="no" DEFAULTROUTE="yes" DIALMODE="auto" DYNAMICIP="yes" FIREWALL="no" IDLETIME="30" IPADDR="192.168.0.99" IP_RESEND="yes" MSN="" MULTILINK="no" PROTOCOL="syncppp" PROVIDER="tonline" PTPADDR="192.160.0.1" STARTMODE="onboot" USEPEERDNS="no" utopia:~ # -- schnapp -- Muss ich vielleicht noch irgendwelche Parameter angeben? Danke für die Hilfe + Gruß Olli
On Fre, 17 Mai 2002, Oliver Bohlen wrote:
utopia:~ # ping suse.de ping: unknown host suse.de
Adresse wird nicht aufgelöst, also (noch) kein DNS bekannt
utopia:~ # ping suse.de PING suse.de (213.95.15.200) from 217.86.236.207 : 56(84) bytes of data. 64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=1 ttl=245 time=46.4 ms
Nachdem die Verbindung zu deinem Provider steht, ist auch ein DNS bekannt, so findet zumindest mal ein Paket seinen Weg hin und zurück.
--- suse.de ping statistics --- 2 packets transmitted, 1 received, 50% loss, time 1018ms rtt min/avg/max/mdev = 46.436/46.436/46.436/0.000 ms
Warum noch Pakete verloren gehen, weiss ich nicht.
utopia:~ # ping 213.95.15.200 PING 213.95.15.200 (213.95.15.200) from 192.168.0.99 : 56(84) bytes of data. ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
--- 213.95.15.200 ping statistics --- 3 packets transmitted, 0 received, 100% loss, time 2023ms
Also, das erkläre ich mir so: ping schickt eine Verbindungsanforderung für 213.95.15.200. Die default route zeigt auf dein für deinen Provider konfiguriertes Interface (ippp0). Die Verbindung zum Provider wird also aufgebaut. Ping kriegt aber nichts von den veränderten Adressen mit (du hast ja vom Provider eine dynamische ermittelte IP-Adresse erhalten). Also landen die (Rück-)Pakete im Nirwana. Beim zweiten Ping steht die Verbindung schon, die IP-Adresse ist dem System bekannt, also klappt auch der Ping, denn der angepingte Partner weiss, wohin die Pakete zurückzuschicken sind. Also IMHO ein ganz normales Verhalten bei einer Wählverbindung ohne feste Routen. Um das Problem mit dem DNS in den Griff zu bekommen, solltest du dich mal um die Geschehnisse um deine /etc/resolv.conf kümmern. Wie von Zauberhand verändert die nämlich, wenn du es nicht unterbindest, beim Aufbau der Verbindung mit deinem Provider ihren Inhalt. Lass dir die Datei einfach mal im offline und im online Status anzeigen. Jetzt kannst du zum Beispiel den Trick anwenden, die Datei im offline Status mit den gleichen Inhalt zu bestücken, wie er im online Status ist. Du schreibst einfach die IP-Adressen der DNS hinein, die dein Provider primär verwendet.
Danke für die Hilfe + Gruß Olli
HTH, Reinhard.
Am Freitag, 17. Mai 2002 22:15 schrieb Reinhard Habichtsberg:
utopia:~ # ping suse.de ping: unknown host suse.de
Adresse wird nicht aufgelöst, also (noch) kein DNS bekannt
Ich denke nicht, dass es ein DNS-Problem ist. Der DNS stimmt und ist korrekt in der /etc/resolv.conf eingetragen. -- schnipp -- utopia:/ # cat /etc/resolv.conf nameserver 194.25.2.129 search t-online.de -- schnapp --
utopia:~ # ping suse.de PING suse.de (213.95.15.200) from 217.86.236.207 : 56(84) bytes of data. 64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=1 ttl=245 time=46.4 ms
Nachdem die Verbindung zu deinem Provider steht, ist auch ein DNS bekannt, so findet zumindest mal ein Paket seinen Weg hin und zurück.
Ist er auch wenn ich offline bin. Steht fest in der /etc/resolv.conf.
--- suse.de ping statistics --- 2 packets transmitted, 1 received, 50% loss, time 1018ms rtt min/avg/max/mdev = 46.436/46.436/46.436/0.000 ms
Warum noch Pakete verloren gehen, weiss ich nicht.
Naja, ich denke das erste Packet wird nicht richtig groutet, da noch keine Verbindung besteht, wenn sie dann besteht reitet der irgendwie die ganze Zeit auf diesem ersten Packet rum und routet somit auch die andern nicht. Erst nach einer Unterbrechung und nach einem neuen Versuch klappt es dann.
utopia:~ # ping 213.95.15.200 PING 213.95.15.200 (213.95.15.200) from 192.168.0.99 : 56(84) bytes of data. ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
--- 213.95.15.200 ping statistics --- 3 packets transmitted, 0 received, 100% loss, time 2023ms
Also, das erkläre ich mir so: ping schickt eine Verbindungsanforderung für 213.95.15.200. Die default route zeigt auf dein für deinen Provider konfiguriertes Interface (ippp0). Die Verbindung zum Provider wird also aufgebaut. Ping kriegt aber nichts von den veränderten Adressen mit (du hast ja vom Provider eine dynamische ermittelte IP-Adresse erhalten). Also landen die (Rück-)Pakete im Nirwana.
Ich weiss nicht. könnte sein.
Beim zweiten Ping steht die Verbindung schon, die IP-Adresse ist dem System bekannt, also klappt auch der Ping, denn der angepingte Partner weiss, wohin die Pakete zurückzuschicken sind.
Also IMHO ein ganz normales Verhalten bei einer Wählverbindung ohne feste Routen.
Tja. normal ist so ein Wort. Bei meinem alten Router den ich mit SuSE 7.2 aufgesetzt hatte war das Problem damit gegessen den Wert DYNIP auf yes zu setzen. Hier bei SuSE 8 anscheinent nicht. Komisch ist dazu ja auch noch, dass ich das Problem nicht hab wenn ich von meiner Workstation pinge, die über den Router ins Internet geht.
Um das Problem mit dem DNS in den Griff zu bekommen, solltest du dich mal um die Geschehnisse um deine /etc/resolv.conf kümmern. Wie von Zauberhand verändert die nämlich, wenn du es nicht unterbindest, beim Aufbau der Verbindung mit deinem Provider ihren Inhalt.
Leider verändert die bei mir nicht den Inhalt. Guck: -- schnipp -- utopia:/ # isdnctrl status ippp0 ippp0 is not connected utopia:/ # cat /etc/resolv.conf nameserver 194.25.2.129 search t-online.de utopia:/ # isdnctrl dial ippp0 Dialing of ippp0 triggered utopia:/ # cat /etc/resolv.conf nameserver 194.25.2.129 search t-online.de utopia:/ # isdnctrl status ippp0 ippp0 connected to 0191011 utopia:/ # isdnctrl hangup ippp0 ippp0 hung up utopia:/ # cat /etc/resolv.conf nameserver 194.25.2.129 search t-online.de utopia:/ # -- schnapp --
Lass dir die Datei einfach mal im offline und im online Status anzeigen. Jetzt kannst du zum Beispiel den Trick anwenden, die Datei im offline Status mit den gleichen Inhalt zu bestücken, wie er im online Status ist. Du schreibst einfach die IP-Adressen der DNS hinein, die dein Provider primär verwendet.
Leider scheint das nicht das Problem zu sein. Trotzdem vielen Dank. Gruß Olli
On Fri, May 17, 2002 at 05:24:55PM +0200, Oliver Bohlen wrote:
Einfach in /etc/sysconfig/isdn/cfg-net0 IP_RESEND="yes" Wenn Du ip_resend noch Parameter uebergeben willst geht das mit: IP_RESEND_PARAMETER="optionale parameter"
Danach:
SuSEconfig --module isdn rcnetwork restart -o type=ippp
O.K. ich habs so gemacht. Der Eintrag stand da noch nicht drin. Hab ihn also komplett neu reingeschrieben. Dannach:
...
--- suse.de ping statistics --- 2 packets transmitted, 1 received, 50% loss, time 1018ms rtt min/avg/max/mdev = 46.436/46.436/46.436/0.000 ms utopia:~ # isdnctrl hangup ippp0 ippp0 hung up utopia:~ # isdnctrl status ippp0 ippp0 is not connected utopia:~ # ping 213.95.15.200 PING 213.95.15.200 (213.95.15.200) from 192.168.0.99 : 56(84) bytes of data. ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
--- 213.95.15.200 ping statistics --- 3 packets transmitted, 0 received, 100% loss, time 2023ms
utopia:~ # -- schnapp --
Woran kann es liegen? Hier nochmal meine /etc/sysconfig/isdn/cfg-net0
Das liegt am ping Programm und hat nichts mit routing usw. zu tun. Das erklaert auch, warum es nur auf dem Router selbst Probleme macht und auf clients funktioniert. Aus einer anderen Mail von mir:
die Verbindung wird bei einem ping aufgebaut (das das ping selbst nie eine Antwort bekommt, liegt am ping Programm selbst, seit der 7.2 wird das ping der iputils verwendet, das scheinbar nicht mit sich aendernen Absender Adressen umgehen kann, vorher war es das des nkitb)
Ich habe auch mal das alte nkitb ping (von einer 7.1) auf eine 8.0 kopiert, damit funktioniert es. Leider sehen scheinbar die Netzwerkleute das Verhalten des iputils ping als richtig an, Grund fuer die Umstellung war, das nkitb nicht weiter gepflegt wird und alle anderen Distributionen schon lange das ping von iputils nutzen. Ich hake da aber nochmal genauer nach, fuer mich ist es ein bug. -- Karsten Keil SuSE Labs ISDN development
Am Samstag, 18. Mai 2002 00:08 schrieb Karsten Keil:
Woran kann es liegen? Hier nochmal meine /etc/sysconfig/isdn/cfg-net0
Das liegt am ping Programm und hat nichts mit routing usw. zu tun. Das erklaert auch, warum es nur auf dem Router selbst Probleme macht und auf clients funktioniert.
Aus einer anderen Mail von mir:
die Verbindung wird bei einem ping aufgebaut (das das ping selbst nie eine Antwort bekommt, liegt am ping Programm selbst, seit der 7.2 wird das ping der iputils verwendet, das scheinbar nicht mit sich aendernen Absender Adressen umgehen kann, vorher war es das des nkitb)
Mein alter Router war SuSE 7.2. Da ging es definitiv. Wie hätten sonst meine ganzen Scripte funktioniert...?
Ich habe auch mal das alte nkitb ping (von einer 7.1) auf eine 8.0 kopiert, damit funktioniert es.
Das liegt mit Sicherheit nicht (nur) an dem ping Programm. Hier mit lynx das gleiche Phänomen. Mit YOU und allen anderen Programmen wie fetchmail usw. habe ich genau das gleiche Problem. -- schnipp -- utopia:~ # isdnctrl status ippp0 ippp0 is not connected utopia:~ # lynx web.de Looking up web.de first Looking up www.web.de.com, guessing... Looking up www.web.de.edu, guessing... Looking up www.web.de.net, guessing... Looking up www.web.de.org, guessing... Can't Access `file://localhost/root/web.de' Alert!: Unable to access document. lynx: Can't access startfile utopia:~ # isdnctrl status ippp0 ippp0 connected to 0191011 utopia:~ # lynx web.de utopia:~ # -- schnapp --
Leider sehen scheinbar die Netzwerkleute das Verhalten des iputils ping als richtig an, Grund fuer die Umstellung war, das nkitb nicht weiter gepflegt wird und alle anderen Distributionen schon lange das ping von iputils nutzen.
Ich hake da aber nochmal genauer nach, fuer mich ist es ein bug.
Naja wie gesagt. bei meinem 7.2 Router ging es immer. Mit Ping, Lynx, YOU und sonstwo mit. Nur hier gibts eben dieses Einwahlproblem. Ich bin mir relativ sicher, dass wir mit der Lösung in Richtung IP_RESEND auf dem richtigen Weg waren. Danke nochmal für die Mühe Olli
On Sat, May 18, 2002 at 10:58:49AM +0200, Oliver Bohlen wrote:
Am Samstag, 18. Mai 2002 00:08 schrieb Karsten Keil:
Woran kann es liegen? Hier nochmal meine /etc/sysconfig/isdn/cfg-net0
Das liegt am ping Programm und hat nichts mit routing usw. zu tun. Das erklaert auch, warum es nur auf dem Router selbst Probleme macht und auf clients funktioniert.
Aus einer anderen Mail von mir:
die Verbindung wird bei einem ping aufgebaut (das das ping selbst nie eine Antwort bekommt, liegt am ping Programm selbst, seit der 7.2 wird das ping der iputils verwendet, das scheinbar nicht mit sich aendernen Absender Adressen umgehen kann, vorher war es das des nkitb)
Mein alter Router war SuSE 7.2. Da ging es definitiv. Wie hätten sonst meine ganzen Scripte funktioniert...?
Hmm kann sein das bei der 7.2 noch das alte ping dabei war, die Umstellung war: * Sat Aug 25 2001 - kukuk@suse.de - Update to snapshot from 24 Aug 2001 - Use included ping like all other distributions do - Don't use included rarpd and tftpd - Lot of new functions and minor bug fixes Das war nach der 7.2 release. Ich bin dadurch auf die 7.1 gekommen, weil das die letzte war, die ein nkitb hatte. Bei der 7.2 wurde aber das alte ping in die iputils gepatcht (gerade nachgesehen). Es sollte funktionieren wenn Du das ping der 7.2 benutzt, das der 7.3 hat allerdings das selbe Verhalten.
Ich habe auch mal das alte nkitb ping (von einer 7.1) auf eine 8.0 kopiert, damit funktioniert es.
Das liegt mit Sicherheit nicht (nur) an dem ping Programm. Hier mit lynx das gleiche Phänomen. Mit YOU und allen anderen Programmen wie fetchmail usw. habe ich genau das gleiche Problem.
-- schnipp -- utopia:~ # isdnctrl status ippp0 ippp0 is not connected utopia:~ # lynx web.de
Looking up web.de first Looking up www.web.de.com, guessing... Looking up www.web.de.edu, guessing... Looking up www.web.de.net, guessing... Looking up www.web.de.org, guessing... Can't Access `file://localhost/root/web.de' Alert!: Unable to access document.
lynx: Can't access startfile utopia:~ # isdnctrl status ippp0 ippp0 connected to 0191011 utopia:~ # lynx web.de utopia:~ # -- schnapp --
Leider sehen scheinbar die Netzwerkleute das Verhalten des iputils ping als richtig an, Grund fuer die Umstellung war, das nkitb nicht weiter gepflegt wird und alle anderen Distributionen schon lange das ping von iputils nutzen.
Ich hake da aber nochmal genauer nach, fuer mich ist es ein bug.
Naja wie gesagt. bei meinem 7.2 Router ging es immer. Mit Ping, Lynx, YOU und sonstwo mit. Nur hier gibts eben dieses Einwahlproblem. Ich bin mir relativ sicher, dass wir mit der Lösung in Richtung IP_RESEND auf dem richtigen Weg waren.
Das ping Problem kann nicht durch IP_RESEND geloest werden, es ist definitiv ein Fehler (wobei manche Leute es nicht als Fehler sehen) im ping selbst. Bei den anderen Programmen sollte IP_RESEND und ein echo "7" >> /proc/sys/net/ipv4/ip_dynaddr helfen. -- Karsten Keil SuSE Labs ISDN development
participants (3)
-
Karsten Keil -
Oliver Bohlen -
Reinhard Habichtsberg