TCP/IP (Teil 3a): AmiTCP

In diesem dritten Teil unseres Workshops zur Netzanbindung werden nun die verschiendenen TCP-Stacks, die es für den Amiga gibt, vorgestellt. In diesem Artikel ist das AmiTCP. In weiteren Rollen: I-Net 225 (vulgo AS225) und Miami.

Welchen der drei Stacks man verwendet, hängt im Wesentlichen vom eigenen Geschmack ab, denn in den Leistungen unterscheiden sie sich nicht wesentlich. AmiTCP ist eher was für die Unix-Jünger, Miami für die, die sich nicht um die Interna kümmern wollen, es aber ohne weiteres können, und I-Net 225 zum Beispiel für die, die einen NFS-Dämon auf ihrem Amiga brauchen.

Allein schon die Verzeichnisstruktur von AmiTCP zeigt, daß es an Unix-Systeme angelehnt ist. Das geht auch soweit, daß die ganzen Konfigurationsfiles gleich heißen und im gleichen Format geschrieben sind.

Das Paket ist mittlerweile eine kommerzielle Software, zu der es eine Demoversion im Aminet zu finden gibt. Auch schon mit dieser Demoversion ist ein geruhsames Arbeiten möglich, einzig beim Starten des Stacks erscheint ein Requester, den man wegklicken muß. Ansonsten ist aber die volle Funktionalität gegeben. Die Demoversion ist noch Version 4.0, derzeit aktuell (seit zwei Jahren aber schon :-(( ) ist V4.3.

AmiTCP kommt mit einem Installerskript daher, daß eine relativ einfache Installation ermöglicht, aber natürlich nur für Standardkonfigurationen dienen kann. Sobald etwas Spezielleres gemacht werden soll, ist es schon überfordert.

Will man nur ein Interface starten (sei es nun mit der Ariadne oder der Connexion in ein LAN oder mittels Modem an seinen Provider), so wird das Skript durchaus brauchbare Ergebnisse liefern. Aber schon bei mehreren Interfaces, die noch dazu nicht alle gleichzeitig gestartet werden sollen (zum Beispiel beim Hochfahren des Amigas ins lokale LAN, aber nur bei Bedarf ins Internet), muß man selbst Hand anlegen.

Der Vorteil von AmiTCP gegenüber seinem großen Konkurrenten Miami ist der, daß AmiTCP mehrere Interfaces verwalten kann und damit auch als Router fungieren kann. Außerdem ist es viel freier zu konfigurieren und erlaubt viel mehr Einstellungen. Beachtet man, daß Miami aus dem ppp.device hervorgegangen ist, so verwundert es nicht, daß es im Grunde "nur" ein aufgeblasenes ppp.device mit schöner Oberfläche ist, das halt hinten dran keinen TCP-Stack mehr benötigt. Ganz anders hingegen AmiTCP, das einen vollwertigen Stack bietet. Will man neue, zusätzliche Dämons installieren, ist der Server einfach in ein bestimmtes Verzeichnis zu kopieren und ein Eintrag im inetd.conf zu machen. Im Miami kann man das nicht so einfach bis gar nicht.

Der Nachteil dieser Konfigurierbarkeit liegt natürlich darin, daß AmiTCP für Anfänger und Einsteiger nicht leicht zu durchblicken ist. Des weiteren gibt es für AmiTCP keine graphische Oberfläche, es muß alles in der Shell eingestellt werden. Die Unix-typische Kryptizität der Optionen und Flags und Parameter muß man erst durch intensives Studium der Dokumentation auflösen, dann jedoch findet man nichts vergleichbar Mächtiges am Amiga. Hat man sich erst einmal eingearbeitet und alles nach dem eigenen Geschmack eingerichtet (was bei Miami ja auch nicht so ohne weiteres funktioniert, dort gibt es ein vorgestaltetes GUI, das einem keine Möglichkeiten offen läßt), so gestaltet sich die Handhabung ziemlich brauchbar und auch für alltäglichen Gebrauch benützbar.

Im Verzeichnis AmiTCP:bin/ sammelt sich so einiges an mitgelieferten Programme an. Die Standardtools, wie ping, traceroute, telnet, ncftp, passwd, login fehlen genausowenig, wie auch ausgefallenere wie nslookup, resolve, aws, askhost, archie oder auch ein rsh. Allerdings läßt ein rlogin doch schmerzlich vermissen. Auch wenn man es nicht alle Tage braucht, es gehört doch irgendwie zur Vollständigkeit dazu.

Auf auf anderen Rechnern freigegebene Laufwerke kann mittels der NFS-Clients ganz einfach zugegriffen werden, es braucht nur im File AmiTCP:db/ch_fstab ein entsprechender Eintrag gemacht werden:

a2000.rockus.at:/nfsgate NFSGate: USER root

und schon kann mittels eines

ch_nfsmount NFSGATE:

Das Verzeichnis nfsgate, daß auf einem Rechner im Netz mit dem Namen a2000.rockus.at freigegeben wurde, am lokalen Rechner als Laufwerk NFSGate: angesprochen werden. Auf der Workbench erscheint brav ein Icon und dank der letzten beiden Parameter in der fstab-Zeile hat man in diesem Verzeichnis auch alle root-Rechte. Das ist sowohl praktisch als auch natürlich sehr gefährlich. Da aber Userrechte am Amiga in der Normalkonfiguraiton nicht implementiert sind, ist das fast die einzige Möglichkeit, auf NFS zuzugreifen. Eine andere Möglichkeit besteht noch darin, auf seinen Platten ein Multiuserfilesystem zu installieren, allerdings beißt sich das Format der Passwort-Verarbeitung mit dem vom AmiTCP (Für die Überspezialisten sei gesagt, daß es auch hier schon einen Workaround gibt). Will man dieses Icon, bzw. diesen Laufwerkseintrag wieder loswerden, so hilft ein ch_die NFSGate:. Damit wird die komplette Anbindung an dieses Verzeichnise freigegeben und braverweise auch das Icon von der WB wieder entfernt.

Diese Programme in AmiTCP:bin/ sind unter anderem die Clients, mit denen der lokale Rechner Verbindung mit dem Rest des Netzes aufnimmt. Will ein entfernter Rechner auf den lokalen zugreifen, müssen dafür sogenannte Dämons, oder Server, am lokalen Rechner laufen, die diese Anfrage beantworten können. In AmiTCP:serv/ sind diese zu finden:

ftpd ist der FTP-Dämon, damit andere Rechner per FTP auf Verzeichnisse in unserem lokalen Amiga zugreifen können.

in.fingerd ist ein finger-Dämon. Das hat nichts mit unanständigen Verhaltensweisen pubertierender Jugendlicher zu tun, sondern kennzeichnet einen Server, der Anfragen nach den aktuell auf dem lokalen Rechner eingeloggten Usern beantwortet.

netfs-server hat leider nichts mit einem NFS-Server zu tun, sondern stellt eine proprietäre AmiTCP-spezifische Möglichkeit dar, unter Amigas Laufwerke freizugeben und gegenseitig zu mounten.

Und schließlich der telnetd, der es ermöglicht, daß andere Rechner oder auch User per telnet auf den lokalen Rechner gelangen können.

Weitere Dämons (wie einen smtpd oder pop3d) lassen sich im Aminet finden.

Der große Vorteil von AmiTCP liegt darin, daß man, wenn man von einem Unix-Rechenr kommt, das System sofort durchschaut hat, da es genau gleich aufgebaut ist. Einzig das Verzeichnis, daß sonst /etc/ heißt, wird hier AmiTCP:db/ genannt. In diesem finden sich dann die ganzen bekannten Dateien, wie hosts, passwd, services, interfaces, protocols usw.

Ein versuchsweises Kopieren von services vom Server der TU-Graz brachte natürlich das Ergebnis, daß es ganz einwandfrei auch mit dieser Datei funktionierte, da das Format ja das Gleiche ist.

Damit man einmal die Funktionsweise dieses Stacks in Grundzügen versteht, werden wir nun einmal das Skript zum Starten des Stacks auseinandernehmen:

.key IPADDRESS .bra { .ket } .def IPADDRESS 129.27.240.2

Diese vier Zeilen dienen nur dazu, amigaspezifische Ungereimtheiten anzupassen, bzw. die Default-IP-Adresse des lokalen Rechners voreinzustellen.

AmiTCP:bin/login >NIL: -f rockus

Damit erfolgt kein Login, wie man ihn von einem Unix-Rechner oder vom Multiuser-Filesystem her kennt, sondern es wird nur AmiTCP-intern ein Username festgelegt, mit dem sich AmiTCP gegenüber anderen Rechnern meldet. Die Option -f bedeutet, daß keine Passwort-Abfrage erfolgen soll.

AmiTCP:bin/umask 022

Jedes neue File erhält bestimmte Flags, die die Zugriffsrechte beschreiben. Damit wird gesetzt, daß Files, die übers Netz von AmiTCP auf irgendeinem anderen Rechner erzeugt werden, autmatisch nur die Rechte, die 022 entsprechen, bekommen. Setzt man stattdessen 777 ein, so kann jeder mit diesem File machen was er will.

run <>NIL: AmiTCP:AmiTCP >NIL: WaitForPort AMITCP

Hier nun endlich wird der Stack gestartet und gleich darauf gewartet, bis er auch wirklich da ist. Dieses Starten hat aber alleine noch nicht viel Sinn, da noch keine Interfaces initialisiert sind, der Stack also nicht weiß, was er wohin schicken soll. Doch das folgt sogleich:

; Configure loop-back device AmiTCP:bin/ifconfig lo0 localhost

Das Programm ifconfig erklärt durch die ihm übergebenen Parameter, wie ein bestimmtes Interface zu initialisiern ist, und welche Aufgaben es hat. Hier wird das lokale Interface (lo0 genannt, das auf jedem Rechner im Netz existieren muß, eingerichtet. Der Parameter, der darauf folgt, gibt die IP-Adresse dieses Interfaces an. Hier also localhost, was nur den lokalen Rechner beschreibt. Damit kann man über den TCP/IP-Stack wieder auf sich selber zurückgreifen. Deshalb wird dieses Interface auch Loopback-Device genannt.

; Configure ariadne AmiTCP:bin/ifconfig ariadne 192.168.1.1 192.168.1.255

Hier wird es nun schon interessanter. Der Aufruf unterscheidet sich nicht wesentlich von Obigem, allerdings wird als Interface ariadne angegeben, und das ist ja eine der Netzwerkkarten für den Amiga. Es wird also AmiTCP dahingehend unterrichtet, daß die eingebaute Ariadne-Karte die IP-Adresse 192.168.1.1 bekommen soll. Das ist (wie schon im ersten Teil erläutert), eine der IP-Adressen, die nicht im globalen Internet geroutet werden, und somit für private Netzte verwendet werden kann. Der Parameter danach gibt die Broadcast-Adresse für dieses Interface an. Broadcasts sind Messages, die an alle Rechner in diesem Netzsegment geschickt werden, und alle Rechner müssen daher auf die gleiche Broadcast-Adresse reagieren.

Damit dieses Interface initialisiert werden kann, ist ein entsprechender Eintrag in AmiTCP:db/interfaces nötig.

Will man zum Beispiel ein zweites Interface parallel dazu starten, genügt ein weiterer Eintrag in startnet oder man schreibt diese Zeilen in ein eigenes Skript-File, das man dann irgendwann später ausführen kann. Das ist zum Beispiel bei Einwahl bei einem Provider per Modem erforderlich.

Dazu können folgende Zeilen dienen:

online >NIL: amippp

Damit wird zum Beispiel das AmiPPP-Device online geschaltet, was bewirkt, daß es sich selbstänsidg beim Provider einzuwählen und anmelden versucht.

IF NOT WARN AmiTCP:bin/ifconfig >NIL: amippp $AmiPPPipLocal $AmiPPPipRemote AmiTCP:bin/route >NIL: add default $AmiPPPipRemote

Gelingt das, so wird das entsprechende Interface (amippp) konfiguriert und die Defaultroute ins internet "verlegt".

ELSE AmiTCP:bin/Hangup ENDIF

Funktioniert es nicht, wird wieder aufgelegt. Dieses Hangup-Skript besteht im einfachsten Fall einfach aus der Zeile:

offline >NIL: amippp

Damit wird das Device offline geschaltet, das Modem legt auf und die Verbindung wird automatisch umkonfiguriert, daß es keine Verbindungen mehr zuläßt.

Aber nun weiter in startnet

Add route to the default gateway AmiTCP:bin/route add default 192.168.1.1

Das bisher war aber noch gar nichts, denn erst mit route legen wir fest, welche Pakete wohin geschickt werden sollen. AmiTCP erkennt automatisch, wenn Pakete auf eines der konfigurierten Interfaces paßt und schickt sie selber dorthin. Aber für alle die Pakete, die nirgends hinpassen, wird eine Default-Route benötigt, damit auch diese abgeschickt werden können. Im Normalfall wird das natürlich ein Interface sein, durch das das Internet erreicht werden kann. Hier allerdings wird nur gesagt, daß eine neue Route angelegt werden soll (add), diese soll die voreingestellte Route für alle sonst nicht zustellbaren Pakete sein (default) und die Route weißt nach 192.168.1.1.

setenv HOSTNAME 'AmiTCP:bin/hostname'

Der Befehl hostname liefert den aktuellen Namen des lokalen Rechners, der sich zum Beispiel beim Einwählen in einen Rechner eines Providers ja immer wieder ändern kann. Dadurch wird also eine Umgebungsvariable gesetzt, die den aktuellen Hostnamen enthält.

Assign TCP: Exists > NIL: IF Warn   Mount TCP: from AmiTCP:devs/Inet-Mountlist EndIf

Eine ganz praktische Sache am AmiTCP ist der TCP:-Handler, der damit gestartet wird. Damit ist es ganz einfach möglich, zum Beispiel per ARexx auf andere Server und deren Diesnte zuzugreifen. Ein Beispiel dafür ist im File AmiTCP:bin/SynClock gegeben, daß die lokale Uhrzeit nach einem Zeitserver im Netz ausrichtet.

; Start the internet 'super server' run <>NIL: AmiTCP:bin/inetd <>NIL:

Und nun schlußendlich wird der Internet-Dämon gestartet, der zwar nach Internet klingt, aber nichts damit zu tun hat. Er ist vielmehr dafür da, die einkommenden Anfragen an die entsprechenden Server (oder Dämons) aufzuteilen. Wie er das machen soll, steht in AmiTCP:db/inetd.conf

Es sei eine beispielhafte Zeile herausgenommen:

ftp   stream   tcp nowait root AmiTCP:serv/ftpd ftpd -l -x -b30 -G

Diese legt fest, daß bei einer Anfrage auf dem FTP-Port, der TCP-Verbindungen (im Gegensatz zu UDP-Verbindungen) hereinläßt, der Server AmiTCP:serv/ftpd mit root-Berechtigungen gestartet werden soll und dieser soll dann die Anfrage beantworten. Der Rest der Zeile sind Parameter, die direkt dem Dämon übergeben werden.

Die Festlegung der Namen der Ports zu ihrer Nummer geschieht in der Datei AmiTCP:db/services:

ftp 21/tcp        ; file transfer

Also soll alles, was am Port 21 an TCP-Verbindungen hereinkommt, an einen ftp genannten Port weitergeleitet werden.

Um wieder aus dem Netz auszusteigen und den Stack zu beenden, gibt es ein stopnet-Skript, mit dem ein geordneter Rückzug möglich ist:

.KEY FLUSH/S .BRA { .KET }

...und wieder die Amiga-Spezialitäten...

FailAt 21 Version bsdsocket.library >nil:

Ist eine bsdsocket.library im System bekannt, so wurde AmiTCP gestartet...

If NOT Warn   If Exists AmiTCP:db/User-Stopnet     Execute AmiTCP:db/User-Stopnet   EndIf

... und sollte eine User-spezifische stopnet-Datei vorhanden sein (zum Beispiel, um sich irgendwo auszuloggen), so wird auch die noch abgearbeitet.

Rx "address AMITCP; KILL" ; Send "KILL" to AmiTCP

Damit wird aber nun unwiderruflich und brutal das AmiTCP abgewürgt und aus dem System geschmissen. Obwohl es so brutal aussieht, ist das die offizielle Methode.

  If {FLUSH}     Wait 3 secs     If 'rx "Say Show(ports, AMITCP)"' EQ 0       Avail >NIL: FLUSH     Else       Echo Memory NOT flushed!     EndIf   EndIf

In manchen Fällen kann es vorkommen, daß ein Teil der Ports, die AmiTCP belegte, nicht aus dem System entfertn wird und es dazu zu Speicherverlust kommt. Damit wird das überprüft (ob vielleicht nach dem Beenden von AmiTCP noch immer Ports existieren) und gegebenenfalls eine Meldung ausgegeben.

Else   Echo AmiTCP/IP is not running. EndIf

Wird oben keine bsdsocket.library gefunden, ist AmiTCP gar nicht gelaufen. Was soll dann also beendet werden?

Danach kann ganz normal wieder ein startnet ausgeführt werden, um wieder das Netz zu starten.

Von den drei Stacks, die am Amiga derzeit verfügbar sind, ist AmiTCP sicher der umfassendste. Nicht zuletzt auch, weil es im Aminet massig Zusatzprogramme und -tools dafür gibt, die die Leistungsfähigkeit noch weiter erhöhen. Nachteilig wirkt sich in heutigen Zeiten natürlich die fehlende GUI aus, was aber durch den Funktionsumfang und die Routerfähigkeit mehr als wettgemacht wird. Im Vergleich zu Miami kann AmiTCP mit seiner freien Konfigurierbarkeit und Leistungsfähigkeit glänzen, muß aber im Vergleich zu I-Net 225 den fehlenden NFS-Dämon zähneknirschend akzeptieren. Bis heute gibt es für den Amiga nur einen einzigen NFSd und der ist nicht der Weiheist leztzter Schluß. Also, Leute, auf ans Programmieren!

Als Zugabe sind meine Miniskripts zur Einwahl bei einem Provider mit cSLIP bzw. PPP dabei. Nähere Informationen und Konfigurationshinweise stehen auf dem Web-Server der TU-Graz.

Oliver Gerler ...........

AmiTCP - Homepage

PPP-Scripts

Workshop Teil 1

Demoversion von AmiTCP [Aminet; Austria]

cSLIP-Skripts

Workshop Teil 2

....