Point-to-Point Protocol (PPP) ist u.a. in den RFCs 1661, 1662, 1332 and 1334 definiert. Es wurde ursprünglich entwickelt, um Daten über serielle Leitungen zu verschicken. Es bietet grundsätzlich auch weitere Netzwerkprotokolle (Apple, IPX, ...) unter Linux ist aber nur IP vorgesehen. PPP bietet verschiedene Features wie z.B. den Austausch der IP-Nummern, Authentication, Compressions etc.
Aus diesem Grund findet zunächst durch das Link Control Protocol (LCP) ein Handshake statt, durch den die Verbindung initialisiert wird (oder auch nicht). In der Praxis ergeben sich genau hierdurch die Probleme gemäß der Richtlinie das schöne an Standards ist, daß sich jeder seinen eigenen aussuchen kann.
Wer analoges PPP gewöhnt ist, muß hier ein umdenken. Bei ISDN dreht sich alles um. Die Netzverbindung besteht logisch immer, gewählt wird aber nur bei Bedarf.
/etc/ppp/options
/etc/ppp/options.DEVICE
(DEVICE ist das aktuell verwendete serielle Device).
/etc/ppp/ip-up
/etc/ppp/ip-down
/etc/ppp/ioptions
Der Unterschied zwischen synchronem und asynchronem PPP ist das Framing also das Einpacken der Rohdaten für die jeweilige Verbindungsart. SyncPPP packt in HDLC ein. Auf einer Modemstrecke bzw. einer seriellen Schnittstelle kann man aber nur characterweise verschicken. Entsprechend packt asyncPPP seine Päckchen anders ein. Es gibt ein ausgewiesenes Byte welches den Paketanfang bzw. das Ende markiert. Diese Byte muss, sofern es im Datenstrom auftaucht natürlich anders dargestellt werden. Dafür gibt es ein weiteres reserviertes Byte, das Escape-Byte.
Beispiel:
NETDEV='ippp0'
# neues Device
isdnctrl addif $NETDEV
# setzte MSN/EAZ
isdnctrl eaz $NETDEV 456
# def. Nummer(n) zum rauswaehlen
isdnctrl addphone $NETDEV out 09011
# erlaube Nummern, die anrufen duerfen
#isdnctrl addphone $NETDEV in
# duerfen alle anrufen? Nein: setze secure=on
isdnctrl secure $NETDEV on
# Layer-2 Protokoll: (x75i, x75ui, x75bui, hdlc)
isdnctrl l2_prot $NETDEV hdlc
# Layer-3 (nur trans)
isdnctrl l3_prot $NETDEV trans
# Ecapsulation: (rawip, cisco_h, syncppp)
isdnctrl encap $NETDEV syncppp
# Idletime
isdnctrl huptimeout $NETDEV 60
# maximale Waehlversuche
isdnctrl dialmax $NETDEV 5
# nur einen bestimmten Kanal benutzen
#isdnctrl bind $NETDEV
# PPP an Netzdevice binden
isdnctrl pppbind $NETDEV 0
# Netzdevice konfigurieren
ifconfig $NETDEV 1.1.1.1 pointopoint 193.102.150.13 up
# OPEN-Meldung ausgeben:
isdnctrl verbose 3
Gelöscht wird das Interface durch die Befehle:
ifconfig $NETDEV down
isdnctrl delif $NETDEV
Vor dem Start des ipppd müssen drei Voraussetzungen erfüllt sein:
isdnctrl addif)
Die syncPPP Unterstützung des Kernels prüft der ipppd
leider über eine etwas unglücklich Methode ab:
Es muß ein Device ippp0 vorhanden sein. Außerdem
kann man das Device nicht beliebig benennen, es muß mit
ippp beginnen. Merke: Benutze immer als Devicename
ippp0
Der ipppd kann über 2,5 Arten Optionen annehmen:
/etc/ppp/ioptions
-file).
In Anlehnung an den pppd empfehle ich folgende Struktur:
/etc/ppp/ioptions
/etc/ppp/options.ippp0
ipppd pidfile /var/run/ipppd.ippp0.pid file /etc/ppp/options.ippp0 &
Folgendes sollte man noch über den ipppd wissen:
man ipppd
pppbind.
/etc/ppp/ioptions muß existieren.
Folgende Optionen haben sich für die verschiedensten ISP's als stabil erwiesen:
# /etc/ppp/options.ippp0
#
# for isdn4linux/syncPPP and dynamic IP-numbers
#
#
# Klaus Franken, kfr@suse.de
# Version: 27.08.97 (5.1)
#
# This file is copy by YaST from /etc/ppp/ioptions.YaST
# to options.<device>
# The device(s)
# for more than one device try:
# /dev/ippp0 /dev/ippp1 ...
/dev/ippp0
# The IP addresses: <local>:<remote>
# just "0.0.0.0:" or nothing for dynamic IP
#0.0.0.0:
# my user name
user suse
# my system name (only for CHAP!)
# name my_system_name
# accept IP addresses from peer
# use with dynamic IP
ipcp-accept-local
ipcp-accept-remote
noipdefault
# try to get IP address from interface
# option specific to ipppd (as opposed to pppd)
# use only with static IP
#useifip
# disable all header-compression
-vj
-vjccomp
-ac
-pc
-bsdcomp
# sometimes you need this:
#noccp
# max receive unit
mru 1524
# max transmit unit
mtu 1500
# If this machine is a server, force authentication by uncommenting one
# of the following. However, if this machine is a client, doing this will
# prevent a succesful connection! (message "peer refused to authenticate").
# So, only uncomment on a server.
# "+pap" / "+chap" NUR AKTIVIEREN, WENN DIES EIN SERVER IST!!!
#+pap
#+chap
# if you have problems with handshaking (no response for first
# lcp-package) try to decrease the retry-cycle. Default is 3 sec,
# try for example 2 sec:
# lcp-restart 2
Der ipppd verhält sich bei der Benutzerauthentifizierung exakt genauso wie der pppd. Daher nur ein kurzer Abriß.
Es stehen zwei Methoden zur Verfügung: PAP und CHAP. Meistens wird PAP angeboten über CHAP kann man im PPP HOWTO nachlesen.
Die Benutzerdaten werden an zwei Stellen konfiguriert;
als erstes wird dem ipppd durch das Schlüsselwort user
mitgeteilt, welche User-Id dem gegnerischen PPP-Daemon
angeboten werden soll.
Als nächstes wird das Passwort selbst (im Klartext) in
der Datei /etc/ppp/pap-secrets abgelegt.
Diese Datei darf nur für root lesbar sein! Also
chmod 600 /etc/ppp/pap-secrets
Für jeden verwendeten User wird eine Zeile eingetragen,
z.B. sei der Username suse und Passwort linux:
# client server pw iplist
"suse" * "linux"
Dies ist die einzige Stelle, wo das
Passwort definiert ist. In der /etc/ppp/pap-secrets
können mehrere User/Passwörter definiert sein, über die Option
user wird jeweils die richtige Zeile extrahiert, um
das Passwort zu ermitteln.
Der Benutzername muß nicht im System bekannt sein, zumindest besteht zwischen dem PAP- (oder CHAP-) Benutzernamen und dem Systembenutzer kein Zusammenhang.
Nachdem der ipppd gestartet ist und ev. eine Route
darüber definiert ist, wird bei Bedarf automatisch ein
Wählvorgang ausgelöst. Manuell kann man dies auslösen
durch isdnctrl dial ippp0.
Meldungen werden über syslog nach /var/log/messages
geschrieben.
Folgende Daten sollte man kennen, die meisten sollte der ISP zur Verfügung stellen.
Es sollte syncPPP sein.
klar...
Mit welcher meiner Telefonnummern möchte/muß ich wählen, siehe Was ist meine MSN?.
Wenn man feste IP-Nummern hat, gibt der ISP zumindest die persönlich an, die IP-Nummer des PtP (also die des ISP) kennt deswegen noch nicht unbedingt. In diesem Fall, gibt man irgendeine ein (wie bei dynamischen) und läßt eine Verbindung herstellen, damit sieht man die IP-Nummer, die man dann hier fest einträgt.
Bei dynamischen IP-Nummern, trägt man irgendwelche ein, siehe Probleme mit dynamischen IP-Nummern.
PAP oder CHAP
klar ...
Sollte man vom ISP mitgeteilt bekommen. Ansonsten siehe
http://www.suse.de/Support/sdb/nonameserver.html
Mit folgenden weiteren Parametern, kann man die ISDN-Verbindung steuern.
Nach wie vielen Sekunden Inaktivität soll aufgelegt
werden. Will man dieses Feature abstellen, kann man
die Zeit auf 0 stellen.
Hinweis: Diese Zeitangabe ist nicht exakt.
Wie oft soll gewählt werden, wenn der Gegner nicht abnimmt?
Hinweis: Diese Anzahl gilt nicht, wenn es Hardwareprobleme gibt, zieht man z.B. das ISDN-Kabel, wird unendlich oft probiert.
Hinweis: Diese Anzahl gilt nicht, wenn die Wählverbindung zustandekam, aber die PPP-Verbindung nicht aufgebaut werden konnte. Ist z.B. das Passwort falsch eingetragen, wird immer wieder eine Verbindung aufgebaut, solange Pakete verschickt werden.
In diesem Fall soll keiner die Verbindung von außen aufbauen
dürfen, deshalb sollte man keine eingehende Telefonnummer
angeben und die Option secure bzw.
Nur angegebene Nummern erlaubt aktivieren.
mehr dazu siehe in
/usr/doc/packages/doc/rc.config.i4l.add
Die Konfiguration wird in der Datei /etc/rc.config
eingetragen (außer Routing), dies kann manuell oder
über YaST geschehen.
Administration des Systems,
Netzwerk konfigurieren und Netzwerk Grundkonfiguration
auswählen.
ippp0 gibt. Mit F5 wählt man den Netzwerktyp aus,
hier also ISDN SyncPP.
F6 vergibt man die IP-Nummern
(siehe
Welche IP-Nummer setze ich denn eigentlich?
und kann auch direkt das Default-Gateway angeben
(siehe
Routing).
F8 werden nun die ISDN-relevanten Daten
eingetragen.
Nachdem man das Device aktiviert hat, kann man es in
der ISDN-Maske direkt hochfahren mit: Starten.
Damit sind die rc.config-Variablen, die PPP-Options, die Passwortdatei und das Routing angepaßt.
Durch folgende Variablen in
/etc/rc.config wird eine syncPPP-Verbindung
gesteuert, hier als echtes Bsp. (mit _0):
IPADDR_2="1.1.1.1"
NETDEV_2="ippp0"
IFCONFIG_2="1.1.1.1 pointopoint 193.102.150.13 up"
I4L_IDLETIME_2="60"
I4L_DIALMAX_2="5"
I4L_LOCALMSN_2="7417559"
I4L_REMOTE_OUT_2="52145922"
I4L_REMOTE_IN_2=""
I4L_ENCAP_2="syncppp"
I4L_SECURE_2="on"
/etc/rc.config sind auch vor den Feldern
entsprechende Kommentare.
Es können beliebig viele Netzdevices definiert werden
(auch wenn per Default nur 4 angegeben sind), die jeweils
durch eine Extension, z.B. _2 gekennzeichnet werden.
Dabei müssen nicht alle aktiv sein. Welche aktiviert
werden sollen, wird in der Variablen NETCONFIG
gesteuert, sollen z.B. _0 und _2 aktiv sein,
setzt man: NETCONFIG="_0 _2".
Als nächstes muß der ipppd konfiguriert werden, erstelle
eine Datei /etc/ppp/options.ippp0
(siehe
PPP-Optionen) am besten in
dem Du
/etc/ppp/ioptions.YaST kopierst.
In der Optionsdatei, setzte den Usernamen und prüfe, ob das
Device stimmt.
Dann trägst Du das Passwort passend zum Usernamen in
/etc/ppp/pap-secrets ein.
Zum manuellen Starten, siehe: ipppd starten
Checkliste:
Kontrolliere mit ps ax|grep ipppd ob einer
läuft bzw. wieviele laufen.
Kontrolliere in /var/log/messages die Startmeldungen,
z.B.:
syslog: info: no CHAP secret entry for this user!
ipppd[536]: Found 1 devices: /dev/ippp0,
ipppd[540]: ipppd i2.2.9 (isdn4linux version of pppd by MH) started
ipppd[540]: init_unit: 0
ipppd[540]: Connect[0]: /dev/ippp0, fd: 8
Der ipppd prüft schon beim Start, mit welchem Usernamen
gearbeitet wird (user suse), zu diesem Namen
wird das entprechende Passwort gelesen. Klappt das nicht,
wird eine Meldung ausgegeben, z.B.
Apr 9 20:32:17 glen syslog: info: no PAP secret entry for this user!
Analoges gilt für CHAP.
Sobald die Gegenstelle abnimmt (und damit Kosten
entstehen) erscheint eine connect-Meldung.
Wird keine Verbindung aufgebaut, gibt es vermutlich
eine cause-Meldung. Siehe:
Cause Meldungen.
Erscheinen nur dialing-Meldungen, aber sonst nichts,
liegt es an der Hardware oder am Hardware-Modul,
siehe
Hardware testen und
Installation.
Bei Erfolgreicher Einwahl erscheinen Meldungen über die IP-Nummern, z.B.:
ipppd[540]: local IP address 149.228.142.59
ipppd[540]: remote IP address 193.102.150.13
select: Bad file number
Direkt nach der Ausgabe der IP-Nummern ercheint:
ipppd[353]: select: Bad file number
ipppd[353]: Couldn't restore device fd flags: Bad file number
ipppd[353]: Exit.
Was hat es damit auf sich? Zunächst einmal: die Verbindung ist trotz allem aufgebaut.
Ursache: der ipppd startet beim (Dis-) Connect das
Script /etc/ppp/ip-up (ip-down).
Aufgrund eines kleinen Fehlers im offiziellen ipppd
(behoben in der CVS-Version und ab S.u.S.E. 5.2) ist die
Abprüfung auf Ausführbarkeit fehlerhaft, woraufhin
trotzdem versucht wird das Script zu starten.
Nach der Ferhlermeldung passiert genau nichts.
Allerdings sollte die Meldung trotzdem beachtet werden, denn da wir dynamische IP-Nummer benutzen, muß das Routing angepaßt werden, was genau über diese Scripte geschehen soll, die hier nicht vorhanden sind.
Wenn die Einwahl nicht klappt, sieht man in
/var/log/messages meist nur, daß die Gegenstelle
aufgelegt hat, um den Grund dafür zu ermitteln, braucht man
mehr Meldungen vom LCP. Dazu trägt man in
/etc/ppp/ioptions folgendes ein:
# Set 'debug' to create a lot of information in /var/log/messages
debug
# Set '+pwlog' for logging passwords in /var/log/messages
#+pwlog
debug werden die LCP-Messages ausgegeben,
durch +pwlog kann man sich zusätzlich das
verschickte Passwort angeben lassen - letzteres ist nur
empfohlen, wenn ansonsten alles richtig scheint, denn
wenn jemand fremndes Zugriff auf /var/log/messages
bekommt...
Häufige Ursachen:
in diesem Fall wird etwas in dieser Art protokolliert,
ipppd[10314]: sent [0][PAP AuthReq id=0x1 user="kfr" password="falsch"]
ipppd[10314]: rcvd [0][PAP AuthNak id=0x1msg=""]
ipppd[10314]: Remote message:
ipppd[10314]: PAP authentication failed
ipppd[7840]: sent [0][PAP AuthReq id=0x1 user="kfr" password="isdnworkshop"]
ipppd[7840]: rcvd [0][PAP AuthAck id=0x1msg=""]
ipppd[7840]: Remote message:
ipppd[7840]: bundle, he: 0 we: 0
Normalerweise LCP-Messages gesendet und empfangen um das Handshaking durchzuführen (send, rcvd):
ipppd[10314]: sent [0][LCP ConfReq id=0x1 <mru 1524> <magic0x93ade903>]
ipppd[10314]: rcvd [0][LCP ConfReq id=0x1 <mru 1524> <auth pap>
<MPdiscr: 0x3 [ 00 c0 7b 70 d5 fa ]>]
lcp-restart
erhöhen), oder kein (sync-) PPP-Daemon dort läuft.
Ist dies nicht nur ein temporäres Problem, ist entweder
die Nummer falsch, oder der ISP bietet tatsächlich kein
syncPPP an.
Im letzteren Fall muß man asyncPPP fahren, siehe
http://www.suse.de/Support/sdb/ppp_async.html
Hierbei sollte man am Protokoll erkennen welche
Optionen angefordert oder abgewiesen werden. Danach
bleibt einem nur der mühsame Weg, diese Optionen
zu setzen/deaktivieren, siehe Bsp-Optionsfile
und man ipppd.
peer refused to authenticate
Man hat selbst +pap oder +chap angegeben.
Ein häufiges Mißverständnis: diese Optionen geben,
an, daß man selber der Authentication-Server sein
möchte, nicht daß man PAP oder CHAP benutzen möchte;
letzteres geschieht nur implizit durch Angabe user,
name und den Eintragungen in
pap-secrets bzw. chap-secrets.
ifconfig. Die IP-Nummern
müssen übereinstimmen (und gegenüber der Grundeinstellung
verändert sein).
route -n.
Siehe
Routing.
Es muß eine Hostroute für den
PtP-Partner gesetzt sein.
ping 193.102.150.13.
Ziel: PPP-Verbindung aufbauen und testen (kein Routing)