🚀 go-pugleaf

Hallo Martina!

03 Jan 96, Martina Umlauft writes to Richard Kail:

 RK>> Hm. Schmeiss den dip weg und nimm pppd und chat.
 MU> Warum eigentlich? Die Scriptsprache von dip ist ungefaehr 100 Mal besser
 MU> als der Schrott, den ich bei chat eingeben kann

    Das Problem mit dip ist, das es sich dabei um Trash-Soft handelt, die von
den Autoren IMHO nicht mehr gewartet wird und fuer den es nicht wirklich gute
Docu gibt. Vielleicht hat sich da mittlerweile was geaendert, aber vor einem
dreiviertel Jahr wars noch so.

    Es stimmt schon, das chat wesentlich weniger kann als dip, aber wenn man es
anderst anordnet, so faehrt man damit viel flexibler.

    Wenn Du ppp verwendest, kannst Du jede Ueberlegung betreffend IP-Parsing
und so weiter schon mal ad acta legen, der ppp konfiguriert alles von selbst
(sehr praktisch). Mit dem Chat machst Du nur den Modem-Call und gibts die
Abbruch-Bedingungen an, das reicht, um das Modem zu steuern.

    Um das ganze baust Du ein Shellscript herum, das den Rest macht, also
Wahlwiederholung und so weiter. Zugegeben, man braucht beim Dip nur ein
Kontroll-File, bei ppp+chat fast ein halbes Dutzend, wenn man die verschiedenen
Leitungen auf die TU verwenden will.

 MU> Wenn ich das richtig verstanden habe, ruft pppd beim Start das chat auf
 MU> und das kann man dann BREAKen lassen, wenn zb. BUSY kommt. Dh. man koennte
 MU> hoechstens dort ein Shellscript reinpfistern, sodass der pppd dieses statt
 MU> dem chat aufruft und das dann abfragt, ob chat erfolgreich oder mit BREAK
 MU> ausgestiegen ist... naja, ordentlich umstaendlich....

    Nein, machs anderst herum. Lass das Shellscript pppd aufrufen und der macht
wiederum das Chat.

 MU> Und PPP: welche Vorteile bietet es noch, ausser dass es von vornherein
 MU> fuer dynamische Adr.-Vergabe geeignet ist und bessere Securitymechnismen
 MU> bietet? Das mit den IP-Adr. funkt eigentlich (bis auf die komische
 MU> Meldung) auch bei SLIP und die bessere Security bietet das EDVZ doch
 MU> garnicht an, oder? (klaert mich auf, Leute, ich komm mir vor wie ein
 MU> Trottel... )

    Slip ist technisch eher ein Murks-Protokoll und nicht besonders flexibel.
PPP ist dahingegen eher sowas wie die eierlegende Wollmilchsau, was
Paket-Protokolle ueber Leitung betrifft.

    Ein paar Features von PPP: PPP kann defakto alle Parameter mit der
Gegenstelle aushandeln. Es gibt gut zwei Dutzend Konfigurationsparameter, die
werden alle mit der Gegenseite abgeglichen. PPP kann mehrere Protokolle
gleichzeitig transportieren. Also es ist mit PPP beispielsweise moeglich, IPX
und TCP/IP nebeneinander ueber die Leitung zu schicken. PPP geht auch jeder
Leitung, ueber die irgendwie HDLC-Frames geschickt werden koennen, also
angefangen von Modem asynchron, Modem synchron ueber ISDN und ATM bis hin zu
Cellular Networks, das ist alles PPP-Tauglich. Weiters ist PPP sehr gut
standardisiert, in den RFC's ist wirklich jeder Mist festgelegt. Insbesondere
das Error-Handling ist bei Slip nicht wirklich so gut definiert wie bei PPP.

    Ich habe mich sowohl ueber ein Jahr lange mit CSLIP an die TU gehaengt wie
ich es jetzt ueber ein Jahr mit PPP mache. Ich muss sagen, PPP gefaellt mir
wesentlich besser. Mit Slip hatte ich nur Troubles, das hat angefangen damit,
das der komische Dip nie wirklich das gemacht habt, was ich wollte bis hin zu
Fehlern, von denen ich bis heute nicht genau weiss, was genau passiert ist. Mit
der Umstellung auf PPP hat das alles mehr oder weniger Out-of-the-Box
funktioniert.

Gruss,
  Richard