Und wieder Probleme mit T-DSL
Hallo Ihr, ich habe mir am Wochenende Suse Linux 7.1 besorgt, um einen hier herumstehenden Rechner zum Internet-Router auf Linux-Basis (unter Windoof 98 funktioniert alles bestens) umzufunktionieren. Mit seiner Hilfe soll einmal ein kleines aus 4 Rechnern bestehendes Netzwerk via DSL ins Internet gelangen können. Leider ist es mir bisher nicht gelungen, überhaupt den Gateway-Rechner ins Internet zu bekommen. Auf diesem benutze ich einen 2.4'er Kernel und die aktuelle PPP- (ppp-2.4.0-5) und PPPOED-Version (pppoed-0.48b1-6). Laut Suse-SDB soll so ja eine DSL-Verbindung auch unter 2.4 möglich sein. Leider ist daß bei mir nicht der Fall. Ein "ping" auf eine beliebige nicht im lokalen Netz gelegene Adresse erbringt immer ein "Destination host unreachable!" Ein Aufruf von ifconfig ergibt: eth0 Link encap:Ethernet HWaddr 00:00:21:29:D6:60 inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::2129:d660/10 Scope:Link inet6 addr: fe80::200:21ff:fe29:d660/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:109 errors:0 dropped:0 overruns:0 frame:0 TX packets:117 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x6100 eth1 Link encap:Ethernet HWaddr 00:A0:D2:15:0F:42 inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::a0:d215:f42/10 Scope:Link inet6 addr: fe80::2a0:d2ff:fe15:f42/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:12 Base address:0x6200 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:3792 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 Dieser Ausdruck scheint soweit in Ordnung zu sein, oder? Starte ich nun die DSL-Verbindung mit "rcpppoed restart" erhalte ich in /var/log/messages folgenden Ausdruck: Feb 28 23:45:56 router kernel: eth1: no IPv6 routers present Feb 28 23:45:56 router kernel: eth0: no IPv6 routers present Feb 28 23:45:57 router kernel: eth1: no IPv6 routers present Feb 28 23:45:57 router kernel: eth0: no IPv6 routers present Feb 28 23:52:23 router kernel: PPP generic driver version 2.4.1 Feb 28 23:52:23 router kernel: Registered PPPoX v0.5 Feb 28 23:52:25 router kernel: mssclampfw v1.2 (written by Marc Boucher <marc@mbsi.ca>. Thanks to Rebel.com) Feb 28 23:52:26 router kernel: Registered PPPoE v0.6.4 Feb 28 23:52:26 router pppd[637]: Plugin /usr/lib/pppd/plugins/pppoe.so loaded. Feb 28 23:52:26 router pppd[637]: PPPoE Plugin Initialized Feb 28 23:52:26 router pppd[637]: Plugin /usr/lib/passwordfd.so loaded. Feb 28 23:52:26 router pppd[637]: pppd 2.4.0 started by root, uid 0 Feb 28 23:52:26 router pppd[637]: Sending PADI Erstaunlich finde ich u. a. die Zeilen mit "ethX: no IPv6 routers present". Was ist damit gemeint, ist das schon der Fehler? Auffällig ist außerdem, daß die vom ISP dynamisch zugewiesene Adresse im Log-File nicht auftaucht. Anscheinend hat sich der "pppoed" gar nicht ins Netz eingewählt. Ein Aufruf von route -n 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 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 scheint diesen Verdacht zu bestätigen. Weiß jemand Rat und kann mir doch noch zu einem funktionstüchtigen DSL-Zugang verhelfen? -- Grüße Bernd
Moin, hast Du einmal den rp-pppoe probiert?
Leider ist daß bei mir nicht der Fall. Ein "ping" auf eine beliebige nicht im lokalen Netz gelegene Adresse erbringt immer ein "Destination host unreachable!"
Ein Aufruf von ifconfig ergibt: <--- schnipp ---> <--- /schnipp ---> Dieser Ausdruck scheint soweit in Ordnung zu sein, oder?
Nein, die Netzwerkkarten sollten in anderen Netzen liegen d.h. die dritte Nummer in der IP sollte sich unterscheiden.
Starte ich nun die DSL-Verbindung mit "rcpppoed restart" erhalte ich in /var/log/messages folgenden Ausdruck: <--- schnipp ---> <--- /schnipp ---> Erstaunlich finde ich u. a. die Zeilen mit "ethX: no IPv6 routers present". Was ist damit gemeint, ist das schon der Fehler?
mit dem "neuen" 2.4.x Kernel mußt Du eine Menge module laden um Masqurading aktivieren zu können. (Siehe meine mail von vorhin dort ist auch ein link auf HOWTO's)
Auffällig ist außerdem, daß die vom ISP dynamisch zugewiesene Adresse im Log-File nicht auftaucht. Anscheinend hat sich der "pppoed" gar nicht ins Netz eingewählt. Ein Aufruf von route -n <--- schnipp ---> <--- /schnipp ---> scheint diesen Verdacht zu bestätigen.
wenn Du eingewählt wärst, gäbe es auch ein ppp0 Device :-)
Weiß jemand Rat und kann mir doch noch zu einem funktionstüchtigen DSL-Zugang verhelfen?
schau mal hier: http://www.adsl4linux.de/software/tonline_rp-pppoe.html Dietrich
On 2001.02.28 23:15:14 +0100 Bernd Augustin wrote:
Hallo Ihr,
ich habe mir am Wochenende Suse Linux 7.1 besorgt, um einen hier herumstehenden Rechner zum Internet-Router auf Linux-Basis (unter Windoof 98 funktioniert alles bestens) umzufunktionieren. Mit seiner Hilfe soll einmal ein kleines aus 4 Rechnern bestehendes Netzwerk via DSL ins Internet gelangen können.
Leider ist es mir bisher nicht gelungen, überhaupt den Gateway-Rechner ins Internet zu bekommen. Auf diesem benutze ich einen 2.4'er Kernel und die aktuelle PPP- (ppp-2.4.0-5) und PPPOED-Version (pppoed-0.48b1-6). Laut Suse-SDB soll so ja eine DSL-Verbindung auch unter 2.4 möglich sein.
[...]
Auffällig ist außerdem, daß die vom ISP dynamisch zugewiesene Adresse im Log-File nicht auftaucht. Anscheinend hat sich der "pppoed" gar nicht ins Netz eingewählt. Ein Aufruf von route -n
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 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Hmm, es erscheint mir etwas seltsam, daß beide Netzwerkkarten im gleichen Netz hängen. Des weiteren kann ich kein Defaultgateway finden.
scheint diesen Verdacht zu bestätigen.
Weiß jemand Rat und kann mir doch noch zu einem funktionstüchtigen DSL-Zugang verhelfen?
-- Grüße Bernd
Gruß Jörg -- Dipl.-Ing. Jörg Schütter joerg.schuetter@gmx.de
Hallo,
Hmm, es erscheint mir etwas seltsam, daß beide Netzwerkkarten im gleichen Netz hängen. Des weiteren kann ich kein Defaultgateway finden.
stimmt, an das Default-Gateway hatte ich gar nicht mehr gedacht. Das "Sub-Net" von eth0 (der Karte, an der der NTBBA hängt) hatte ich schon mal auf 100 (192.168.100.1) geändert, aber das half nichts. Wie kann ich denn ein solches Default-Gateway der Routing-Tabelle hinzufügen? -- Bis bald, Bernd
Bernd Augustin schrieb:
Hallo Ihr,
ich habe mir am Wochenende Suse Linux 7.1 besorgt, um einen hier herumstehenden Rechner zum Internet-Router auf Linux-Basis (unter Windoof 98 funktioniert alles bestens) umzufunktionieren. Mit seiner Hilfe soll einmal ein kleines aus 4 Rechnern bestehendes Netzwerk via DSL ins Internet gelangen können.
Leider ist es mir bisher nicht gelungen, überhaupt den Gateway-Rechner ins Internet zu bekommen. Auf diesem benutze ich einen 2.4'er Kernel und die aktuelle PPP- (ppp-2.4.0-5) und PPPOED-Version (pppoed-0.48b1-6). Laut Suse-SDB soll so ja eine DSL-Verbindung auch unter 2.4 möglich sein.
Leider ist daß bei mir nicht der Fall. Ein "ping" auf eine beliebige nicht im lokalen Netz gelegene Adresse erbringt immer ein "Destination host unreachable!"
Ein Aufruf von ifconfig ergibt:
eth0 Link encap:Ethernet HWaddr 00:00:21:29:D6:60 inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::2129:d660/10 Scope:Link inet6 addr: fe80::200:21ff:fe29:d660/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:109 errors:0 dropped:0 overruns:0 frame:0 TX packets:117 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x6100
eth1 Link encap:Ethernet HWaddr 00:A0:D2:15:0F:42 inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::a0:d215:f42/10 Scope:Link inet6 addr: fe80::2a0:d2ff:fe15:f42/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:12 Base address:0x6200
< Rest gesnipt> Hallo Bernd, erstmal eine Änderung, dann nochmal testen: Ein Router steht normalerweise zwischen zwei Netzen. Deine beiden Netzwerkkarten stecken aber im gleichen Netz 192.168.0.X. Setz mal die Karte "nach draussen" auf z.B. 192.168.100.1 Vieleicht war's das ja schon. Tommes
* Mittwoch, 28. Februar 2001 um 23:15 (+0100) schrieb Bernd Augustin:
Leider ist es mir bisher nicht gelungen, überhaupt den Gateway-Rechner ins Internet zu bekommen. Auf diesem benutze ich einen 2.4'er Kernel und die aktuelle PPP- (ppp-2.4.0-5)
Welchen pppd, den "offiziellen" oder den für PPPoE gepatcheten? (Oder ist da gar kein Unterschied mehr?)
und PPPOED-Version (pppoed-0.48b1-6).
Wenn du den gepatchten pppd benutzt, brauchst du den pppoed nicht mehr.
Feb 28 23:45:56 router kernel: eth1: no IPv6 routers present Feb 28 23:45:56 router kernel: eth0: no IPv6 routers present Feb 28 23:45:57 router kernel: eth1: no IPv6 routers present Feb 28 23:45:57 router kernel: eth0: no IPv6 routers present Feb 28 23:52:23 router kernel: PPP generic driver version 2.4.1 Feb 28 23:52:23 router kernel: Registered PPPoX v0.5 Feb 28 23:52:25 router kernel: mssclampfw v1.2 (written by Marc Boucher <marc@mbsi.ca>. Thanks to Rebel.com) Feb 28 23:52:26 router kernel: Registered PPPoE v0.6.4 Feb 28 23:52:26 router pppd[637]: Plugin /usr/lib/pppd/plugins/pppoe.so loaded. Feb 28 23:52:26 router pppd[637]: PPPoE Plugin Initialized
Sieht aus wie der gepatchte pppd...
Feb 28 23:52:26 router pppd[637]: Plugin /usr/lib/passwordfd.so loaded. Feb 28 23:52:26 router pppd[637]: pppd 2.4.0 started by root, uid 0 Feb 28 23:52:26 router pppd[637]: Sending PADI
Das sieht bis hierhin nicht schlecht aus. Wie geht es weiter? Es müsste danach so etwas Ähnliches kommen wie: Mar 3 13:12:36 KoCom pppd[31503]: HOST_UNIQ successful match Mar 3 13:12:36 KoCom pppd[31503]: HOST_UNIQ successful match Mar 3 13:12:36 KoCom pppd[31503]: Got connection: 2b1b Mar 3 13:12:36 KoCom pppd[31503]: Connecting PPPoE socket: 00:d0:ba:70:66:ab 1b2b eth1 0x807cdb8 Mar 3 13:12:36 KoCom pppd[31503]: using channel 30 Mar 3 13:12:36 KoCom pppd[31503]: Using interface ppp0 Mar 3 13:12:36 KoCom pppd[31503]: Connect: ppp0 <--> eth1 [ LCP-Handshake ]
Erstaunlich finde ich u. a. die Zeilen mit "ethX: no IPv6 routers present". Was ist damit gemeint, ist das schon der Fehler?
IMHO nein.
Auffällig ist außerdem, daß die vom ISP dynamisch zugewiesene Adresse im Log-File nicht auftaucht. Anscheinend hat sich der "pppoed" gar nicht ins Netz eingewählt. Ein Aufruf von route -n
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 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
scheint diesen Verdacht zu bestätigen.
Ja, das sehe ich auch so. Das ppp0-Device und die Default-Route werden erst gesetzt, wenn das PPPoE-Handshake erfolgreich war ("Using interface ppp0" im obigen Log). Kommentiere doch einmal das plugin "passwordfd.so" in deiner ppp-Options-Datei aus und starte den pppd mit "pppd eth1". (Wenn deine pppd-Optionen-Datei nicht /etc/ppp/options ist, mit "pppd eth1 file <Pfad zur pppd-Optionen-Datei>".) Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo,
Welchen pppd, den "offiziellen" oder den für PPPoE gepatcheten? (Oder ist da gar kein Unterschied mehr?)
und PPPOED-Version (pppoed-0.48b1-6).
Wenn du den gepatchten pppd benutzt, brauchst du den pppoed nicht mehr. Sieht aus wie der gepatchte pppd...
das habe ich nicht gewußt. Ich habe immer versucht, mit "pppoed start" oder "rcpppoed start" die Verbindung aufzubauen. Das kann dann ja auch nicht klappen. Leider steht das auch nicht in den Artikeln aus der "sdb".
Feb 28 23:52:26 router pppd[637]: Plugin /usr/lib/passwordfd.so loaded. Feb 28 23:52:26 router pppd[637]: pppd 2.4.0 started by root, uid 0 Feb 28 23:52:26 router pppd[637]: Sending PADI
Das sieht bis hierhin nicht schlecht aus. Wie geht es weiter?
Danach kommt leider nichts mehr. Ein Berbingungsaufbau mit obigen Kommandos endet immer mit der Zeile "Sending PADI."
Kommentiere doch einmal das plugin "passwordfd.so" in deiner ppp-Options-Datei aus und starte den pppd mit "pppd eth1". (Wenn deine pppd-Optionen-Datei nicht /etc/ppp/options ist, mit "pppd eth1 file <Pfad zur pppd-Optionen-Datei>".)
Ich werde deinen Tip gleich mal ausprobieren. Mal schauen, was dann passiert. Danke aber schon mal im Voraus. -- Grüße Bernd
Hallo Bernd, Am 03. Mär 2001, 15:06 Uhr schrieb Bernd Augustin:
Danach kommt leider nichts mehr. Ein Berbingungsaufbau mit obigen Kommandos endet immer mit der Zeile "Sending PADI."
Ich weiß zwar nicht, ob dies in diesem Zusammenhang interessant ist: nach Freischaltung meines DSL-Anschlusses im Januar endeten alle Verbindungsaufbauten mit vom Access Concentrator nicht beantworteten Send-PADI-Paketen. Als Grund dafür stellte sich letztlich heraus, daß das Siemens-DSL-"Modem" mit veralteter Firmware ausgeliefert worden war (die drei Dioden auf dem Gerät leuchteten trotzdem grün). Nach Update der Firmware seitens der Telekom traten bis heute keine Fehler mehr auf. HTH Gruß Rudi --
PS.: Don't drink as root! Das kann man gar nicht oft genug sagen: "uups, rm -rf * statt rm -rf *~ in /etc", das war eine Meisterleistung nachts um 3 mit 2.6 auf dem Turm ;-)) [Volker Müller und Thomas Bendler in suse-linux]
Hallo Liste, nach dem ich nun ca. eine Woche lang versuchte haben, meine Linux-Kiste dazu zu bewegen, endlich auch via T-DSL ins I-Netz zu gehen, habe ich es endlich geschafft. Das Problem waren nicht die Einstellung der Konfigurationsdateien für den pppoed, oder die route.conf, sonder die Zuordung der Karten. Ich hatte unter Yast2 die Allied-TeleSyn (die Karte, an der der NTBBA hängt) als eth0 eingetragen und die zweite Karte ins interne Netz als eth1. Alle Konfigurationsdateien basierten auf dieser Zuordnung. Beide Karten benutzen allerdings den RealTek 8029 und das scheint unter Yast2 zu Problemen bei der Kartenzuordnung geführt zu haben. Die Zuordnung wurden schlicht vertauscht, so daß die Allied-TeleSyn als eth1 und die interne Karte als eth0 eingetragen wurden. Da die Konfigurationsdateien auf einer anderen Zuordnung basierten, konnte eine Kommunikation Allied-TeleSyn<->NTBBA gar nicht zustande kommen. Als ich dies einmal heraus und die Einstellung entsprechend angepaßt hatte, klappte der Verbindungsaufbau auf anhieb ;-)). -- Bis bald, Bernd
participants (6)
-
Andreas Koenecke -
Bernd Augustin -
Dietrich Heise -
Jörg Schütter -
Rudolf Buerger -
Thomas Grotevent