kinternet: ipp0/eth0-Verwechselung?
Hallo zusammen, mein letzer Versuch diese Frage zu posten ist als Thread Antwort rausgegegangen, sorry dafür. Jetzt also ein neuer Versuch: Ich vesuche parallel zu meinem DSL Zugang auch über die ISDN Karte (Fritz Card) ins Netz zu gehen. Ich habe im Yast die entsprechenden Einstellungen vorgenommen. Wenn ich dann unter kinternet verbinden lasse wird auch eine Verbindung hergestellt. Diese geht jedoch offenbar nicht wirklich über die ISDN Karte; wir doch unter "Verbindung prüfen" als Schnittstelle eth0 angezeigt. Irgendeine Verbindung scheint aber dennoch aufgebaut zu werden, denn es wird eine IP Nummer vergeben (134.etc.). Ins Netz komme ich darüber trotzdem nicht. Hat irgendjemad eine Ahnung wo ich ansetzen könnte? Gruß Christian Hier das Log vom Einwahlversuch (habe die Rufnummer durch "Number" ersetzt) Feb 1 17:10:49 dhcppc1 ipppd[5021]: Connect[0]: /dev/ippp0, fd: 16 Feb 1 17:10:49 dhcppc1 isdnlog: Feb 01 17:10:49 tei 104 calling 019161 with +49 Number, Location HANGUP ( 0:04:47) Feb 1 17:10:49 dhcppc1 modify_resolvconf: restored /etc/resolv.conf.saved.by.ip ppd.ippp0 to /etc/resolv.conf Feb 1 17:10:49 dhcppc1 ipppd[5021]: Terminating on signal 15. Feb 1 17:10:49 dhcppc1 ipppd[5021]: closing fd 16 from unit 0 Feb 1 17:10:49 dhcppc1 ipppd[5021]: link 0 closed , linkunit: 0 Feb 1 17:10:49 dhcppc1 ipppd[5021]: Exit. Feb 1 17:10:49 dhcppc1 kernel: ippp_ccp: freeing reset data structure c34c4800 Feb 1 17:16:32 dhcppc1 isdnlog: Feb 01 17:16:32 tei 85 calling ? with ? Time:S un Feb 1 17:16:00 2004 Feb 1 17:16:32 dhcppc1 isdnlog: Feb 01 17:16:32 tei 85 calling ? with ? CONNEC T Feb 1 17:19:58 dhcppc1 ipppd[6595]: Found 1 device: Feb 1 17:19:58 dhcppc1 ipppd[6596]: ipppd i2.2.12 (isdn4linux version of pppd b y MH) started Feb 1 17:19:58 dhcppc1 ipppd[6596]: init_unit: 0 Feb 1 17:19:58 dhcppc1 kernel: ippp, open, slot: 0, minor: 0, state: 0000 Feb 1 17:19:58 dhcppc1 kernel: ippp_ccp: allocated reset data structure d63b400 0 Feb 1 17:19:58 dhcppc1 ipppd[6596]: Connect[0]: /dev/ippp0, fd: 22 Feb 1 17:19:58 dhcppc1 kernel: ippp0: dialing 1 019161... Feb 1 17:19:58 dhcppc1 isdnlog: Feb 01 17:19:58 * tei 104 calling 019161 with + 49 Number, Location RING (Data) Feb 1 17:20:01 dhcppc1 isdnlog: Feb 01 17:20:01 tei 104 calling 019161 with + 49 Number, Location Time:Sun Feb 1 17:19:00 2004 Feb 1 17:20:01 dhcppc1 isdnlog: Feb 01 17:20:01 tei 104 calling 019161 with + 49 Number, Location CONNECT (Data) Feb 1 17:20:01 dhcppc1 isdnlog: Feb 01 17:20:01 tei 104 calling 019161 with + 49 Number, Location INTERFACE ippp0 calling 019161 Feb 1 17:20:01 dhcppc1 isdnlog: Feb 01 17:20:01 tei 104 calling 019161 with + 49 Number, Location No area info for provider 33_0 (18), destination 0191 61 Feb 1 17:20:01 dhcppc1 kernel: isdn_net: ippp0 connected Feb 1 17:20:01 dhcppc1 ipppd[6596]: Local number: 2802873, Remote number: 01916 1, Type: outgoing Feb 1 17:20:01 dhcppc1 ipppd[6596]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 22 Feb 1 17:20:01 dhcppc1 ipppd[6596]: ioctl(SIOCSIFMTU): Invalid argument, 21 ipp p0 1514. Feb 1 17:20:01 dhcppc1 ipppd[6596]: Remote message: Feb 1 17:20:01 dhcppc1 ipppd[6596]: MPPP negotiation, He: No We: No Feb 1 17:20:01 dhcppc1 ipppd[6596]: CCP enabled! Trying CCP. Feb 1 17:20:01 dhcppc1 ipppd[6596]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol) Feb 1 17:20:01 dhcppc1 ipppd[6596]: ccp_resetci! Feb 1 17:20:01 dhcppc1 ipppd[6596]: local IP address 134.147.36.244 Feb 1 17:20:01 dhcppc1 ipppd[6596]: remote IP address 134.147.214.254 Feb 1 17:20:01 dhcppc1 ipppd[6596]: ppp not replacing existing default route to eth0[192.168.0.1] Feb 1 17:20:01 dhcppc1 modify_resolvconf: Service ipppd modified /etc/resolv.co nf. See info block in this file Feb 1 17:20:49 dhcppc1 isdnlog: Feb 01 17:20:49 tei 85 calling ? with ? NOTIFI CATION: Remote hold Feb 1 17:20:55 dhcppc1 isdnlog: Feb 01 17:20:55 tei 85 calling ? with ? NOTIFI CATION: Remote retrieval Feb 1 17:20:55 dhcppc1 isdnlog: Feb 01 17:20:55 tei 85 calling ? with ? Normal call clearing (User) Feb 1 17:21:00 dhcppc1 isdnlog: Feb 01 17:21:00 tei 85 calling ? with ? HANGUP ( 0:04:28) Feb 1 17:21:36 dhcppc1 kernel: isdn_net: local hangup ippp0 Feb 1 17:21:36 dhcppc1 kernel: ippp0: Chargesum is 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: Modem hangup Feb 1 17:21:36 dhcppc1 ipppd[6596]: Connection terminated. Feb 1 17:21:36 dhcppc1 ipppd[6596]: taking down PHASE_DEAD link 0, linkunit: 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: closing fd 22 from unit 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: link 0 closed , linkunit: 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: reinit_unit: 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: Connect[0]: /dev/ippp0, fd: 22 Feb 1 17:21:36 dhcppc1 isdnlog: Feb 01 17:21:36 tei 104 calling 019161 with +49 Number, Location Normal call clearing (User) Feb 1 17:21:36 dhcppc1 kernel: ippp_ccp: freeing reset data structure d63b4000 Feb 1 17:21:36 dhcppc1 kernel: ippp, open, slot: 0, minor: 0, state: 0000 Feb 1 17:21:36 dhcppc1 kernel: ippp_ccp: allocated reset data structure d63b4000 Feb 1 17:21:36 dhcppc1 isdnlog: Feb 01 17:21:36 tei 104 calling 019161 with +49 Number, Location HANGUP ( 0:01:35) Feb 1 17:21:36 dhcppc1 modify_resolvconf: restored /etc/resolv.conf.saved.by.ipppd.ippp0 to /etc/resolv.conf Feb 1 17:21:36 dhcppc1 ipppd[6596]: Terminating on signal 15. Feb 1 17:21:36 dhcppc1 ipppd[6596]: closing fd 22 from unit 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: link 0 closed , linkunit: 0 Feb 1 17:21:36 dhcppc1 ipppd[6596]: Exit. Feb 1 17:21:36 dhcppc1 kernel: ippp_ccp: freeing reset data structure d63b4000 Feb 1 17:21:37 dhcppc1 modprobe: modprobe: Can't locate module ippp0 Feb 1 17:21:37 dhcppc1 modprobe: modprobe: Can't locate module ippp0
Am Do, 2004-02-05 um 18.48 schrieb Christian Wolter:
Ich vesuche parallel zu meinem DSL Zugang auch über die ISDN Karte (Fritz Card) ins Netz zu gehen. Ich habe im Yast die entsprechenden Einstellungen vorgenommen. Wenn ich dann unter kinternet verbinden lasse wird auch eine Verbindung hergestellt. Diese geht jedoch offenbar nicht wirklich über die ISDN Karte; wir doch unter "Verbindung prüfen" als Schnittstelle eth0 angezeigt. Irgendeine Verbindung scheint aber dennoch aufgebaut zu werden, denn es wird eine IP Nummer vergeben (134.etc.). Ins Netz komme ich darüber trotzdem nicht.
Starte mal 'kadslwatch' bzw. 'kisdnwatch'. Dort werden aktive bzw. inaktive Verbindungen angezeicht.
Hat irgendjemad eine Ahnung wo ich ansetzen könnte?
Ich habe auch eine Fritz Card. DSL habe ich über Capi für DSL und ISDN über die Capi 2.0 Schnittstelle laufen. Habe damit keine Probleme. mfg michael
Starte mal 'kadslwatch' bzw. 'kisdnwatch'. Dort werden aktive bzw. inaktive Verbindungen angezeicht.
kisdnwatch zeigt eine aktive Verbindung an
Ich habe auch eine Fritz Card. DSL habe ich über Capi für DSL und ISDN über die Capi 2.0 Schnittstelle laufen. Habe damit keine Probleme.
ich wähle mich nicht direkt über DSL ein, sondern über einen Router. Wenn ich bei kinternet Verbindung prüfen wähle, zeigt er folgendes an: Gateway Adresse: 192.168.0.1 Eigene Adresse: 192.168.0.2 Interface: eth0 Nameserver: auf Antwort warten Eine antwort bekommt er allerdings nicht Lasse ich gleichzeitig meine Netzwerkkarte eingesteckt findet er einen Nameserver und es läuft alles. Aber er nutzt dabei nicht die ISDN sondern die DSL Verbindung. Ziehe ich der Karte nämlich den Stecker raus, gibts auch keine Verbindung mehr, obwohl kisdnwatch eine aktive ISDN Verbindung anzeigt. Brauche dringend noch einen Tip Gruß Christian
Am Fr, 2004-02-06 um 15.33 schrieb Christian Wolter:
ich wähle mich nicht direkt über DSL ein, sondern über einen Router.
Entschuldige, ich dachte du hast eine Fritz Card DSL.
Wenn ich bei kinternet Verbindung prüfen wähle, zeigt er folgendes an: Gateway Adresse: 192.168.0.1 Eigene Adresse: 192.168.0.2 Interface: eth0 Nameserver: auf Antwort warten
Eine antwort bekommt er allerdings nicht
Hast du die ISDN-Karte im Router?
Lasse ich gleichzeitig meine Netzwerkkarte eingesteckt findet er einen Nameserver und es läuft alles. Aber er nutzt dabei nicht die ISDN sondern die DSL Verbindung. Ziehe ich der Karte nämlich den Stecker raus, gibts auch keine Verbindung mehr, obwohl kisdnwatch eine aktive ISDN Verbindung anzeigt.
Meines Wissens nach wird auch nur die Schnittstelle überwacht und nicht die Aktivität des NTBAs.
Brauche dringend noch einen Tip
Gruß Christian
* Freitag, 06. Februar 2004 um 15:33 (+0100) schrieb Christian Wolter:
Lasse ich gleichzeitig meine Netzwerkkarte eingesteckt findet er einen Nameserver und es läuft alles. Aber er nutzt dabei nicht die ISDN sondern die DSL Verbindung. Ziehe ich der Karte nämlich den Stecker raus, gibts auch keine Verbindung mehr, obwohl kisdnwatch eine aktive ISDN Verbindung anzeigt.
Das Stichwort heisst "Routing": Die Default-Route deines Rechners
zeigt auf den Router und wird auch vom 'ipppd' beim
ISDN-Verbindungsaufbau nicht verändert (siehe gepostetes Log).
Falls du ISDN und DSL alternativ verwenden willst, dann musst du nach
dem ISDN-Verbindungsaufbau mit Hilfe von "/etc/ppp/ip-up.local" die
alte Default-Route löschen und eine neue durch ipppX setzen (und
umgekehrt bei Beendigung des ISDN-Verbindung).
Falls du beide Verbindungen gleichzeitig nutzen willst, dann wird es
kompliziert --> "http://www.lartc.org".
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Falls du ISDN und DSL alternativ verwenden willst, dann musst du nach dem ISDN-Verbindungsaufbau mit Hilfe von "/etc/ppp/ip-up.local" die alte Default-Route löschen und eine neue durch ipppX setzen (und umgekehrt bei Beendigung des ISDN-Verbindung).
Mir ist nicht ganz klar, wo in der Datei ich das tun müßte. Könntest Du mir die entsprechende Stelle zeigen? Christian
* Samstag, 07. Februar 2004 um 14:49 (+0100) schrieb Christian Wolter:
Falls du ISDN und DSL alternativ verwenden willst, dann musst du nach dem ISDN-Verbindungsaufbau mit Hilfe von "/etc/ppp/ip-up.local" die alte Default-Route löschen und eine neue durch ipppX setzen (und umgekehrt bei Beendigung des ISDN-Verbindung).
Mir ist nicht ganz klar, wo in der Datei ich das tun müßte. Könntest Du mir die entsprechende Stelle zeigen?
Wo? Du hast AFAIR nicht geschrieben, welche SuSE-Version du benutzt,
aber im "Auslieferungszustand" existieren AFAIK "/etc/ppp/ip-up.local"
und "/etc/ppp/ip-down.local" noch gar nicht und müssen erst angelegt
werden. Und da würde ich es dann oben reinschreiben... ;-)
Aber warte mal -- vieleicht ist das gar nicht nötig. Der 'smpppd', der
von 'kinternet' und Konsorten verwendet wird, übergibt dem '(i)pppd'
die Option "replacedefaultroute", wenn die Option "defaultroute" in
der Konfiguration gesetzt ist. Sieh mal nach, ob du in der
Konfiguration der ISDN-Verbindung mit 'yast2' irgendwo ein Häkchen
"Default-Route" o.ä. setzen kannst.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Wo? Du hast AFAIR nicht geschrieben, welche SuSE-Version du benutzt, aber im "Auslieferungszustand" existieren AFAIK "/etc/ppp/ip-up.local" und "/etc/ppp/ip-down.local" noch gar nicht und müssen erst angelegt werden. Und da würde ich es dann oben reinschreiben... ;-)
Ich benutze Suse 8.2. und diese Dateien existieren tatsächlich nicht. Was müßte ich denn genau dort reinschreiben wenn ich die Dateien anlege?
Aber warte mal -- vieleicht ist das gar nicht nötig. Der 'smpppd', der von 'kinternet' und Konsorten verwendet wird, übergibt dem '(i)pppd' die Option "replacedefaultroute", wenn die Option "defaultroute" in der Konfiguration gesetzt ist. Sieh mal nach, ob du in der Konfiguration der ISDN-Verbindung mit 'yast2' irgendwo ein Häkchen "Default-Route" o.ä. setzen kannst.
Die ISDN Verbindung ist und war im Yast2 als Standard Route eingestellt. Das bringt leider keine Veränderung Bei einem anderen Rechner hat die Einrichtung über Yast2auf Anhieb funktioniert. Ich weiß nicht, warum das jetzt bei mir nicht klappt. Da bin ich auf eure Hilfe angewiesen. Christian
Ikarus GuardNT hat dieses eMail auf Viren und Trojaner untersucht. Nichts Verdächtiges gefunden. keine Anlagen gefunden ------------------------------------------------------- Hallo Christian, kannst du mir mal den Anfang deines Problems nochma schicken, ich bin neu dabei, hatte aber so was ähnliches auch mal, vielleicht kann ich dir helfen Gruß Michael -----Ursprüngliche Nachricht----- Von: Christian Wolter [mailto:su98oc5@gmx.de] Gesendet: Sonntag, 8. Februar 2004 10:38 An: suse-linux@suse.com Betreff: Re: kinternet: ipp0/eth0-Verwechselung? Ikarus GuardNT hat dieses eMail auf Viren und Trojaner untersucht. Nichts Verdächtiges gefunden. keine Anlagen gefunden -------------------------------------------------------
Wo? Du hast AFAIR nicht geschrieben, welche SuSE-Version du benutzt, aber im "Auslieferungszustand" existieren AFAIK "/etc/ppp/ip-up.local" und "/etc/ppp/ip-down.local" noch gar nicht und müssen erst angelegt werden. Und da würde ich es dann oben reinschreiben... ;-)
Ich benutze Suse 8.2. und diese Dateien existieren tatsächlich nicht. Was müßte ich denn genau dort reinschreiben wenn ich die Dateien anlege?
Aber warte mal -- vieleicht ist das gar nicht nötig. Der 'smpppd', der von 'kinternet' und Konsorten verwendet wird, übergibt dem '(i)pppd' die Option "replacedefaultroute", wenn die Option "defaultroute" in der Konfiguration gesetzt ist. Sieh mal nach, ob du in der Konfiguration der ISDN-Verbindung mit 'yast2' irgendwo ein Häkchen "Default-Route" o.ä. setzen kannst.
Die ISDN Verbindung ist und war im Yast2 als Standard Route eingestellt. Das bringt leider keine Veränderung Bei einem anderen Rechner hat die Einrichtung über Yast2auf Anhieb funktioniert. Ich weiß nicht, warum das jetzt bei mir nicht klappt. Da bin ich auf eure Hilfe angewiesen. Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
wie kann kann ich den html editor quanta von kde so konfigurieren, dass er bei dem kontext-menu für php-includes gleich das entsprechdende file öffnet, ohne in den file-brower zu springen, um den pfad zum file zu bekommen. der pfad zum file ist ja in dem php-dokument angegeben, so bräuchte es doch keinen dialog mit dem file-browser von kde mehr. oder gibt es da gar keine möglichkeit dass zum konfigurieren? die quanta version ist 3.1.4 auf KDE 3.1.4
Am Son 08.02.04 um 10:49 CET schrieb Andreas Waaser
wie kann kann ich den html editor quanta von kde so konfigurieren, dass er bei dem kontext-menu für php-includes gleich das entsprechdende file öffnet, ohne in den file-brower zu springen, um den pfad zum file zu bekommen. der pfad zum file ist ja in dem php-dokument angegeben, so bräuchte es doch keinen dialog mit dem file-browser von kde mehr.
oder gibt es da gar keine möglichkeit dass zum konfigurieren?
die quanta version ist 3.1.4 auf KDE 3.1.4
Also meine Bleeding Edge Version macht das genauso wie du's gern hättest. -- begin LOVE-LETTER-FOR-YOU.txt.vbs end Gegen Nichtstandardkonforme Software! http://piology.org/ILOVEYOU-Signature-FAQ.html
* Sonntag, 08. Februar 2004 um 10:37 (+0100) schrieb Christian Wolter:
Ich benutze Suse 8.2. und diese Dateien existieren tatsächlich nicht. Was müßte ich denn genau dort reinschreiben wenn ich die Dateien anlege?
Ich kann es aber nur "schmutzig" ;-) #!/bin/sh # # /etc/ppp/ip-up.local # /sbin/ip route replace default via $5 dev $1 # Ende. und #!/bin/sh # # /etc/ppp/ip-down.local # /etc/sysconfig/network/scripts/ifup-route eth0 # Ende. Nicht vergessen, beide Dateien für root ausführbar zu machen. Falls es nicht funktioniert, poste bitte die Ausgaben von 'ifconfig' und 'route -n' jeweils für einen Zeitpunkt vor, während und nach der ISDN-Verbindung. Das nächste Problem wird vermutlich die SuSE-Firewall sein. Damit kenne ich mich aber nicht aus.
Die ISDN Verbindung ist und war im Yast2 als Standard Route eingestellt. Das bringt leider keine Veränderung
Steht in der Datei
"/etc/sysconfig/network/providers/<Deine ISDN-Verbindung>" ein
"DEFAULTROUTE='yes'"?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Wenn ich den Rechner jetzt hochfahre, ohne das die Netzwerkkarte eingesteckt ist funktioniert es. Sonst baut er zwar eine Verbindung auf, geht aber über die Netzwerkkarte (s. Log unten). Das ist aber zumindest eine Lösung, mit der ich leben könnte.
Steht in der Datei "/etc/sysconfig/network/providers/<Deine ISDN-Verbindung>" ein "DEFAULTROUTE='yes'"?
In /etc/sysconfig/network/isdn/cfg-net0 steht "DEFAULTROUTE='yes'"
Falls es nicht funktioniert, poste bitte die Ausgaben von 'ifconfig' und 'route -n' jeweils für einen Zeitpunkt vor, während und nach der ISDN-Verbindung.
eth0 Protokoll:Ethernet Hardware Adresse 00:50:BF:90:0E:E9 inet Adresse:192.168.0.2 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::250:bfff:fe90:ee9/64 Gültigkeitsbereich:Verbindung UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:381 errors:0 dropped:0 overruns:0 frame:0 TX packets:409 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:206231 (201.3 Kb) TX bytes:51816 (50.6 Kb) Interrupt:11 Basisadresse:0x5000 ippp0 Protokoll:Punkt-zu-Punkt Verbindung UP PUNKTZUPUNKT RUNNING NOARP DYNAMIC MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:30 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) lo Protokoll:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:96 errors:0 dropped:0 overruns:0 frame:0 TX packets:96 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:7780 (7.5 Kb) TX bytes:7780 (7.5 Kb) dhcppc1:/home/chris # ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:50:BF:90:0E:E9 inet Adresse:192.168.0.2 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::250:bfff:fe90:ee9/64 Gültigkeitsbereich:Verbindung UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:386 errors:0 dropped:0 overruns:0 frame:0 TX packets:413 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:206819 (201.9 Kb) TX bytes:52079 (50.8 Kb) Interrupt:11 Basisadresse:0x5000 ippp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:134.147.36.190 P-z-P:134.147.214.254 Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP DYNAMIC MTU:1500 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:30 RX bytes:194 (194.0 b) TX bytes:253 (253.0 b) lo Protokoll:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:96 errors:0 dropped:0 overruns:0 frame:0 TX packets:96 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:7780 (7.5 Kb) TX bytes:7780 (7.5 Kb) dhcppc1:/home/chris # ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:50:BF:90:0E:E9 inet Adresse:192.168.0.2 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::250:bfff:fe90:ee9/64 Gültigkeitsbereich:Verbindung UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:530 errors:0 dropped:0 overruns:0 frame:0 TX packets:552 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:370742 (362.0 Kb) TX bytes:66853 (65.2 Kb) Interrupt:11 Basisadresse:0x5000 lo Protokoll:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:106 errors:0 dropped:0 overruns:0 frame:0 TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:8692 (8.4 Kb) TX bytes:8692 (8.4 Kb) dhcppc1:/home/chris # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 dhcppc1:/home/chris # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 134.147.214.254 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 dhcppc1:/home/chris # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 dhcppc1:/home/chris #
* Sonntag, 08. Februar 2004 um 18:05 (+0100) schrieb Christian Wolter:
Wenn ich den Rechner jetzt hochfahre, ohne das die Netzwerkkarte eingesteckt ist funktioniert es. Sonst baut er zwar eine Verbindung auf, geht aber über die Netzwerkkarte (s. Log unten).
Ja, das ist logisch: Kein Netzwerkkabel -> kein DHCP-Server erreichbar -> keine Default-Route, die ersetzt werden muss.
dhcppc1:/home/chris # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 134.147.214.254 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Hier sind aber die beiden Dateien "/etc/ppp/ip-{up,down}.local" noch
nicht angelegt worden, oder?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
dhcppc1:/home/chris # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 134.147.214.254 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Hier sind aber die beiden Dateien "/etc/ppp/ip-{up,down}.local" noch nicht angelegt worden, oder?
Doch, beide Dateien sind so angelegt, wie Du es beschrieben hattest. Christian
* Montag, 09. Februar 2004 um 17:47 (+0100) schrieb Christian Wolter:
Hier sind aber die beiden Dateien "/etc/ppp/ip-{up,down}.local" noch nicht angelegt worden, oder?
Doch, beide Dateien sind so angelegt, wie Du es beschrieben hattest.
Es sieht aber so aus, als wenn "/etc/ppp/ip-up.local" nicht ausgeführt
wurde. Sind die beiden Dateien ausführbar ('ls -l /etc/ppp/*.local')?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Es sieht aber so aus, als wenn "/etc/ppp/ip-up.local" nicht ausgeführt wurde. Sind die beiden Dateien ausführbar ('ls -l /etc/ppp/*.local')?
Waren sie nicht. Jetzt sind sie es und es funktioniert!!! Nur wenn ich die ISDN Verbindung jetzt trenne, habe ich keine Verbindung mehr zum Internet (über Konqueror oder kmail während kopete eingeloggt bleibt). Scheinbar "vergisst" er den Gateway: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 vor der ISDN Verbindung: Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 Christian
* Montag, 09. Februar 2004 um 20:30 (+0100) schrieb Christian Wolter:
Jetzt sind sie es und es funktioniert!!!
Nur wenn ich die ISDN Verbindung jetzt trenne, habe ich keine Verbindung mehr zum Internet (über Konqueror oder kmail während kopete eingeloggt bleibt). Scheinbar "vergisst" er den Gateway:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Hm, vermutlich passt das 'ifup-route eth0' in "ip-down.local" nicht zu
deiner Konfiguration. Ich verstehe aber auch (noch) nicht, welches der
Skripte unter "/etc/sysconfig/" in welcher Reihenfolge bei welcher
Konfiguration ausgeführt werden...
Ich habe mal zwei Dateien angehängt, die das auf die "alte", aber
universelle Weise erledigen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Ich habe mal zwei Dateien angehängt, die das auf die "alte", aber universelle Weise erledigen.
Vielen Dank mit diesen Dateien funktioniert es. Nur noch eine Verständnisgfrage: Was machen die von Dir geschickten Dateien anders, als die ursprünglich vom mit angelegten? Was meinst Du mit "alter universeller Weise"? Nochmals vielen Dank für Deine Hilfe!!! Christian
* Dienstag, 10. Februar 2004 um 18:34 (+0100) schrieb Christian Wolter:
Nur noch eine Verständnisgfrage: Was machen die von Dir geschickten Dateien anders, als die ursprünglich vom mit angelegten? Was meinst Du mit "alter universeller Weise"?
Die wesentliche Änderung liegt in 'ip-down.local': Bei der ersten
Version habe ich eines der SuSE-Konfigurations-Skripte angegeben, in
der Hoffnung, dass es die alte Default-Route aus irgendwelchen
Konfigurationsdateien restauriert. Das hat es aber nicht getan,
wahrscheinlich weil es das unpassende Konfigurations-Skript für deinen
Fall war (DHCP). (D.h. mit einem der anderen Konfigurations-Skripte
würde es vermutlich auch funktionieren, ich weiss aber nicht mit
welchem...)
Die letzte, funktionierende Version verzichtet vollständig auf
SuSE-Skripte und -Konfigurationsdateien. In 'ip-up-local' wird vor dem
Verändern der Default-Route die alte Default-Route in eine temporäre
Datei gesichert und in 'ip-down.local' mit Hilfe dieser temporären
Datei wieder restauriert.
"Alt" bezieht sich dabei auf die Zeit vor distributionsspezifischen
Skripten und Konfigurationsdateien und "universell" auf den Einsatz
von 'ip', einem Tool, das auf jedem Linux-System zur Verfügung stehen
sollte.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (6)
-
Andreas Koenecke -
Andreas Waaser -
Christian Wolter -
Michael Hellmuth -
Michael Uhl -
Stefan Heinrichsen