| TCP/IP (Teil 4): LAN | Diskarchive |

TCP/IP (Teil 4): LAN - Längst ausufernde Nichtigkeiten

Es war eine längere "Sommerpause", die unsere TCP/IP-Artikelserie unterbrach, nun aber geht es voller Vorfreuden auf Köln auf in die nächste Runde, die da lautet, Amigas in ein lokales Netz zu hängen.

"Was soll das eigentlich? Wofür brauch ich denn das?" mag sich da so mancher fragen. Nur weil diese Spinnen ihre Produkte überall hinspannen und auch vor so manchen Teichen keinen Halt machen, braucht man das doch zu Hause nicht, oder?

Alles ist Ansichtssache, und eine ist, daß man sich den Amiga ja auch ins Büro stellen kann und dort per Standleitung mehr im bunten Netz zu finden ist, als produktive Arbeit tut. Eine andere, daß man zu Hause die Daten auf den anderen Rechnern auch zur Verfügung haben will, nicht dauernd mit Disketten rumrennen will, gegenseitig sich seine Devices mounted und diverse Drucker im Netzwerk zum Arbeiten drängt. Damit solche Dienste möglich sind, braucht man aber immer eine Grundlage, den TCP-Stack. Wie in Teil 3 (entsprechende Links am Ende dieses Textes) gesehen, gibt es am Amiga dafür AmiTCP und I-Net 225. Anhand von AmiTCP soll nun gezeigt werden, wie relativ simpel so eine Einbindung möglich ist.

Start me Up!

Aller Netz Anfang ist wie immer das startnet-Skript, aufgerufen aus der User-Startup per run >NIL: startnet, das nicht nur den Stack ins Leben ruft, sondern auch diverse Interfaces konfiguriert und interessanten Daemons die Daseinsberechtigung verschreibt.

Das Wichtigste am startnet ist in diesem Zusammenhang sicher die Konfiguration der einzelnen Interfaces. Wie schon in den ersten Teilen gesehen, benötigt jeder einzelner Rechner im Netz eine eindeutige IP-Adresse, über die er erkannt werden kann (technisch gesehen ist auch die IP-Adresse nur eine Art Assign auf die MAC-Adresse, die einer Netzwerkkarte hardwaremäßig eingeprägt ist).

Zum Zwecke lokaler Netze, die nicht mittels registriertem IP-Adressen-Pool, sondern durch Tricks wie Proxy-Server, Firewalls oder IP-Masquerading in Verbindung mit dem Rest der Welt sind, gibt es eben einige Bereiche innerhalb der IP-Adressen, die für private Netze verwendet werden können. Eines davon ist zum Beispiel 192.168.0.0 bis 192.168.255.255. In diesem Bereich kann man sich nehmen, was man will, das wird sowieso nicht nach aussen weitergegeben.

Damit aber der TCP-Stack auch weiß, welche MAC-Adresse (über die die Rechner, bzw. eigentlich nur die Netzwerkkarten, ja de facto angesprochen werden) nun welcher IP-Adresse zuzuordnen ist, müssen die Interfaces konfiguriert werden: für jede Netzanbindung eines. So ist bei mehreren Netzwerkkarten in einem Rechner auch für jede Karte ein eigenes Interface aufzubauen, soll über die parallele Schnittstelle ein Netzwerkprotokoll gefahren werden, wird diese Schnittstelle ebenfalls als Interface abgebildet, selbiges gilt natürlich auch für die Serielle, die ja schon in Teil 3 als Verbindung zum Modem zu ihren Ehren kam.

So ist nun auch die folgende Zeile aus startnet zu verstehen:

AmiTCP:bin/ifconfig ariadne 192.168.1.1 192.168.1.255

Das ganze Skript ist am Ende des Textes verlinkt.

