Inhalt

2. Die Protokolle bei Packet Radio und Linux

Das AX.25-Protokoll gestattet den Betrieb sowohl mit als auch ohne laufende Verbindungen und wird entweder selbst zur Herstellung von Punkt-zu-Punkt-Verbindungen oder als Träger für andere Protokolle wie TCP/IP oder NET/ROM eingesetzt.

Es entspricht in seinem Aufbau dem X.25-Protokoll mit einigen amateurfunkspezifischen Erweiterungen. Das NetROM-Protokoll ist ein Versuch eines vollständigen Netzwerkprotokolls und nutzt AX.25 auf seiner niedrigsten Ebene als Protokoll zum Datenaustausch. Es stellt eine Netzwerkebene zur Verfügung, die eine angepaßte Form des AX.25 darstellt. Das NetROM-Protokoll bietet dynamisches Routing und Aliases für die einzelnen Nodes.

Das ROSE-Protokoll wurde von Tom Moulton (W2VY) entwickelt und implementiert. Es stellt eine Implementation des X.25-Packet-Layer-Protokolls dar, wurde für das Zusammenwirken mit AX.25 als Datalink entworfen und stellt ebenfalls eine Netzwerk-Ebene zur Verfügung.

ROSE-Adressen sind zehnstellige Nummern. Die ersten vier sind der sog. Data Network Identification Code (DNIC) und stammen aus dem Zusatz B der CCITT X.121-Empfehlung.

Mehr Informationen zum ROSE-Protokoll gibt es auf dem RATS (Radio Amateur Teleprinter Society) -Web-Server:

http://www.rats.org/

Das FPAC/Linux-Projekt als eine ROSE-Anwendung ist auf

http://www.qsl.net/fpac

zu finden.

Alan Cox entwickelte die frühe Kernel-Unterstützung für AX.25. Jonathan Naylor (g4klx@g4klx.demon.co.uk) entwickelte den Code weiter, fügte NetROM- und ROSE-Unterstützung hinzu und ist jetzt der Entwickler des AX.25-Codes für den Kernel.

Die Unterstützung für DAMA wurde von Joerg (DL1BKE, jreuter@lykos.tng.oche.de) entwickelt. Thomas Sailer (sailer@ife.ee.ethz.ch) fügte die Unterstützung für BayCom- und SoundModem hinzu. Die AX-25-Utilities werden von Craig Small (csmall@debian.org) betreut. Der Linux-Code unterstützt KISS-basierte TNCs (Terminal Node Controllers), die Ottawa PI-Card, die Gracilis PacketTwin-Karte und andere SCC-Karten auf der Basis des Z8530 mit dem allgemeinen SCC-Treiber sowie parallele und serielle BayCom-Modems.

Der SoundModem-Treiber von Thomas Sailer unterstützt den SoundBlaster und die Soundkarten auf der Basis des Crystal-Chipsatzes. Die Anwenderprogramme enthalten ein einfaches PMS (Personal Message System), eine Möglichkeit, Baken auszusenden, ein zeilenorientiertes Programm zum Verbindungsaufbau, 'listen', ein Beispiel, wie man alle AX.25-Pakete an einem Interface mitlesen kann und Programme zur Einrichtung des NetROM- Protokolls. Ebenso sind ein AX.25-Server-Programm zur Verwaltung eintreffender Verbindungen und ein NetROM-Daemon, der den Hauptanteil der NetROM- Funktionalität übernimmt, vorhanden.

2.1 Wie alles zusammenpaßt

Die AX.25-Implementation bei Linux ist noch sehr neu. Obwohl sie an vielen Stellen NOS, BPQ oder anderen Implementationen ähnelt, ist sie keine von diesen. Man kann sie so einrichten, daß sie sich fast wie andere Implementationen verhält, die Konfiguration ist jedoch vollkommen anders. Um beim Verständnis der Einrichtungsweise zu helfen, soll dieser Abschnitt einige strukturelle Eigenschaften beschreiben und darstellen, wie sie sich in die Systemstruktur von Linux einfügen.

Vereinfachte Zeichnung der Protokoll-Ebenen:

+----------+-----------+----------+----------+
| AF_AX25  | AF_NETROM | AF_INET  | AF_ROSE  |
|==========|===========|==========|==========|
|          |           |          |          |
|          |           | TCP/IP   |          |
|          |           +-------+  |          |
|          | NetROM            |  |          |
|          +-------------------+--+----------+
|      A  X  .  2  5                         |
+--------------------------------------------+

Diese Darstellung soll zeigen, daß NetROM, ROSE und TCP/IP alle direkt auf AX.25 aufgesetzt laufen, aber jedes Protokoll als einzelnes Protokoll an der Programmierschnittstelle behandelt wird. Die »AF_«-Namen sind die Namen für die Adreßfamilie jedes Protokolls, wie sie in den darauf aufsetzenden Programmen verwendet werden. Wichtig ist also die richtige Konfiguration der AX.25-Geräte, bevor man die NetROM-, TCP/IP- oder ROSE-Devices einrichten kann.

Darstellung der Linux-Netzwerk-Implementation:

 
---------+-----------+------------------++----------+------------------------
Anwender | Programme | call     node    || Daemonen | ax25d   mheardd
         |           | pms      mheard  ||          | inetd   netromd
---------+-----------+------------------++----------+------------------------
         | Sockets   | open(), close(), listen(), read(), write(), connect()
         |           +-----------+-----------+--------------+----------------
         |           | AF_AX25   | AF_NETROM |  AF_ROSE     | AF_INET
         +-----------+-----------+-----------+--------------+----------------
         | Protokolle| AX.25     | NetROM    |  ROSE        | TCP/IP/UDP
Kernel   +-----------+-----------+-----------+--------------+----------------
         | Devices   | ax0, ax1  | nr0, nr1  | rose0, rose1 | eth0, ppp0...
         +-----------+-----------+-----------+--------------+----------------
         | Treiber   | KISS, PI2, PacketTwin, SCC, BPQ,     | slip, ppp,
         |           |       SoundModem, BayCom             | ethernet
---------+-----------+--------------------------------------+----------------
Hardware | PI2-Karte, PacketTwin-Karte, SCC-Karte, Serielle Schnittstelle,
         | SoundBlaster, Ethernet-Karte
---------+-------------------------------------------------------------------

Diese Zeichnung ist ein wenig allgemeiner als die erste. Sie soll den Zusammenhang zwischen Anwenderprogrammen, Kernel und Hardware und die Beziehungen von Programmierschnittstelle, Protokoll-Modulen, Kernel-Netzwerk-Devices und Gerätetreibern untereinander verdeutlichen. In dieser Darstellung ist jeder Teil von dem, was darunter steht, abhängig, man muß also von »unten« (Hardware) nach »oben« (Programme) alles der Reihe nach einrichten. Beispiel: Will man das Programm »call« starten, so muß man zunächst die Hardware einrichten, dann sicherstellen, daß der Kernel den passenden Treiber geladen hat, das zugehörige Netzwerk-Device erzeugt wurde und das zur Nutzung durch »call« gewünschte Protokoll im Kernel enthalten ist. Dieser Text wird sich im großen und ganzen an diese Reihenfolge halten.


Inhalt