Next Previous Contents

13. syncppp: Sync PPP

13.1 syncppp_whichppp: pppd, ipppd, syncPPP, asyncPPP .. was ist das alles? Welchen soll ich benutzen?

Siehe zu dieser Frage den Abschnitt in async PPP: asyncppp_whichppp.

13.2 syncppp_compile: Wie kompiliere ich ISDN4LINUX mit syncPPP?

Zum Kompilieren des Kernels mit dem in ISDN4LINUX enthaltenen syncPPP musst Du bei der Konfiguration die entsprechenden Fragen mit 'yes' beantworten. Vergiss nicht, daß 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 älteren Kernels problematisch und funktioniert nicht verläßlich - die Unterstützung dafür sollte jedoch trotzdem im Kernel vorhanden sein, da es sonst zu Nebenwirkungen kommen kann.

13.3 syncppp_netinterface: Wie sollte ich mein Netzwerk-Interface benennen?

Der Name des Netzwerk-Interfaces sollte immer mit 'ippp' beginnen, nicht mit 'syncppp' oder 'isdn', da in diesem Fall die Verständigung mit dem ipppd nicht ordentlich funktionieren wird. Es sollte also mindestens ein 'ippp0' vorhanden sein sonst wird der ipppd nicht starten. Überprüfe Deine Interfaces mit dem Befehl ifconfig.

13.4 syncppp_config: Wie richte ich ISDN4LINUX mit syncPPP ein?

Synchronous PPP ist einfach eine weitere encapsulation fü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ß 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üssen separat konfiguriert werden. Jedes ippp*-Device sollte mit einer eigenen IP-Addresse versehen werden (routing!). Mehrere ippp*-Devices können einer einzelnen MSN zugeordnet werden. Dann können mehrere Anrufer diese MSN gleichzeitig nutzen.