ifconfig konfiguriert nun das Device namens ariadne auf die Adresse 192.168.1.1. Damit ist dieser Rechner in dem Netzwerkteil, der an dieser Ariadne dranhängt, unter der Adresse 192.168.1.1 erreichbar und meldet sich auch brav auf diverse pings und ähnliches. Die zweite IP-Adresse ist zuständig für Broadcast-Messages, die alle Karten/Rechner in dem dieser Karte zugeordneten Netzsegment erreichen soll. Im Normallfall ist das immer eine IP-Adresse mit gleicher Netzangabe und 255 an der oder den letzten Stellen. Damit funktioniert dieses Interface aber nur, wenn auch im File AmiTCP:db/interfaces eine Zeile drinnensteht, die das (virtuelle) Interface ariadne einer physikalisch vorhandenen Karte zuordnet:

ariadne DEV=DEVS:Networks/ariadne.device UNIT=0

Damit wird die erste Ariadne im Amiga angesprochen. Gibt es derer mehrerer, so wird eben die UNIT hinaufgezählt.

In diesem interfaces-File sind auch noch ganz interessante andere Devices aufgezählt, wie zum Beispiel ein liana, das eben die parallele Schnittstelle über Liana (dem TCP-Treiber für die Parallele von VillageTronic) ins Netz einbindet. Somit wird es eben auch möglich, Amigas in Netze einzubinden, in die keine Netzwerkkarte gesteckt werden kann, wie ein 500er, CDTV oder solche "Exoten". 600er und 1200er haben es schon wieder einfacher, da es für den PCMCIA-Port bei jedem besserem Computer-Händler Netzwerkkarten gibt, die damit funktionieren. Eine davon ist die C-Net, für die es im Aminet das entsprechende Sana-II-Device (eben das cnet.devic e) gibt, mit dem auch diese Rechner in ein Ethernet direkt eingebunden werden können. Bei der Anbindung über die parallele Schnittstelle weiß ja nur der Amiga auf der anderen Seite etwas von diesem weiteren Mitglied im immer dichtwerdenden Fallstricke-werfenden Spinnennetz.

Wege und Unwege

Damit nun auch ein jeder weiß, welche Pakete über welches Netz wann wohin geschickt werden sollen, gibt es die Routes, die ebendieses festlegen. Genialerweise kann das AmiTCP (wie nun auch das neue Miami in seiner Deluxe-Ausführung - derzeit als Beta von NordicGlobal zu haben) routen und somit ist es aber notwendig, dem TCP-Stack zu sagen, welche Packl er wohin schicken soll. Dieses geschieht mittels route-Kommandos in zum Beispiel folgender Form:

AmiTCP:bin/route add default 192.168.1.100

Das bedeutet, daß die Daten-Pakete, die sonst nirgends hinpassen, zu dem Interface weitergeleitet werden, zu dem 192.168.1.100 hört. Die Auswahl des richtigen Interfaces geschieht mittels Netmask (bitweise AND-Verknüpfungen führen hier zum Erfolg). Setzt man statt default die Netz-Klasse eines Bereiches ein, der an einem anderen Interface hängt (im Extremfall auch nur eine einzelne IP-Adresse, wenn es zum Beispiel eine Verbindung über die Parallele zu einem anderen Amiga ist), werden alle Pakete, die in dieses Schema passen, dann dorthin geroutet.

Ich bin ich?!?

Damit sich der Amiga auch wieder selber kennt, sind obige Angaben auch noch für ein LoopBack-Interface nötig, das immer auf die Adresse 127.0.0.1 hört. Die Adresse 127.0.0.1 ist immer und auf jedem Rechner, auf dem ein TCP-Stack läuft, dieser rechner selber und sonst keiner. Macht man also ein ping 127.0.0.1 und erhält Antworten, sagt das zwar nichts über den Zustand des Netzes aus, aber immerhin läuft schon mal lokal ein TCP-Stack.

Dessenthalben sollten folgende Zeilen im oft bemühten startnet-Skript auch nicht fehlen:

AmiTCP:bin/ifconfig lo0 loopback AmiTCP:bin/route add 192.168.1.1 localhost

Statt 192.168.1.1 muß natürlich die aktuelle Adresse des Rechners eingetragen werden.

testing...

