Re: [suse-laptop] ftp und telnet auf Suse 6.4 und 7.2
Hallo Lars
Sieh dir mal dein Netzwerk genauer an. Mit dem Befehl ifconfig -a siehst du, wie deine Netzwerkschnittstellen konfiguriert sind (macht natuerlich nur Sinn, wenn du online bist). Mit route bekommst du eine Tabelle, wohin welche Pakete geschickt werden. Mit iptables -L siehst du, ob evtl. Firewall-Regeln aktiv sind. Dann versuche mal ping an den Rechner, mit dem du dich verbinden willst. Eventuell hilft dir auch ein traceroute an den betreffenden Rechner, dann siehst du, ob die Pakete irgendwo unterwegs abgefangen werden.
Ich habe das jetzt ausprobiert. Ich sollte hinzufügen, da Laptop mit 7.2 hat eine eingebaute Netzkarte, die problemlos läuft, aber für die ich natürlich ein ineted starten muß, ein gateway, eine eigene IP 147.96.5.222, und ein nameserver einrichten muß, dinge die ich für das 6.4 Laptop, das keine Netzkarte hat, nicht nötig sind. Möglicherweise ist das das Problem: traceroute verrät mir, daß offensichtlich das Signal das 7.2 Laptop nicht verläßt. Was meinst du? So ich habe es überprüft, erst inetd abgeschaltet, also nur lokaler lokaler Loop, keine Änderung, dann habe die Netzkarte explizit lahmglegt, und das hat funktioniert, soll heißen telnet hat funktioniert. Das ganze erscheint mir ziemlich absured und Lächerlich, sogar Windows bringt es fertig richtig zwischen Modem (allerdings internem) und der Netzkarte zu unterscheiden. Weißt du Rat? Danke und Gruß Uwe Hier die attachments. Erst von suse6.4 nur externes modem, dann von 7.2 netzkarte und externes modem lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ppp0 Link encap:Point-to-Point Protocol inet addr:62.151.104.94 P-t-P:62.14.2.142 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:34 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.14.2.142 * 255.255.255.255 UH 0 0 0 ppp0 loopback * 255.0.0.0 U 0 0 0 lo default 62.14.2.142 0.0.0.0 UG 0 0 0 ppp0 1 * * * 2 62-15-0-150.es.jazztelbone.net (62.15.0.150) 120 ms 62-15-0-149.es.jazztelbone.net (62.15.0.149) 145 ms 160 ms 3 62.14.61.58 (62.14.61.58) 130 ms 62.14.61.78 (62.14.61.78) 145 ms 130 ms 4 62.151.16.248 (62.151.16.248) 150 ms 150 ms 130 ms 5 mad-val-i2-feth0-0-4.telia.net (213.248.71.109) 160 ms 140 ms 130 ms 6 mad-val-i1-pos1-2.telia.net (213.248.75.25) 140 ms 130 ms 140 ms 7 dante-01354-mad-val-i1.c.telia.net (213.248.71.30) 130 ms 140 ms 130 ms 8 GE0-1-0.EB-Madrid0.red.rediris.es (130.206.220.42) 140 ms 134 ms 262 ms 9 ucm-router.red.rediris.es (130.206.206.14) 138 ms 140 ms 130 ms 10 rcpdaa010010.red.ucm.es (147.96.1.1) 131 ms 150 ms 130 ms 11 mataplx2.quim.ucm.es (147.96.5.224) 140 ms 150 ms 150 ms eth0 Link encap:Ethernet HWaddr 00:00:E2:42:34:F0 inet addr:147.96.5.222 Bcast:147.96.5.255 Mask:255.255.255.0 inet6 addr: fe80::e242:34f0/10 Scope:Link inet6 addr: fe80::200:e2ff:fe42:34f0/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:16 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:984 (984.0 b) Interrupt:10 Base address:0x1000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:35 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2324 (2.2 Kb) TX bytes:2324 (2.2 Kb) ppp0 Link encap:Point-to-Point Protocol inet addr:62.151.100.139 P-t-P:62.14.16.68 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:1232 (1.2 Kb) TX bytes:328 (328.0 b) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62-14-16-68.es. * 255.255.255.255 UH 0 0 0 ppp0 147.96.5.0 * 255.255.255.0 U 0 0 0 eth0 default 62-14-16-68.es. 0.0.0.0 UG 0 0 0 ppp0 1 hilbert.quim.ucm.es (147.96.5.222) 2999 ms !H 2999 ms !H 3000 ms !H
Uwe Brauer schrieb:
Ich sollte hinzufügen, da Laptop mit 7.2 hat eine eingebaute Netzkarte, die problemlos läuft, aber für die ich natürlich ein ineted starten muß, ein gateway, eine eigene IP 147.96.5.222, und ein nameserver einrichten muß, dinge die ich für das 6.4 Laptop, das keine Netzkarte hat, nicht nötig sind.
Einen inetd mußt Du nur starten, wenn Dein Rechner auf Anfragen von _außen_ antworten soll, also Du anderen Dienste wie telnet oder ftp zur Verfügung stellst. Sonst nicht. Wenn Du nur ein PPP-Interface hast ist klar, daß die default-route darüber laufen soll, das setzt der ppp-Dämon im Zweifel selber. Wenn Du mehrere Interfaces hast (ppp0 und eth0) mußt Du schon selber sagen, über welchen Host die Default route laufen soll, das kann der Kernel ja nicht erraten. Du könntest ja übers eth0 permanent im Internet sein, und das Modem nur sporadisch für eine Leitung benutzen. Ein dauerhaftes Interface braucht eine dauerhafte IP-Nummer. Wenn sie nicht dynamisch über DHCP geholt werden kann mußt Du sie fest setzen. Ein sporadisches Interface wie ppp0, bei dem klar ist daß die andere Seite Deine IP-Nummer jedesmal neu setzt, kann vor dem Verbindungsaufbau jede beliebige IP-Nummer haben, sie wird ja eh geändert. Deswegen mußt Du Dich darum nicht kümmern. Einer der Parameter beim PPP-Verbindungsaufbau ist daß die andere Seite Deiner Seite die IP-Nummern von relevanten NameServern mitteilt. Insofern mußt Du Dich da nicht selber drum kümmern, wie das der Fall ist, wenn Du eine feste Leitung über ein Netzwerk hast. Dann mußt Du in der Tat einen Name Server wissen. Zusammenfassend kann man sagen: Wenn Du eine "richtige" Netzwerkschnittstelle hast und benutzt, muß sie eine IP-Nummer haben, und Du mußt eine default route setzen, und einen Name Server eintragen. Wenn Du nur ein PPP-Interface hast, brauchst Du das nicht, weil klar ist daß alles darüber läuft und sich der PPP-Dämon um die Details kümmert. Diese Ausführungen helfen Dir aber bei Deinem Problem nicht weiter. Ich tippe darauf, daß entweder die default route nicht richtig gesetzt ist, sodaß der Kernel beim Verbindungsaufbau nicht weiß, daß er die Leitung aufmachen muß (obwohl deine Routing-Tabelle ganz vernünftig aussieht, Woher hat er denn den Namen für das Default-Gateway?), oder aber daß der eingetragene Name Server nicht richtig ist, sodaß er übers eth0 versucht, ihn zu erreichen und nicht über die default route. Was mich am meisten erstaunt ist daß er sich selber per traceroute nicht erreichen kann. Das ist pathologisch. Sich selbst muß er in 0 ms erreichen können, ein ping auf seine eigene eth0-IP-Nummer muß unter 100 us gehen. -- Eckhard Rüggeberg E.Rueggeberg@t-online.de - Who is General Failure, and why is he reading my disk ??
Hallo Eckhard, Hallo Lars
Uwe Brauer schrieb: [...] Einen inetd mußt Du nur starten, wenn Dein Rechner auf Anfragen von _außen_ antworten soll, also Du anderen Dienste wie telnet oder ftp zur Verfügung stellst. Sonst nicht. Das stimmt, das hatte ich nicht bedacht
Ich habe mein Problem, glaube ich nicht so vollständig erklärt. Auf dem Laptop ist eine interne Netzkarte, konfiguriert mit YAST1. Der Rechner hat IP 147.96.5.222 Gateway 147.96.5.1 Nameserver 147.96.1.9 das Laptop ist während der Woche am internen Uninetz, am Wochenende bei mir zu hause und wird dann mit dem externen Modem betrieben (Yast bietet mir die Möglichkeit an, das PCMCIA Modem im gleichen Menu zu konfigurieren) Ich benutze aber ein externes Modem, das ich mit wvconfig konfiguriert habe. In diesem wvdial Menu wird nichts über Auto IP, und Gateways gesagt, lediglich kann ich den Nameserver von Hand setzen, wenn der Provider kein Auto DNS macht. Das ist der Fall, und dementsprechend wird dann resolv.conf geändert. Verbinde ich mich mit dem Modem, dann wird offensichtlich der geänderte Nameserver erkannt, denn ich kann mich problemlos zu webseiten zb www.Suse.de verbinden. Bei telnet zb Telnet 147.96.5.228 (ein anderer unserer Unirechner) benutzt der Laptop offensichtlich das Gateway 147.96.5.1. Da die Netzkarte nicht angeschlossen ist, funktioniert das nicht.
Wenn Du nur ein PPP-Interface hast ist klar, daß die default-route darüber laufen soll, das setzt der ppp-Dämon im Zweifel selber. Wenn Du mehrere Interfaces hast (ppp0 und eth0) mußt Du schon selber sagen, über welchen Host die Default route laufen soll, das kann der Kernel ja nicht erraten. Du könntest ja übers eth0 permanent im Internet sein, und das Modem nur sporadisch für eine Leitung benutzen.
Das ist glaube ich das Problem, Lars meint es könnte am Firewall liegen, aber leider kann ich das erst morgen Abend wieder ausprobieren, da ich ipstables nicht installiert hatte. Wenn meine Vermutung richtig ist, wo soll ich wvdial sagen, welches Gateway das Modem benutzen soll??? Kppp funktioniert bei mir KDE 2.2.1 nicht richtig, das heißt der DNS Server des Providers, obwohl gesetzt, wird bei der Verbindung nicht benutzt Meine bisherige Lösung besteht darin, mit Yast1, die Netzkarte, und damit auch das Gateway lahmzulegen. Diese Lösung ist aber nur ein Provisorium; unter Windows passiert das alles nicht :-(, wenn das (allerdings interne Modem) benutzt wird, scheint windows zu wissen, daß es nicht das Netzwerkkarten Gateway benutzen sollte. Noch mal vielen Dank an alle Uwe
Uwe Brauer schrieb:
Verbinde ich mich mit dem Modem, dann wird offensichtlich der geänderte Nameserver erkannt, denn ich kann mich problemlos zu webseiten zb www.Suse.de verbinden.
Bei telnet zb
Telnet 147.96.5.228 (ein anderer unserer Unirechner) benutzt der Laptop offensichtlich das Gateway 147.96.5.1. Da die Netzkarte nicht angeschlossen ist, funktioniert das nicht.
Kann ja auch nicht. Es ist ja eine Route eingetragen, daß in das 147.96.5er Netz über eth0 zu gehen ist. Das ist auch gut und richtig so, solange eth0 tatsächlich in dem Netz steckt.
Das ist glaube ich das Problem, Lars meint es könnte am Firewall liegen [...]
Nein, es ist ein reines Routing-Problem.
wo soll ich wvdial sagen, welches Gateway das Modem benutzen soll???
Brauchst Du nicht, weil es der default für den PPP-Dämon ist, nach erfolgreicher Verbindungsaufnahmen die default route über das neue (i)ppp0 Interface zu setzen (in /etc/ppp/options? options.ppp?) Das heißt: Du mußt dem Rechner schon sagen, daß er in dem Fall, daß er mit dem Modem eine Verbindung aufgebaut hat, die Route ins 147.96.5er Netz wegwerfen muß. Da bietet sich bei SuSE 7.3 (vermutlich ist es aber bei 8.* ähnlich) /etc/ppp/ip-ip.local und /etc/ppp/ip-down.local an, die von /etc/ppp/ip-up = /etc/ppp/ip-down im Falle ihrer Existenz aufgerufen werden. Da schreibt Du einfach ein "route del ..." bezw. ein "route add ..." rein. Wenn das unter W*****s von alleine passiert, dann unterstellt Billy Boy in seiner unermeßlichen Weisheit, daß man, wenn man das Modem benutzt, das Netz nicht gleichzeitig benutzen kann/will. Das ist in der Mehrzahl der Fälle schlicht falsch, nur in Deinem Fall durch Zufall richtig. Überleg mal was passiert, wenn Du im Institut sitzt, das Netzwerk steckt, und Du benutzt das Modem, um eine Leitung zu einer Partnerfirma aufzumachen, die keinen Zugriff von außen übers Internet erlaubt. Die W*****s-Strategie würde bedeuten, daß Du auf einen Rechner im Institut über den Umweg der anderen Firma zugreifen müßtest! -- Eckhard Rüggeberg E.Rueggeberg@t-online.de - Who is General Failure, and why is he reading my disk ??
participants (2)
-
Eckhard Rüggeberg -
Uwe Brauer