Hallo, ich habe ein Problem mit der Einrichtung eines Dial-In Zugangs. Ich benutze die 8.2er und bin der Anleitung von http://www.linuxnetmag.com/de/issue8/m8dialin1.html soweit gefolgt. Ziel ist es, dass ich mich via ISDN in meinen SuSE-Rechner einwählen kann und Zugang zu meinem Netz habe sowie über diese ISDN-Leitung auch surfen kann (der SuSE-Rechner hat dann natürlich eine Internetverbindung via eth1). Yast2 bediene ich nur über Konsole (ssh), nicht grafisch, da kein X installiert ist. Ich weiss nicht, wie es sich im Normalfall verhalten soll, aber für meine beiden ippp-interfaces erstellt yast2 immer nur eine options-Datei. Bei früheren Versionen von SuSE (7.2) kam bei mehreren interfacen jeweils eine options.<interface> dazu. Laut dem Artikel vom NetMag sollte ja eigentlich auch hier von YaST2 eine solche Datei angelegt werden. In meinem Fall wäre das dann ja wohl die options.ippp1 eventuell dahinter dann noch den Providernamen (options.ippp1.dialin). Nur, wie schon gesagt, leider übernimmt yast2 das nicht und ich stehe ohne diese Datei da. Ändere ich in der /etc/ppp/options einen Eintrag (debug-modus aktivieren z.B.), führt der pppd (?) alles korrekt aus und liefert debug-Meldungen, natürlich erst nach einem restart des isdn-Systems mit rcisdn restart sowie rcnetwork restart. Lege ich die Datei /etc/ppp/options.ippp1 von Hand an, killt mir yast2 die Datei, bzw. SuSEconfig killt sie, sobald es aufgerufen wird. Auch nach einem restart beider Dienste (isdn & network) wird die Datei überhaupt nicht beachtet. Zur Not habe ich nun in der Datei /etc/sysconfig/isdn/cfg-net1 den Parameter IPPPD_OPTIONS="noccp ms-dns 192.168.28.1 auth +pap +chap proxyarp" gesetzt. Damit läuft jetzt wenigstens die User-Authentifizierung. "noccp" habe ich gesetzt, weil compression eh nicht klappt und nur Fehlermeldungen beim connect bringt. "proxyarp" bringt leider auch nur eine Fehlermeldung, dass die IP nicht aufgelöst werden konnte... "Cannot determine ethernet address for proxy ARP" Allerdings bin ich der Meinung, proxyarp unbedingt zu benötigen, wie im NetMag beschrieben ist, um die Routing Funktionalitäten herzustellen. Hier noch ein paar Log-Auszüge mit der entsprechenden proxyarp-Fehlermeldung. Ist denke ich aber alles etwas weniger wichtig, denn wenn Ihr mir helfen könntet, die Datei options.ippp1 endlich gelesen wird, hoffe ich schon sehr viel weiter zu kommen. Habe ich irgendetwas wichtiges vergessen? Ich hoffe nicht, ansonsten fragt bitte nach. Danke schon mal für Eure Hilfe! Michael ============================================ Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 * Call to tei 127 from 20 on 22 RING (Data) Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 Call to tei 70 from 20 on 22 CONNECT (Data) Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 Call to tei 70 from 20 on 22 INTERFACE ippp1 called by 20 Aug 10 13:31:08 stargate kernel: ippp1: call from 20 -> 22 accepted Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 tei 72 calling ? with ? Time:Sun Aug 10 13:30:00 2003 Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 tei 72 calling 22 with ? COLP 22 Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 tei 72 calling 22 with ? CONNECT Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 Call to tei 70 from 20 on 22 INTERFACE ippp1 called by 20 Aug 10 13:31:08 stargate kernel: isdn_net: ippp1 connected Aug 10 13:31:08 stargate ipppd[13872]: Local number: 22, Remote number: , Type: incoming Aug 10 13:31:08 stargate ipppd[13872]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 1, linkunit: 0, fd: 7 Aug 10 13:31:08 stargate ipppd[13872]: MPPP negotiation, He: No We: No Aug 10 13:31:08 stargate kernel: Received CCP frame from peer slot(1) Aug 10 13:31:08 stargate kernel: [1/1].ccp-rcv[0]: 01 04 00 0a 12 06 00 00 00 01 Aug 10 13:31:08 stargate ipppd[13872]: local IP address 192.168.32.1 Aug 10 13:31:08 stargate ipppd[13872]: remote IP address 192.168.32.200 Aug 10 13:31:08 stargate ipppd[13872]: Cannot determine ethernet address for proxy ARP ============================================
On Fri, Aug 15, 2003 at 03:16:20PM +0200, Michael Ludwig wrote:
Hallo,
ich habe ein Problem mit der Einrichtung eines Dial-In Zugangs. Ich benutze die 8.2er und bin der Anleitung von http://www.linuxnetmag.com/de/issue8/m8dialin1.html soweit gefolgt. Ziel ist es, dass ich mich via ISDN in meinen SuSE-Rechner einwählen kann und Zugang zu meinem Netz habe sowie über diese ISDN-Leitung auch surfen kann (der SuSE-Rechner hat dann natürlich eine Internetverbindung via eth1).
Yast2 bediene ich nur über Konsole (ssh), nicht grafisch, da kein X installiert ist. Ich weiss nicht, wie es sich im Normalfall verhalten soll, aber für meine beiden ippp-interfaces erstellt yast2 immer nur eine options-Datei. Bei früheren Versionen von SuSE (7.2) kam bei mehreren interfacen jeweils eine options.<interface> dazu.
Die wurden abgeschafft, dafür wurde IPPPD_OPTIONS eingeführt. Das Problem mit den /etc/ppp/options.xxx Dateien war, das sie dem Konzept, mehrere alternative Provider über ein Interface zu unterstützen teilweise entgegen standen.
Laut dem Artikel vom NetMag sollte ja eigentlich auch hier von YaST2 eine solche Datei angelegt werden. In meinem Fall wäre das dann ja wohl die options.ippp1 eventuell dahinter dann noch den Providernamen (options.ippp1.dialin). Nur, wie schon gesagt, leider übernimmt yast2 das nicht und ich stehe ohne diese Datei da.
Ändere ich in der /etc/ppp/options einen Eintrag (debug-modus aktivieren z.B.), führt der pppd (?) alles korrekt aus und liefert debug-Meldungen, natürlich erst nach einem restart des isdn-Systems mit rcisdn restart sowie rcnetwork restart.
Lege ich die Datei /etc/ppp/options.ippp1 von Hand an, killt mir yast2 die Datei, bzw. SuSEconfig killt sie, sobald es aufgerufen wird. Auch nach einem restart beider Dienste (isdn & network) wird die Datei überhaupt nicht beachtet.
Zur Not habe ich nun in der Datei /etc/sysconfig/isdn/cfg-net1 den Parameter IPPPD_OPTIONS="noccp ms-dns 192.168.28.1 auth +pap +chap proxyarp" gesetzt. Damit läuft jetzt wenigstens die User-Authentifizierung. "noccp" habe ich gesetzt, weil compression eh nicht klappt und nur Fehlermeldungen beim connect bringt.
"proxyarp" bringt leider auch nur eine Fehlermeldung, dass die IP nicht aufgelöst werden konnte... "Cannot determine ethernet address for proxy ARP"
proxyarp geht nur wenn die interface adresse zugeordnet werden kann, deshalb muss sie im selben netzwerk liegen und eindeutig bei mehreren ethX sein. Am Besten man verwendet für das IPPP Device die selbe Adresse wie für das eth0.
Allerdings bin ich der Meinung, proxyarp unbedingt zu benötigen, wie im NetMag beschrieben ist, um die Routing Funktionalitäten herzustellen.
Proxy ARP ist eigentlich nur ein workaround, besser man setzt gleich ein richtiges Routing auf, d.h der default gateway des Netzwerks hat eine Route über diesen Einwahlrechner zu den remote clients. Wenn der Rechner selbst das default GW ist, besteht keine Notwendigkeit für ProxyARP.
Hier noch ein paar Log-Auszüge mit der entsprechenden proxyarp-Fehlermeldung. Ist denke ich aber alles etwas weniger wichtig, denn wenn Ihr mir helfen könntet, die Datei options.ippp1 endlich gelesen wird, hoffe ich schon sehr viel weiter zu kommen.
Wie gesagt IPPPD_OPTIONS bewirkt das selbe. -- Karsten Keil SuSE Labs ISDN development
Hallo Karsten, danke für Deine Antwort, Karsten Keil [mailto:kkeil@suse.de] schrieb am August 15, 2003 3:56 PM:
"proxyarp" bringt leider auch nur eine Fehlermeldung, dass die IP nicht aufgelöst werden konnte... "Cannot determine ethernet address for proxy ARP"
proxyarp geht nur wenn die interface adresse zugeordnet werden kann, deshalb muss sie im selben netzwerk liegen und eindeutig bei mehreren ethX sein. Am Besten man verwendet für das IPPP Device die selbe Adresse wie für das eth0.
Proxy ARP ist eigentlich nur ein workaround, besser man setzt gleich ein richtiges Routing auf, d.h der default gateway des Netzwerks hat eine Route über diesen Einwahlrechner zu den remote clients.
Okay, also benötige ich das wohl nicht. Ich habe verschiedene Netze eingerichtet. eth0: das eigentliche Netzwerk, in dem Server & Clients laufen eth1: Karte für T-DSL ippp0: ISDN-Dial-out für Notfall ippp1: ISDN-Dial-in für "mobiles" arbeiten. Folgende Netze habe ich entsprechend: eth0: 192.168.28.1 eth1: 192.168.34.1 ippp0: DYNIP ippp1: 192.168.32.1 wobei der angewähle Rechner die 192.168.32.200 zugewiesen bekommt. Mein routing sieht im Moment so aus: stargate:/ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 217.5.98.92 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.32.200 0.0.0.0 255.255.255.255 UH 0 0 0 ippp1 192.168.34.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.28.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 217.5.98.92 0.0.0.0 UG 0 0 0 ppp0 stargate:/ # Nun müsste ich, um proxyarp zu umgehen, verständlicherweise eine Route vom 32er-Netz ins Netz 0.0.0.0 erstellen. Meine Idee wäre nun: stargate:/ # route add -net 0.0.0.0 gw 192.168.28.1 netmask 0.0.0.0 ippp1 SIOCADDRT: Network is unreachable Um das routing vom dial-in-rechner korrekt laufen zu lassen. Aber da ist ja nun anscheinend ein Fehler drin.
Wenn der Rechner selbst das default GW ist, besteht keine Notwendigkeit für ProxyARP.
Ja, wie Du oben schon ähnlich geschrieben hast. Aber da jedes interface ein eigenes Netz hat, muss ja geroutet werden. Doch wieso nimmt er die route von oben nicht? Wo liegt mein Denkfehler? Wähle ich mich ein, bekomme ich korrekt meine IP und den DNS Server (192.168.32.200 meine IP während ISDN-Dial-in und 192.168.28.1 DNS-Server & GW) zugewiesen. Ich kann ich das GW auf der 192.168.28.1 anpingen, doch einen Rechner im Netz 192.168.28.0/24 leider nicht. Any hints?? Michael Hallo Karsten, danke für Deine Antwort, Karsten Keil [mailto:kkeil@suse.de] schrieb am August 15, 2003 3:56 PM:
"proxyarp" bringt leider auch nur eine Fehlermeldung, dass die IP nicht aufgelöst werden konnte... "Cannot determine ethernet address for proxy ARP"
proxyarp geht nur wenn die interface adresse zugeordnet werden kann, deshalb muss sie im selben netzwerk liegen und eindeutig bei mehreren ethX sein. Am Besten man verwendet für das IPPP Device die selbe Adresse wie für das eth0.
Proxy ARP ist eigentlich nur ein workaround, besser man setzt gleich ein richtiges Routing auf, d.h der default gateway des Netzwerks hat eine Route über diesen Einwahlrechner zu den remote clients.
Okay, also benötige ich das wohl nicht. Ich habe verschiedene Netze eingerichtet. eth0: das eigentliche Netzwerk, in dem Server & Clients laufen eth1: Karte für T-DSL ippp0: ISDN-Dial-out für Notfall ippp1: ISDN-Dial-in für "mobiles" arbeiten. Folgende Netze habe ich entsprechend: eth0: 192.168.28.1 eth1: 192.168.34.1 ippp0: DYNIP ippp1: 192.168.32.1 wobei der angewähle Rechner die 192.168.32.200 zugewiesen bekommt. Mein routing sieht im Moment so aus: stargate:/ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 217.5.98.92 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.32.200 0.0.0.0 255.255.255.255 UH 0 0 0 ippp1 192.168.34.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.28.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 217.5.98.92 0.0.0.0 UG 0 0 0 ppp0 stargate:/ # Nun müsste ich, um proxyarp zu umgehen, verständlicherweise eine Route vom 32er-Netz ins Netz 0.0.0.0 erstellen. Meine Idee wäre nun: stargate:/ # route add -net 0.0.0.0 gw 192.168.28.1 netmask 0.0.0.0 ippp1 SIOCADDRT: Network is unreachable Um das routing vom dial-in-rechner korrekt laufen zu lassen. Aber da ist ja nun anscheinend ein Fehler drin.
Wenn der Rechner selbst das default GW ist, besteht keine Notwendigkeit für ProxyARP.
Ja, wie Du oben schon ähnlich geschrieben hast. Aber da jedes interface ein eigenes Netz hat, muss ja geroutet werden. Doch wieso nimmt er die route von oben nicht? Wo liegt mein Denkfehler? Wähle ich mich ein, bekomme ich korrekt meine IP und den DNS Server (192.168.32.200 meine IP während ISDN-Dial-in und 192.168.28.1 DNS-Server & GW) zugewiesen. Ich kann ich das GW auf der 192.168.28.1 anpingen, doch einen Rechner im Netz 192.168.28.0/24 leider nicht. Any hints?? Michael
participants (2)
-
Karsten Keil
-
Michael Ludwig