Ein kleines unscheinbares Progrämmchen, das bis hierher schon zur Anwendung kam, hilft auch, um die Einstellungen zu überprüfen. Läuft der TCP/IP-Stack, so kann man in einer Shell einmal ifconfig aufrufen, das etwa Folgendes auswerfen sollte:

lo0: flags=C9<UP,LOOPBACK,RUNNING,NOARP> MTU=1536 inet 127.0.0.1 netmask FF000000 Hardware type: Loopback ariadne: flags=4863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,SANA> MTU=1500 inet 192.168.1.1 netmask FFFFFF00 broadcast 192.168.1.255 Hardware type: Ethernet, address: 0:60:30:0:2:75

Die letzte Zahl mit den vielen Doppelpunkten dazwischen ist diese berüchtigte MAC-Adresse, die weltweit einmalig sein sollte und anhand derer die Netzwerkkarten/Rechner auseinandergehalten werden können.

Daran sieht man nun, daß das Interface namens ariadne, dem aller Wahrscheinlichkeit nach, außer irgendwer hat die Voreinstellungen völlig durcheinandergeworfen, eine Ariadne-Karte zugeordnet sein wird, unter 192.168.1.1 sich meldet. Die netmask ist in dieser Voreinstellung richtig und "beschreibt", was für einer Netzklasse diese IP-Adresse zugeordnet wird und welche Pakete mit welchen Zieladressen an dieses Interface geschickt wird (im Falle von ariadne eben alles von 192.168.1.0 bis 192.168.1.254). Die Adresse 192.168.1.255 ist für Broadcasts vorgesehen, und dementsprechend hinten ausgegeben. Diese beiden Angaben sind in dieser Zusammenstellung die Vorgabe und brauchen somit nicht extra angegeben zu werden. Die MTU (Maximum Transfer Unit) legt die maximale Größe fest, die ein Paket über dieses Interface haben kann. Größere Pakete werden entsprechend aufgeteilt und geteilt verschickt. Grundsätzlich sind höhere Werte sinnvoll, es bringt aber nichts, diese Werte hier zu verändern, da das nächste Interface, über das die Daten geroutet werden, wieder die Standardeinstellung haben wird und nun also dort die Pakete zerteilt werden. Oben angebene Werte haben sich davon abgesehen aber sowieso als am Sinnvollsten erwiesen.

Ist da sonst gar nichts mehr??

Aber freilich. Da gibt es noch genug an kleinen und noch kleineren Helferleins, die das tägliche Netzbefinden angenehmer gestalten, aber um die Grundeinstellungen vornehmen zu können, damit sich der Amiga im Netz befindet, ist das soweit alles.

Will man freilich, daß der Amiga auch auf Messages von außen reagiert, so müssen die entsprechenden Daemons, oder Server, zu finden in AmiTCP:serv/ konfiguriert werden. Dafür ist die Datei AmiTCP:db/inetd.conf zuständig.

Ein Einloggen auf den Rechner ist zum Beispiel mit folgender Zeile in diesem File möglich:

telnet stream tcp nowait root AmiTCP:serv/telnetd

Ein FTP-Daemon für FileTransfers wird so gestartet:

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

Damit wird es nun möglich, sich die Dateien von aussen aus anzusehen, wie wenn man aus dem Aminet was holte.

Es ist also gar nicht so kompliziert, sich mit dem Amiga in einem lokalen Netzwerk sich breitzumachen, sollten aber dennoch weiter Fragen bestehen, reicht eine Mail an den Autor.

Oliver Gerler

Die TCP/IP Serie:

Teil 1: Geschichte/Grundlagen

Teil 2: Adressen/Klassen

Teil 3a: AmiTCP

Teil 3b: I-Net 225

Teil 4: lokales Netz

Teil 5: Die Exoten (Envoy, Samba, NFS, ...)

cnet.device - Auch PCMCIA-Netzwerkkarten sind am Amiga zu gebrauchen!

NordicGlobal - Miami Deluxe

NetConnect - Die Netzwerksuite für Amigas

NetConnect Test (AmigaScene)

startnet-Skript (TXT; 0K)