Next Previous Contents

13. syncppp: Sync PPP

13.1 syncppp{[lowbar]}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{[lowbar]}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{[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.

13.3 syncppp{[lowbar]}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{[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.

13.4 syncppp{[lowbar]}config: Wie richte ich ISDN4LINUX mit syncPPP ein?

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.

13.5 syncppp{[lowbar]}busy: Wie stelle ich fest, da{[szlig ]} ein Verbindungsaufbau erfolglos war (besetzt)?

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.

13.6 syncppp{[lowbar]}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{[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.

13.7 syncppp{[lowbar]}2configs: Ich m{[ouml ]}chte Verbindungen mit entfernten Maschinen aufbauen, die unterschiedliche Konfigurationen ben{[ouml ]}tigen. Die einzige Art dazu, die ich fand, besteht darin, den ipppd zu beenden und einen neuen mit anderer Konfiguration f{[uuml ]}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{[uuml ]}r dieses Interface individuell eingestellten ipppd verbinden kannst. Mit dem (leider schlecht dokumentierten) Befehl


isdnctrl pppbind {[lt    ]}interface{[gt    ]} {[lt    ]}Number{[gt    ]}

kannst Du das Interface interface an das Device Number binden. Du l{[ouml ]}st diese Bindung wieder mit 'pppunbind'.

13.8 syncppp{[lowbar]}pppbind: Wie funktioniert der (wenig dokumentierte) Befehl "pppbind" in isdnctrl?

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    ]}

wird das Interface {[lt ]}interface{[gt ]} an das Device /dev/ippp{[lt ]}number{[gt ]} gebunden.

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


isdnctrl pppbind ippp5 2

Dementsprechend l{[ouml ]}st der Befehl 'pppunbind' diese Bindung wieder auf.

13.9 syncppp{[lowbar]}dynip: Ich m{[ouml ]}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 {[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

wobei REMOTE die Addresse der entfernten Maschine ist (der Maschine, von der Du Deine Addresse bekommst).

13.10 syncppp{[lowbar]}msgetdns: Mit welcher Einstellung f{[uuml ]}r ipppd erreiche ich, da{[szlig ]} 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{[auml ]}hlst. Mit ms-dns zeigst Du die Adresse des Nameservers wenn sich jemand bei Dir einw{[auml ]}hlt.

13.11 syncppp{[lowbar]}ipx: Wie kann ich IPX {[uuml ]}ber den ipppd betreiben?

{[Uuml ]}bergib dem ipppd die Option +ipx-protocol.

13.12 syncppp{[lowbar]}faster: Wie kann ich meine Datentransferraten per PPP verbessern?

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.

13.13 syncppp{[lowbar]}compression: Welche Kompressionsarten kann ich mit ipppd verwenden?

Mit dem ipppd k{[ouml ]}nnen verschiedene Kompressionsverfahren benutzt werden. Bei Fehlern oder Zweifeln sollte man sie jedoch deaktivieren.

13.14 syncppp{[lowbar]}strategy: Ich kann keine Verbindung bekommen. Wie finde ich das Problem?

Die Meldungen des ipppd sind sehr hilfreich... (siehe n{[auml ]}chste Frage: syncppp_log)

13.15 syncppp{[lowbar]}log: Wie bekomme ich ein Log des ipppd?

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

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:
{[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.

13.16 syncppp{[lowbar]}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{[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

(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{[lowbar]}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{[auml ]}hlen soll, ipppd aber noch nicht l{[auml ]}uft oder nicht verf{[uuml ]}gbar ist.

13.18 syncppp{[lowbar]}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{[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.

13.19 syncppp{[lowbar]}framesdelayed: Ich bekomme die Meldung 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.

13.20 syncppp{[lowbar]}noroute: Ich kann mit dem Befehl 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.

13.21 syncppp{[lowbar]}nodefaultroute: Nachdem ipppd hinausgew{[auml ]}hlt hat ist meine defaultroute verschwunden.

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

Beachte bitte, da{[szlig ]} das bei Kernel 2.2.x NICHT funktioniert (das Routing wurde wieder ge{[auml ]}ndert). {[Uuml ]}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
{[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

Beachte bitte, da{[szlig ]} bei Kernel 2.2.x die Kommandos route add default und route del default NICHT benutzt werden d{[uuml ]}rfen. {[Uuml ]}bergib statt dessen die Option "defaultroute" an den ipppd.

13.22 syncppp{[lowbar]}packettoolarge: Ich bekomme oft die Fehlermeldung 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).

13.23 syncppp{[lowbar]}slow: Die Verbindung mit ipppd scheint zu stehen, bricht aber schlie{[szlig ]}lich zusammen oder ist sehr langsam.

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.

13.24 syncppp{[lowbar]}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{[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: {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.

13.25 syncppp{[lowbar]}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{[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).

13.26 syncppp{[lowbar]}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 {[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:

13.27 syncppp{[lowbar]}droppacket: Was bedeutet die Meldung 'No phone number, packet dropped'?

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.

13.28 syncppp{[lowbar]}leadingzero: Warum w{[auml ]}hlt mein ipppd eine Null zuviel ('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.

13.29 syncppp{[lowbar]}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{[auml ]}uscht ein Ethernet-Device vor. Es ignoriert IRQ und baseaddr und ben{[ouml ]}tigt nur die HWaddr f{[uuml ]}r die Ethernet-Encapsulation.

13.30 syncppp{[lowbar]}lzsproblem: Ich bekomme eine Fehlermeldung: 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.


Next Previous Contents