Siehe zu dieser Frage den Abschnitt in async PPP: asyncppp_whichppp.
Zum Kompilieren des Kernels mit dem in ISDN4LINUX enthaltenen syncPPP musst Du bei der Konfiguration die entsprechenden Fragen mit 'yes' beantworten. Vergiss nicht, da{[szlig ]} das Modul slhc.o vor dem Modul isdn.o geladen werden muss, wenn die VJ-Kompression nicht in den Kernel eingebunden wurde, wenn Du z.B. kein PPP und kein CSLIP im Kernel hast. Der Gebrauch von VJ-Kompression ist bei {[auml ]}lteren Kernels problematisch und funktioniert nicht verl{[auml ]}{[szlig ]}lich - die Unterst{[uuml ]}tzung daf{[uuml ]}r sollte jedoch trotzdem im Kernel vorhanden sein, da es sonst zu Nebenwirkungen kommen kann.
Der Name des Netzwerk-Interfaces sollte immer mit 'ippp'
beginnen, nicht mit 'syncppp' oder 'isdn', da in diesem Fall
die Verst{[auml ]}ndigung mit dem ipppd nicht ordentlich funktionieren
wird. Es sollte also mindestens ein 'ippp0' vorhanden sein
sonst wird der ipppd nicht starten. {[Uuml ]}berpr{[uuml ]}fe Deine
Interfaces mit dem Befehl ifconfig
.
Synchronous PPP ist einfach eine weitere encapsulation f{[uuml ]}r ISDN4LINUX. Diese encapsulation wird 'syncppp' genannt. Hier folgt ein Beispiel zur Konfiguration des link level device ippp0:
/sbin/isdnctrl addif ippp0 /sbin/isdnctrl encap ippp0 syncppp
Beachte bitte, da{[szlig ]} syncppp sehr sensibel in Bezug auf die Benennung der Devices reagiert. Es funktionieren nur Devices deren Bezeichnung mit 'ippp'beginnt. Zumindest ein Interface sollte den Namen 'ippp0' haben (siehe Frage syncppp_netinterface).
Alle in Gebrauch befindlichen ippp*-Devices m{[uuml ]}ssen separat konfiguriert werden. Jedes ippp*-Device sollte mit einer eigenen IP-Addresse versehen werden (routing!). Mehrere ippp*-Devices k{[ouml ]}nnen einer einzelnen MSN zugeordnet werden. Dann k{[ouml ]}nnen mehrere Anrufer diese MSN gleichzeitig nutzen.
Zum Gebrauch dieser Devices ben{[ouml ]}tigst Du das Programm ipppd
,
das Du konfigurieren musst. ipppd muss nach dem Installieren der
Module einmal gestartet werden und dann kontinuierlich laufen, um das
Hinaus- und Hineinw{[auml ]}hlen zu erm{[ouml ]}glichen. Es kommuniziert mit
den ISDN4LINUX link level devices durch /dev/ippp0
bis
/dev/ippp63
. Ein einzelnes ipppd kann mit allen Devices
zugleich arbeiten. Wenn Du zwei PPP-Verbindungen zugleich brauchst,
musst Du ipppd an zwei Devices binden, usw. Dadurch stellt ipppd
das Netzwerk-Device ippp0
zur Verf{[uuml ]}gung, das mit
ifconfig
{[uuml ]}berpr{[uuml ]}ft werden kann (obwohl es den
gleichen Namen tr{[auml ]}gt, darf das Netzwerk-Device ippp0
nicht
mit /dev/ippp0
verwechselt werden, das zur Kommunikation
zwischen ipppd und dem link level verwendet wird).
ipppd hat eine weitere Option: 'useifip' benutzt die IP-Addresse des verbundenen Netzwerk-Interfaces (wenn diese nicht 0.0.0.0 lautet. Sogar dann versucht ipppd, die Point-to-Point-Addresse als remote IP zu benutzen). Zu Anfang solltest Du alle Kompressionsoptionen deaktivieren (lzs/stac, bsd, van jacobson), sp{[auml ]}ter kannst Du versuchen, sie zu aktivieren (siehe Frage syncppp_compression).
Es ist sehr wichtig, die Authentifikations-Informationen sauber einzustellen. Unsaubere Authentifikation ist das vermutlich meist beschriebene Problem in der Mailingliste. Arbeite bitte erst selbst den Abschnitt pap komplett durch, bevor Du andere um Hilfe bittest.
In dem Paket isdn4kernel-util findest Du ein Konfigurationsbeispiel in
der Datei etc/rc.isdn.syncppp
.
Mit mehreren ipppd-Instanzen k{[ouml ]}nnen verschiedene Konfigurationen
erstellt werden. Dazu dient der Befehl 'isdnctrl pppbind'
. Normalerweise sollte der gesamte Verkehr {[uuml ]}ber einen ipppd
laufen. Die Einrichtung von mehreren ipppds ist wirklich nur
empfehlenswert, wenn mehrere verschiedene Kofigurationen ben{[ouml ]}tigt
werden.
Wenn Du die Option defaultroute
angegeben hast, wartest Du ein
paar Sekunden und kannst dann pr{[uuml ]}fen, ob die default route
existiert. Eine weitere M{[ouml ]}glichkeit besteht durch die Option
useifip
. Du findest dann im syslog Eintr{[auml ]}ge wie
"Local IP: x.y.z.a"
und/oder "Remote IP:
x.y.z.a"
. In beiden F{[auml ]}llen besteht eine Verbindung.
Lass Dir eine Login-Prozedur im 'Debug-Log' protokollieren und suche danach, welche Optionen der andere Computer ablehnt. Danach konfigurierst Du ipppd ohne diese nicht ben{[ouml ]}tigten Optionen. Ein Seiteneffekt ist, da{[szlig ]} solche unben{[ouml ]}tigten Optionen die Redundanz vergr{[ouml ]}{[szlig ]}ern (wenn der andere Computer z.B. Fehler hat und die Optionen nicht korrekt ablehnt). Wie Du ein Logfile erstellst siehst Du in syncppp_log.
Du musst ein Netzwerk-Interface explizit an ein ippp Device binden, mit dem Du einen f{[uuml ]}r dieses Interface individuell eingestellten ipppd verbinden kannst. Mit dem (leider schlecht dokumentierten) Befehl
isdnctrl pppbind {[lt ]}interface{[gt ]} {[lt ]}Number{[gt ]}
Zuerst musst Du wissen, wie ipppd seine Daten bekommt. Alle Daten, die {[uuml ]}ber die ISDN-Leitung hereinkommen, werden von den Netzwerk-Devices empfangen, die mit isdnctrl eingestellt werden. Dann werden die Daten an eines der Devices /dev/ippp* {[uuml ]}bergeben - an eines, an dem der Systemdienst ipppd auf Daten wartet.
Was die Netzwerk-Interfaces betrifft, so k{[ouml ]}nnen alle ipppds die gerade eingegangenen Daten behandeln. Daher ist es normalerweise unm{[ouml ]}glich, vorherzusagen, welcher ipppd Daten von welchem Netzwerk-Interface empfangen wird.
In der Praxis installierst Du normalerweise mehrere ipppds mit unterschiedlichen Einstellungen. Jeder davon sollte Daten ausschlie{[szlig ]}lich von einem bestimmten Netzwerk-Interface empfangen, das ebenfalls speziell eingestellt wurde. Der Befehl "pppdbind" erf{[uuml ]}llt genau diesen Zweck. Mit:
isdnctrl pppbind {[lt ]}interface{[gt ]} {[lt ]}Number{[gt ]}
Beispiel: Die folgende Konfiguration bindet das Interface 'ippp5' an /dev/ippp2:
isdnctrl pppbind ippp5 2
Zumindest musst Du eine route angeben, die ein Datenpaket an das ippp Netzwerk-Interface {[uuml ]}bergibt, um ein Hinausw{[auml ]}hlen auszul{[ouml ]}sen. Eine defaultroute auf das Interface ippp sollte funktionieren. Nun musst Du Deinem Interface eine Dummy-Addresse zuteilen. Wenn Du aus irgendwelchen Gr{[uuml ]}nden die defaultroute nicht auf das Interface ippp setzen kannst, nimmst Du irgendeine Addresse aus dem Subnet, aus dem Du Deine dynamische IP-Nummer erwartest und setzt eine 'network route' f{[uuml ]}r dieses Subnet auf das Interface ippp. Rufe ipppd mit der Option 'ipcp-accept-local' auf um das {[Uuml ]}berschreiben der Dummy-Addresse zu erm{[ouml ]}glichen. Du musst wissen, wie ipppd die Addressen bekommt, die er einstellen muss. Wenn Du keine Option aktivierst, versucht ipppd, die Addresse des localhost zu {[uuml ]}bertragen! Mit der Option 'noipdefault' verlangt er eine Addresse von der entfernten Maschine. Mit 'useifip' bekommt er die Addressen vom Netz-Interface. Du kannst die Addressen auch in der Optionszeile mit der Option 'a.b.c.d:e.f.g.h' setzen.
Hinweis: die IP-Addresse der entfernten Maschine muss lokal gesetzt werden oder die entfernte Maschine muss sie in einem IPCP Request senden. Wenn Deine Seite die IP-Addresse nach der Verhandlung nicht kennt, wird sie die Verbindung abbrechen! Du musst das {[Uuml ]}berschreiben der Addressen mit den Optionen "ipcp-accept-local/remote" erlauben wenn Du Deine eigene oder die entfernte Addresse ausdr{[uuml ]}cklich gesetzt hast. Versuche als Beispiel diese Optionen:
/sbin/ipppd :{[dollar]}REMOTE noipdefault /dev/ippp0
Mit der Option ms-get-dns
wird die Adresse des Nameservers geholt
wenn Du Deinen Internet Provider anw{[auml ]}hlst. Mit ms-dns
zeigst
Du die Adresse des Nameservers wenn sich jemand bei Dir einw{[auml ]}hlt.
{[Uuml ]}bergib dem ipppd die Option +ipx-protocol
.
Du kannst mehr Kan{[auml ]}le mittels MPPP einrichten (siehe Abschnitt MPPP). Eine weitere M{[ouml ]}glichkeit ist die Nutzung von Kompression, siehe Frage syncppp_compression.
Mit dem ipppd k{[ouml ]}nnen verschiedene Kompressionsverfahren benutzt werden. Bei Fehlern oder Zweifeln sollte man sie jedoch deaktivieren.
-vj -vjccomp
deaktiviert.
Die Meldungen des ipppd sind sehr hilfreich... (siehe n{[auml ]}chste Frage: syncppp_log)
/var/log/messages
,
/var/log/debug
und /var/adm/daemon
(wenn vorhanden)
nach. Es k{[ouml ]}nnte ein Fehler im ipppd sein.cause E0010
ist KEIN Fehler! Es
ist nur die informative Meldung, da{[szlig ]} die Verbindung beendet
wurde.
Wenn die Option "debug" f{[uuml ]}r den ipppd gesetzt wurde, erscheinen
die Meldungen normalerweise in /var/log/messages
,
/var/log/debug
oder /var/adm/daemon
(abh{[auml ]}ngig
von Deiner Distribution).
Zur Fehlersuche kannst Du das PPP-Log in eine gesonderte Datei
umleiten. Editiere dazu die Datei /etc/syslog.conf
und
f{[uuml ]}ge die folgende Zeile hinzu (Achtung: gebrauche KEINE
Leerzeichen sondern TABs - Du findest weitere Details mit man 5
syslog.conf
):
daemon.* /var/log/ppp-log
ste@esqhen.su.eunet.de
schrieb dazu:
Entferne das Kommentar-Zeichen vor dieser Zeile in /etc/syslog.conf:
{[num ]}*.=debug /tmp/debug
Nach der {[Auml ]}nderung dieser Datei kannst Du den syslogd mit 'kill -1 pid of syslogd' neu starten. Die Meldungen in /tmp/debug k{[ouml ]}nnen zur Optimierung der PPP-Optionen genutzt werden.
Pr{[uuml ]}fe, ob das Device 'ippp0' existiert (z.B. mit dem Programm "ifconfig"). Hinweise zur Benennung von Net-Interfaces bekommst Du bei Frage syncppp_netinterface. Der ipppd braucht dieses Device mit exakt diesem Namen und syncppp. Wenn es nicht existiert, muss es definiert werden:
isdnctrl addif ippp0 isdnctrl encap ippp0 syncppp
Vielleicht hast Du den ipppd mit den Quellen eines Kernels, den Du nicht benutzt, kompiliert...
Diese Meldung taucht dann auf, wenn das Verbindungs-Interface hinausw{[auml ]}hlen soll, ipppd aber noch nicht l{[auml ]}uft oder nicht verf{[uuml ]}gbar ist.
Wenn ipppd gestartet wird, ruft er Funktionen auf, die den Transport eines Netzwerkpaketes ausl{[ouml ]}sen k{[ouml ]}nnen (z.B. gethostbyname()). Ohne ipppd (da zu dieser Zeit ipppd noch nicht komplett gestartet ist) kann dieser Netzwerkzugriff nicht durchgef{[uuml ]}hrt werden. Versuche, die gesuchten Host-Namen in die lokale /etc/hosts zu schreiben oder sonst irgendwie zu definieren, soda{[szlig ]} sie ohne Zugriff auf das ISDN-/ippp-Interface aufgel{[ouml ]}st werden k{[ouml ]}nnen.
IP frames delayed
- aber keine Verbindung.
Hast Du tats{[auml ]}chlich hinausgew{[auml ]}hlt? Sieh Dir die Frage dialout_dialmode und Deine Konfiguration der verschiedenen Dialmodi an.
isdnctrl dial ippp0
nicht hinausw{[auml ]}hlen. Die Route zu ipppd scheint zu fehlen, obwohl ich sie wirklich gesetzt habe (network unreachable
). Mit dem alten Kernel 2.0 funktionierte alles einwandfrei!
In den neueren Kernel muss der Befehl route
als letztes
Kommando vor dem W{[auml ]}hlbefehl stehen. Anderenfalls l{[ouml ]}scht der
Kernel die Route.
Das liegt am Kernel. Bei neueren Kernel (= 2.0.x) gibt es einige {[Auml ]}nderungen beim Routing. L{[ouml ]}sung: installiere ein Script /etc/ppp/ip-up, das in etwa so aussieht:
{[num ]}!/bin/sh /sbin/route add default ippp0
Wenn Du Deine Verbindungen manuell herstellst, kannst Du so etwas wie dieses Script benutzen:
/sbin/isdn {[num ]}! /bin/sh case {[dollar]}1 in on) /sbin/isdnctrl dial ippp0 {[num ]} aufbauen der Verbindung sleep 5 {[num ]} abwarten /sbin/route add default ippp0 {[num ]} Route setzen ;; off) /sbin/isdnctrl hangup ippp0 {[num ]} Verbindung beenden /sbin/route del default {[num ]} L{[ouml ]}schen der Route ;; *) echo -e '{[bsol ]}a Usage: 'isdn on' or 'isdn off'' ;; esac
route add
default
und route del default
NICHT benutzt werden
d{[uuml ]}rfen. {[Uuml ]}bergib statt dessen die Option "defaultroute" an
den ipppd.
hscx{[lowbar]}empty{[lowbar]}fifo: incoming packet too large
Vermutlich ist eine der Kompressionsoptionen aktiviert (funktionieren mit I4L nicht so gut). Mehr dazu in der n{[auml ]}chsten Frage. Ein weiterer m{[ouml ]}glicher Grund k{[ouml ]}nnte ein IRQ-Problem sein - siehe Frage 'Warum sollte ich IRQ 12 und 15 f{[uuml ]}r meine ISDN-Karte vermeiden?'. Das Problem kann auch durch '{[num ]}'-Zeichen in der Datei pap-secrets verursacht werden. In diesem Fall musst Du den Benutzernamen und/oder das Passwort mit Anf{[uuml ]}hrungszeichen einrahmen (je nachdem, was betroffen ist).
Vermutlich ist eine der Kompressionsoptionen aktiviert (die I4L nicht sauber behandeln kann). Verbreiteter Fehler: '-vj' muss *zus{[auml ]}tzlich* zu '-vjccomp' gesetzt werden, um die VJ-Kompression v{[ouml ]}llig abzuschalten - in den Beispielscripts von ipppd ist diese Option schon nicht mehr enthalten. Auch andere Kompressionsmodi (bsd, pccomp) k{[ouml ]}nnen Probleme verursachen. Daher solltest Du alle Kompressionsoptionen deaktivieren (siehe auch Frage syncppp_compression). Auch die Option "noccp" kann da helfen.
Sven Engelhardt
sven@sik.de
schrieb am 12. Dezember 1996:
Wir sind ein ISP in Dresden und benutzen Linux (neben anderen Systemen) f{[uuml ]}r unseren Zugang (mit I4L ebenso wie mit externen Terminaladaptern). Wir haben dieses Problem haupts{[auml ]}chlich mit Kunden, die unter Windows 95 und NT die 'enthaltene' (Modem Netzwerk) Software benutzen. Es ist dabei unerheblich, ob der Kunde sich mit asynchronem oder synchronem PPP einw{[auml ]}hlt. Es spielt auch keine Rolle, welche Modememulation er auf seiner Seite benutzt. Was sie gemeinsam haben ist, da{[szlig ]} die Verbindung mit Microsoft's Modemadapter und Microsoft's PPP hergestellt wird (obwohl mir ein Kollege k{[uuml ]}rzlich von einem {[auml ]}hnlichen Problem mit einem Macintosh-Kunden erz{[auml ]}hlte). Da es bei PPP keinen Unterschied macht, wer der Server und wer der Client ist, solltest Du Deinen ISP fragen, welche Hardware er zur Einwahl benutzt (wir hatten keine Probleme mit Linux-Kunden und Benutzern von Trumpet Winsock, daher vermuten wir einen Fehler in MS-PPP). Die folgende Abhilfe funktioniert normalerweise bei uns: (es ist keine Kur, aber es lindert die Schmerzen...)Bei Windows 95 sind das zwei Eintr{[auml ]}ge in der Registry, unter Linux kannst Du die Optionen 'mtu 576' und 'mru 576' f{[uuml ]}r PPP setzen. (Siehe auch:
- Reduziere den Wert f{[uuml ]}r Max MTU auf 576 oder sogar 296
- Reduziere das DefaultRcvWindow auf 2144
{urlnam}
)
Erik Corry
ec@sign-tronic.dk
f{[uuml ]}gte am 16. Dezember 1996 hinzu:
Bei mir half weder das Abschalten der PPP Kompressionsoption noch das Setzen von mru/mtu auf 296. Was half, war der AT-Befehl:
AT{[amp ]}B512
der die gesendeten Pakete auf 512 Bytes begrenzt.
Wenn der Wert mtu nicht festgesetzt ist, wird ein Defaultwert
angenommen - m{[ouml ]}glicherweise '0', der nat{[uuml ]}rlich nicht korrekt
sein kann. F{[uuml ]}ge 'mtu 1024'
zu Deinen Optionen f{[uuml ]}r
ipppd hinzu (1500 kann auch funktionieren).
Es gibt ein paar Probleme mit der Hinauswahl in Verbindung mit syncPPP und dynamischer Zuteilung der IP-Addresse. In diesem Fall {[auml ]}ndert sich Deine IP-Addresse w{[auml ]}hrend Pakete auf die Versendung warten. Alle Pakete, die vor dieser IP-Address{[auml ]}nderung verschickt werden, haben dann die falsche R{[uuml ]}ckantwort-Addresse und werden nie eine R{[uuml ]}ckmeldung erhalten. Das kann viele vergebliche W{[auml ]}hlversuche verursachen (siehe dod). M{[ouml ]}gliche L{[ouml ]}sungen sind:
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
IP{[lowbar]}DYNIP='yes'
in /etc/rc.config
aktivieren.Hkey{[lowbar]}Local{[lowbar]}Machine{[bsol ]}{[bsol ]}System{[bsol ]}{[bsol ]}CurrentControlSet{[bsol ]}{[bsol ]}Services{[bsol ]}{[bsol ]}VxD{[bsol ]}
{[bsol ]}MSTCP{[bsol ]}{[bsol ]}MaxConnectRetries
von 3 auf einen h{[ouml ]}heren Wert (5
oder 7).
Michael Engert
michi@bello.wor.de
schrieb im Nov/Dez 1996:
Das bedeutet, da{[szlig ]} Dein Computer ein IP-Paket von jemandem hat, der vor wenigen Sekunden online war aber die Verbindung inzwischen unterbrochen hat. Dein Computer versucht nun, dieses Paket zu verschicken und findet auch eine passende Route. Das Interface isdn(0{[verbar]}1{[verbar]}...) kann jedoch den Zielcomputer nicht erreichen, da es keine Telefonnummer zum Hinausw{[auml ]}hlen findet.
'ippp0: dialing 0 089XXXXXX...'
)? Ich habe keine Nebenstellen!
Die erste Null wird nicht gew{[auml ]}hlt. Sie zeigt die Anzahl der
W{[auml ]}hlversuche, festgelegt vom Parameter isdnctrl dialmax
.
Das ISDN-Device t{[auml ]}uscht ein Ethernet-Device vor. Es ignoriert IRQ und baseaddr und ben{[ouml ]}tigt nur die HWaddr f{[uuml ]}r die Ethernet-Encapsulation.
kernel check for lzs failed
?
Das bedeutet, da{[szlig ]} ipppd versucht, die LZS-Kompression zu nutzen,
aber kein kompiliertes Modul mit dem entsprechenden Code findet. Die
Fehlermeldung hat nur kosmetische Bedeutung, da das System
weiterarbeitet. Du kannst entweder die LZS-Kompression abstellen
(setze noccp
als Option f{[uuml ]}r ipppd) oder das LZS Modul
kompilieren und laden.