Zum Gebrauch dieser Devices benö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ählen zu ermö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ügung, das mit ifconfig überprüft werden kann (obwohl es den gleichen Namen trä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ä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önnen verschiedene Konfigurationen erstellt werden. Dazu dient der Befehl 'isdnctrl pppbind'. Normalerweise sollte der gesamte Verkehr über einen ipppd laufen. Die Einrichtung von mehreren ipppds ist wirklich nur empfehlenswert, wenn mehrere verschiedene Kofigurationen benötigt werden.

13.5 syncppp_busy: Wie stelle ich fest, daß ein Verbindungsaufbau erfolglos war (besetzt)?

Wenn Du die Option defaultroute angegeben hast, wartest Du ein paar Sekunden und kannst dann prüfen, ob die default route existiert. Eine weitere Möglichkeit besteht durch die Option useifip. Du findest dann im syslog Einträge wie "Local IP: x.y.z.a" und/oder "Remote IP: x.y.z.a". In beiden Fällen besteht eine Verbindung.

13.6 syncppp_logindelay: Wie kann ich das Login beschleunigen?

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ötigten Optionen. Ein Seiteneffekt ist, daß solche unbenötigten Optionen die Redundanz vergröß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.

13.7 syncppp_2configs: Ich möchte Verbindungen mit entfernten Maschinen aufbauen, die unterschiedliche Konfigurationen benötigen. Die einzige Art dazu, die ich fand, besteht darin, den ipppd zu beenden und einen neuen mit anderer Konfiguration für die Verbindung mit der zweiten Maschine zu starten.

Du musst ein Netzwerk-Interface explizit an ein ippp Device binden, mit dem Du einen für dieses Interface individuell eingestellten ipppd verbinden kannst. Mit dem (leider schlecht dokumentierten) Befehl 

isdnctrl pppbind <interface> <Number>
kannst Du das Interface interface an das Device Number binden. Du löst diese Bindung wieder mit 'pppunbind'.

13.8 syncppp_pppbind: Wie funktioniert der (wenig dokumentierte) Befehl "pppbind" in isdnctrl?

Zuerst musst Du wissen, wie ipppd seine Daten bekommt. Alle Daten, die ü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* übergeben - an eines, an dem der Systemdienst ipppd auf Daten wartet.

Was die Netzwerk-Interfaces betrifft, so können alle ipppds die gerade eingegangenen Daten behandeln. Daher ist es normalerweise unmö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ßlich von einem bestimmten Netzwerk-Interface empfangen, das ebenfalls speziell eingestellt wurde. Der Befehl "pppdbind" erfüllt genau diesen Zweck. Mit: 

isdnctrl pppbind <interface> <Number>
wird das Interface <interface> an das Device /dev/ippp<number> gebunden.

Beispiel: Die folgende Konfiguration bindet das Interface 'ippp5' an /dev/ippp2: 

isdnctrl pppbind ippp5 2
Dementsprechend löst der Befehl 'pppunbind' diese Bindung wieder auf.

13.9 syncppp_dynip: Ich möchte dynamisch zugeteilte IP-Addressen nutzen. Wie muss ich das Netzerk-Device konfigurieren?

Zumindest musst Du eine route angeben, die ein Datenpaket an das ippp Netzwerk-Interface übergibt, um ein Hinauswählen auszulösen. Eine defaultroute auf das Interface ippp sollte funktionieren. Nun musst Du Deinem Interface eine Dummy-Addresse zuteilen. Wenn Du aus irgendwelchen Grü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ür dieses Subnet auf das Interface ippp. Rufe ipppd mit der Option 'ipcp-accept-local' auf um das Überschreiben der Dummy-Addresse zu ermö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 ü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 Überschreiben der Addressen mit den Optionen "ipcp-accept-local/remote" erlauben wenn Du Deine eigene oder die entfernte Addresse ausdrücklich gesetzt hast. Versuche als Beispiel diese Optionen: 

/sbin/ipppd :$REMOTE noipdefault /dev/ippp0
wobei REMOTE die Addresse der entfernten Maschine ist (der Maschine, von der Du Deine Addresse bekommst).

13.10 syncppp_msgetdns: Mit welcher Einstellung für ipppd erreiche ich, daß die Adresse des Nameservers bei der Einwahl geholt oder angezeigt wird?

Mit der Option ms-get-dns wird die Adresse des Nameservers geholt wenn Du Deinen Internet Provider anwählst. Mit ms-dns zeigst Du die Adresse des Nameservers wenn sich jemand bei Dir einwählt.

13.11 syncppp_ipx: Wie kann ich IPX über den ipppd betreiben?

Übergib dem ipppd die Option +ipx-protocol.

13.12 syncppp_faster: Wie kann ich meine Datentransferraten per PPP verbessern?

Du kannst mehr Kanäle mittels MPPP einrichten (siehe Abschnitt MPPP). Eine weitere Möglichkeit ist die Nutzung von Kompression, siehe Frage syncppp_compression.

13.13 syncppp_compression: Welche Kompressionsarten kann ich mit ipppd verwenden?

Mit dem ipppd können verschiedene Kompressionsverfahren benutzt werden. Bei Fehlern oder Zweifeln sollte man sie jedoch deaktivieren.

13.14 syncppp_strategy: Ich kann keine Verbindung bekommen. Wie finde ich das Problem?

Die Meldungen des ipppd sind sehr hilfreich... (siehe nächste Frage: syncppp_log)

13.15 syncppp_log: Wie bekomme ich ein Log des ipppd?

Wenn die Option "debug" für den ipppd gesetzt wurde, erscheinen die Meldungen normalerweise in /var/log/messages, /var/log/debug oder /var/adm/daemon (abhä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ü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
Nun werden alle Informationen des Dienstes PPP in die Datei /var/log/ppp-log geschrieben. Emil Stephan ste@esqhen.su.eunet.de schrieb dazu:
Entferne das Kommentar-Zeichen vor dieser Zeile in /etc/syslog.conf: 
#*.=debug        /tmp/debug
Nach der Änderung dieser Datei kannst Du den syslogd mit 'kill -1 pid of syslogd' neu starten. Die Meldungen in /tmp/debug können zur Optimierung der PPP-Optionen genutzt werden.

13.16 syncppp_nopppsupport: Beim Start des ipppd bekomme ich die Fehlermeldung 'this systems lacks ppp support' oder 'isdn driver is out of date. maybe ippp0 has no syncppp0 encapsulation'.

Prü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
(weitere Informationen in der Dokumentation zu I4L und bei der Frage syncppp_config)

Vielleicht hast Du den ipppd mit den Quellen eines Kernels, den Du nicht benutzt, kompiliert...

13.17 syncppp_nousabledevice: Wenn ich ipppd starten will, bekomme ich die Meldung 'Can't find usable ippp device'

Diese Meldung taucht dann auf, wenn das Verbindungs-Interface hinauswählen soll, ipppd aber noch nicht läuft oder nicht verfügbar ist.

13.18 syncppp_starterror: Beim Start von ipppd bekomme ich nur Fehlermeldungen vom I4L-Treiber.

Wenn ipppd gestartet wird, ruft er Funktionen auf, die den Transport eines Netzwerkpaketes auslösen können (z.B. gethostbyname()). Ohne ipppd (da zu dieser Zeit ipppd noch nicht komplett gestartet ist) kann dieser Netzwerkzugriff nicht durchgeführt werden. Versuche, die gesuchten Host-Namen in die lokale /etc/hosts zu schreiben oder sonst irgendwie zu definieren, sodaß sie ohne Zugriff auf das ISDN-/ippp-Interface aufgelöst werden können.

13.19 syncppp_framesdelayed: Ich bekomme die Meldung IP frames delayed - aber keine Verbindung.

Hast Du tatsächlich hinausgewählt? Sieh Dir die Frage dialout_dialmode und Deine Konfiguration der verschiedenen Dialmodi an.

13.20 syncppp_noroute: Ich kann mit dem Befehl isdnctrl dial ippp0 nicht hinauswä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ählbefehl stehen. Anderenfalls löscht der Kernel die Route.

13.21 syncppp_nodefaultroute: Nachdem ipppd hinausgewählt hat ist meine defaultroute verschwunden.

Das liegt am Kernel. Bei neueren Kernel (= 2.0.x) gibt es einige Änderungen beim Routing. Lösung: installiere ein Script /etc/ppp/ip-up, das in etwa so aussieht: 

#!/bin/sh
/sbin/route add default ippp0
Beachte bitte, daß das bei Kernel 2.2.x NICHT funktioniert (das Routing wurde wieder geändert). Übergib statt dessen die Option "defaultroute" an den ipppd.

Wenn Du Deine Verbindungen manuell herstellst, kannst Du so etwas wie dieses Script benutzen: 

/sbin/isdn
#! /bin/sh
case $1 in
on)
/sbin/isdnctrl dial ippp0       #  aufbauen der Verbindung
sleep 5                         #  abwarten
/sbin/route add default ippp0   #  Route setzen
;;
off)
/sbin/isdnctrl hangup ippp0     #  Verbindung beenden
/sbin/route del default         #  Löschen der Route
;;
*)
echo -e '\a Usage: 'isdn on' or 'isdn off''
;;
esac
Beachte bitte, daß bei Kernel 2.2.x die Kommandos route add default und route del default NICHT benutzt werden dürfen. Übergib statt dessen die Option "defaultroute" an den ipppd.

