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