13.22 syncppp_packettoolarge: Ich bekomme oft die Fehlermeldung hscx_empty_fifo: incoming packet too large

Vermutlich ist eine der Kompressionsoptionen aktiviert (funktionieren mit I4L nicht so gut). Mehr dazu in der nächsten Frage. Ein weiterer möglicher Grund könnte ein IRQ-Problem sein - siehe Frage 'Warum sollte ich IRQ 12 und 15 für meine ISDN-Karte vermeiden?'. Das Problem kann auch durch '#'-Zeichen in der Datei pap-secrets verursacht werden. In diesem Fall musst Du den Benutzernamen und/oder das Passwort mit Anführungszeichen einrahmen (je nachdem, was betroffen ist).

13.23 syncppp_slow: Die Verbindung mit ipppd scheint zu stehen, bricht aber schließlich zusammen oder ist sehr langsam.

Vermutlich ist eine der Kompressionsoptionen aktiviert (die I4L nicht sauber behandeln kann). Verbreiteter Fehler: '-vj' muss *zusätzlich* zu '-vjccomp' gesetzt werden, um die VJ-Kompression völlig abzuschalten - in den Beispielscripts von ipppd ist diese Option schon nicht mehr enthalten. Auch andere Kompressionsmodi (bsd, pccomp) können Probleme verursachen. Daher solltest Du alle Kompressionsoptionen deaktivieren (siehe auch Frage syncppp_compression). Auch die Option "noccp" kann da helfen.

13.24 syncppp_loadproblem: Ich habe nur dann Probleme mit ipppd, wenn die Verbindung sehr stark belastet wird. Dann bleibt alles stehen. Wodurch kann das hervorgerufen werden?

Sven Engelhardt sven@sik.de schrieb am 12. Dezember 1996:

Wir sind ein ISP in Dresden und benutzen Linux (neben anderen Systemen) für unseren Zugang (mit I4L ebenso wie mit externen Terminaladaptern). Wir haben dieses Problem hauptsä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ählt. Es spielt auch keine Rolle, welche Modememulation er auf seiner Seite benutzt. Was sie gemeinsam haben ist, daß die Verbindung mit Microsoft's Modemadapter und Microsoft's PPP hergestellt wird (obwohl mir ein Kollege kürzlich von einem ähnlichen Problem mit einem Macintosh-Kunden erzä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äge in der Registry, unter Linux kannst Du die Optionen 'mtu 576' und 'mru 576' für PPP setzen. (Siehe auch: http://www.winfiles.com/connect/trouble.html)

Erik Corry ec@sign-tronic.dk fü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&B512
der die gesendeten Pakete auf 512 Bytes begrenzt.

13.25 syncppp_mtu: Mein ipppd funktioniert. Ich bekomme jedoch laufend die Meldung 'pppd(104): ioctl(SIOCSIFMTU): Invalid argument'.

Wenn der Wert mtu nicht festgesetzt ist, wird ein Defaultwert angenommen - möglicherweise '0', der natürlich nicht korrekt sein kann. Füge 'mtu 1024' zu Deinen Optionen für ipppd hinzu (1500 kann auch funktionieren).

13.26 syncppp_1stpacket: Bei automatischer Hinauswahl mit dynamischer Zuteilung der IP-Addresse geht das erste IP-Paket verloren.

Es gibt ein paar Probleme mit der Hinauswahl in Verbindung mit syncPPP und dynamischer Zuteilung der IP-Addresse. In diesem Fall ändert sich Deine IP-Addresse während Pakete auf die Versendung warten. Alle Pakete, die vor dieser IP-Addressänderung verschickt werden, haben dann die falsche Rückantwort-Addresse und werden nie eine Rückmeldung erhalten. Das kann viele vergebliche Wählversuche verursachen (siehe dod). Mögliche Lösungen sind:

13.27 syncppp_droppacket: Was bedeutet die Meldung 'No phone number, packet dropped'?

Michael Engert michi@bello.wor.de schrieb im Nov/Dez 1996:

Das bedeutet, daß 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|1|...) kann jedoch den Zielcomputer nicht erreichen, da es keine Telefonnummer zum Hinauswählen findet.

13.28 syncppp_leadingzero: Warum wählt mein ipppd eine Null zuviel ('ippp0: dialing 0 089XXXXXX...')? Ich habe keine Nebenstellen!

Die erste Null wird nicht gewählt. Sie zeigt die Anzahl der Wählversuche, festgelegt vom Parameter isdnctrl dialmax.

13.29 syncppp_ethfake: Wenn ich die Werte meines ISDN-Devices mit ifconfig abfrage, wird es mit HWaddr und IRQ=0 und base address = 0 angezeigt.

Das ISDN-Device täuscht ein Ethernet-Device vor. Es ignoriert IRQ und baseaddr und benötigt nur die HWaddr für die Ethernet-Encapsulation.

13.30 syncppp_lzsproblem: Ich bekomme eine Fehlermeldung: kernel check for lzs failed?

Das bedeutet, daß 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ür ipppd) oder das LZS Modul kompilieren und laden.

Next Previous Contents