Linux AX25 HOWTO <author>Terry Dawson (<tt>terry@perf.no.itg.telstra.com.au</tt>) und Gerd Röthig (<tt>roetg@medizin.uni-leipzig.de</tt>) <date>v1.6-2, 8. Juli 1999 <abstract> Das Betriebssystem Linux ist vielleicht das einzige, das eine eingebaute Unterstützung für das im Packet Radio verwendete AX.25-Protokoll bietet. Dieser Text beschreibt, wie man diese Unterstützung installiert und einrichtet. </abstract> <toc> <sect>Einführung <p> Dieses HOWTO beschreibt, wie man die AX.25-, NetROM- und ROSE-Unterstützung unter Linux installiert und einrichtet. Einige typische Konfigurationen sind beispielhaft aufgeführt und können als Ausgangsbasis dienen. Die Implementation der Amateurfunk-Protokolle unter Linux ist sehr flexibel. Für Neulinge wird die Konfiguration reichlich kompliziert und verwirrend erscheinen. Es braucht ein wenig Zeit, bis man versteht, wie alles zusammenpaßt. Die Konfiguration wird sich als schwierig erweisen, wenn man sich nicht entsprechend vorbereitet und über Linux im allgemeinen informiert hat. Zur Zeit ist mit der Einführung des Linux-Kernels 2.2.x auch das AX.25-Subsystem tiefgreifenden Veränderungen unterworfen. Dieses HOWTO wird darauf in kommenden Fassungen ausführlicher eingehen, wenn erste Erfahrungen mit der neuen Software vorliegen. Die im folgenden beschriebenen Konfigurationshinweise und Beispiele beziehen sich daher, wenn nicht ausdrücklich anders vermerkt, auf ein Linux-System mit Kernel 2.0.37, libc5 und ax25-utilities-2.1.42a. <sect1>Wo bekommt man neue Versionen dieses Textes <p> Den englischen Originaltext findet man im Archiv des Linux-Dokumentation-Projektes. Die WWW-Fassung findet sich hier: <tscreen> <htmlurl url="http://metalab.unc.edu/LDP/HOWTO/AX25-HOWTO.html" name="http://metalab.unc.edu/LDP/HOWTO/AX25-HOWTO.html"> </tscreen> Man kann Terry Dawson (<tt>terry@perf.no.itg.telstra.com.au</tt>) auch direkt fragen; neue Versionen wird er jedoch sofort dem Koordinator des LDP schicken, so daß man immer erst bei metalab nachsehen sollte. Gibt es dort keine neue Version, so ist es wahrscheinlich, daß sie noch nicht fertig ist. Die deutsche Version findet man beim DLHP: <tscreen> <htmlurl url="http://www.tu-harburg.de/dlhp/" name="http://www.tu-harburg.de/dlhp/"> </tscreen> <sect1>Weitere Informationen zu diesem und verwandten Themen <p> Es gibt eine Menge weitere Dokumentation. Viele Texte befassen sich mit Netzwerken und Linux im allgemeinen und es wird wärmstens empfohlen, diese zu lesen, da sie bei eigenen Bemühungen helfen und Wege zu weiteren möglichen Konfigurationen aufzeigen. Folgende Texte sind empfehlenswert: <itemize> <item><em><htmlurl name="HAM HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/HAM-HOWTO.html"></em> <item><em><htmlurl name="NET-3 HOWTO" url="DE-NET-3-HOWTO.html"></em> <item><em><htmlurl name="Ethernet HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/Ethernet-HOWTO.html"></em> <item><em><htmlurl name="Firewall HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/Firewall-HOWTO.html"></em> </itemize> Allgemeinere Informationen zu Linux findet man in den anderen Linux-HOWTO-Dokumenten: <tscreen> <htmlurl url="http://metalab.unc.edu/LDP/HOWTO/" name="http://metalab.unc.edu/LDP/HOWTO/"> </tscreen> <sect>Die Protokolle bei Packet Radio und Linux <p> 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: <tscreen> <htmlurl url="http://www.rats.org/" name="http://www.rats.org/"> </tscreen> Das FPAC/Linux-Projekt als eine ROSE-Anwendung ist auf <tscreen> <htmlurl url="http://www.qsl.net/fpac" name="http://www.qsl.net/fpac"> </tscreen> zu finden. Alan Cox entwickelte die frühe Kernel-Unterstützung für AX.25. Jonathan Naylor (<tt>g4klx@g4klx.demon.co.uk</tt>) 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, <tt>jreuter@lykos.tng.oche.de</tt>) entwickelt. Thomas Sailer (<tt>sailer@ife.ee.ethz.ch</tt>) fügte die Unterstützung für BayCom- und SoundModem hinzu. Die AX-25-Utilities werden von Craig Small (<tt>csmall@debian.org</tt>) 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. <sect1>Wie alles zusammenpaßt <p> 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: <tscreen><verb> +----------+-----------+----------+----------+ | AF_AX25 | AF_NETROM | AF_INET | AF_ROSE | |==========|===========|==========|==========| | | | | | | | | TCP/IP | | | | +-------+ | | | | NetROM | | | | +-------------------+--+----------+ | A X . 2 5 | +--------------------------------------------+ </verb></tscreen> 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: <tscreen><verb> ---------+-----------+------------------++----------+------------------------ 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 ---------+------------------------------------------------------------------- </verb></tscreen> 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. <sect>Die Software zu AX.25/NetROM/ROSE <p> Die AX.25-Software besteht aus drei Komponenten: <itemize> <item>dem Kernel-Quelltext <item>den Netzwerk-Konfigurationsprogrammen <item>den Utilities. </itemize> In den Kernel-Versionen 2.0.35, 2.0.36 und 2.0.37 sind die Treiber für AX.25, NetROM, Z8530 SCC, PI-Karte und PacketTwin standardmäßig in einer aktuellen Version enthalten. Zum Kernel 2.2.x siehe Anmerkungen am Ende dieses Textes. <sect1>Woher bekommt man den passenden Kernel und die Software <p> <sect2>Die Kernel-Quelltexte <p> Diese sind an der üblichen Stelle bei <tt><htmlurl url="ftp://ftp.kernel.org" name="ftp.kernel.org"></tt> zu finden. Empfohlen wird <tt>linux-2.0.37.tar.gz</tt>. Es gibt keinen Grund, eine andere als diese Kernel-Version aus der 2.0.x-Reihe zu verwenden. Wer seinen Kernel von älteren Versionen auf 2.0.37 aktualisieren will, sollte das komplette Quelltextarchiv herunterladen, da es mit Patches auf 2.0.37 zu Problemen kommt, wenn die vorherigen Kernel-Quellen nicht mehr »original« sind. Im Hinblick auf die Kernel der 2.2.x-Reihe sind die Mirrors von <tt>ftp.kernel.org</tt> die erste Wahl. Die Adresse des zu bevorzugenden Mirrors erhält man, indem man den Landes-Suffix einfügt; aus <tt>ftp.kernel.org</tt> wird für Deutschland demnach <tt>ftp.de.kernel.org</tt> (für Nutzer kommerzieller Onlinedienste <tt>ftp2.de.kernel.org</tt>). Dort findet man die aktuellen Kernel-Archive unter <tt>/pub/linux/kernel/v2.2/</tt>. <sect2>Programme für die Netzwerkkonfiguration <p> <sect3>Die Net-Tools <p> Die aktuelle Version der Standard-Linux-Netzwerk-Tools unterstützt AX.25, NetROM und ROSE, sie findet sich auf <tscreen> <htmlurl url="http://www.tazenda.demon.co.uk/phil/net-tools/" name="http://www.tazenda.demon.co.uk/phil/net-tools/"> </tscreen> als <tt>net-tools-1.52.tar.gz</tt>. <sect3>Firewall-Konfiguration <p> Die neueste Version des ipfwadm (IP Firewall Administrator) für den Kernel 2.0.37 kann hier bezogen werden: <tscreen> <htmlurl url="ftp://ftp.xos.nl/pub/linux/ipfwadm" name="ftp.xos.nl:/pub/linux/ipfwadm"> </tscreen> Wer eine aktuelle Distribution einsetzt, sollte vor dem Download prüfen, ob diese Pakete nicht bereits installiert bzw. auf der Installations-CD enthalten sind. Wer auf seinem System eine Nettools-Version größer 1.33 vorfindet, braucht sie sich nicht nochmals zu installieren. Gleiches trifft auf ipfwadm zu. Hier ist 2.3.0 die aktuelle Version (wird mit <tt>ipfwadm -h</tt> angezeigt). Für die Kernel der 2.2.x-Reihe gibt es an Stelle von ipfwadm das Programm ipchains. Zu finden ist es hier: <tscreen> <htmlurl url="ftp://ftp.starshadow.com/pub/rustcorp/ipchains/" name="ftp.starshadow.com:/pub/rustcorp/ipchains/"> </tscreen> Das Programm wird auf <tscreen> <htmlurl url="http://www.rustcorp.com/linux/ipchains/" name="http://www.rustcorp.com/linux/ipchains/"> </tscreen> vorgestellt. <sect2>Die AX.25-Utilities Version 2.1.42a <p> Die empfohlene Version der AX.25-Utilities für den Kernel 2.0.37 auf libc5-basierten Systemen ist <tt>ax25-utils-2.1.42a</tt>. Zu finden ist sie hier: <tscreen> <htmlurl url="ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/" name="ftp.funet.fi:/pub/ham/unix/Linux/packet/ax25/"> </tscreen> Ältere Versionen sollten nicht eingesetzt werden. Binäre Pakete zur direkten Installation unter RedHat 5.2 oder S.u.S.E. 6.0 finden sich unter: <tscreen> <htmlurl url="ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/packages/libc6/rpm" name="ftp.funet.fi:/pub/ham/unix/Linux/packet/ax25/packages/libc6/rpm"> </tscreen> Wichtig ist hierbei, sowohl <tt>ax25-utils-2.1.42a-3.i386.rpm</tt> als auch <tt>ax25-utils-devel-2.1.42a-3.i386.rpm</tt> zu installieren, damit auf dem AX.25-Subsystem aufbauende Software kompiliert werden kann. Dem Debian-Archiv <tt>ax25-utils_2.1.42a-6.deb</tt> fehlt auf Grund einer Fehlinformation der Verantwortlichen (man nahm Lizenzprobleme an) das Programm smdiag, so daß es nur für diejenigen geeignet ist, die weder BayCom- noch SoundModem verwenden möchten. Neue Version 0.0.1 Für Kernel 2.2.10 gibt es eine komplett überarbeitete Fassung der AX.25-Utilities und der benötigten Bibliotheken: <tscreen> <htmlurl url="ftp://ftp.hes.iki.fi/pub/ham/linux/ax25" name="ftp.hes.iki.fi:/pub/ham/linux/ax25"> </tscreen> Da sich sowohl Software als auch Bibliotheken in einer Alpha-Version befinden und in nächster Zeit weiter entwickelt werden sollen, wurde das Archiv in die Bestandteile <tt>ax25-apps-0.0.2.tar.gz</tt>, <tt>ax25-tools-0.0.3.tar.gz</tt> und <tt>libax25-0.0.5.tar.gz</tt> aufgeteilt, die zur Installation dieser Version vollständig benötigt werden. Weitere Informationen liefert diese WWW-Seite: <tscreen> <htmlurl url="http://www.eye-net.com.au/hamradio/" name="http://www.eye-net.com.au/hamradio/"> </tscreen> Vorausgesetzt wird ein installiertes XFree86, zumindest aber die Bibliothek libX11, da sich sonst das Programm smdiag nicht kompilieren läßt. Viele Dateien sind gespiegelt, d.h, sie befinden sich auf Servern, die schneller zu erreichen sind als die Originalserver. Am leichtesten findet man derartige Möglichkeiten mit FTPSearch. <sect>Die Software zu AX.25/NetROM/ROSE installieren <p> Um die AX.25-Unterstützung erfolgreich nutzen zu können, muß man erst einen passenden Kernel und anschließend (unter dem neuen Kernel) die AX.25- Utilities installieren. <sect1>Den Kernel kompilieren <label id="DE-AX25-HOWTO-kernel-compilieren"> <p> Wer sich mit dem Erstellen eines neuen Kernels auskennt, kann diesen Abschnitt überspringen. Wichtig ist die Auswahl der richtigen Optionen beim Kompilieren. Wer noch nicht weiß, wie es geht, sollte hier weiterlesen. Normalerweise befindet sich der Quelltext des Kernels in dem Verzeichnis <tt>/usr/src/linux.</tt> Will man nun einen neuen Kernel installieren, geht man so vor: <tscreen><verb> cd /usr/src </verb></tscreen> Falls man bereits ein Linux-Verzeichnis besitzt und dieses nicht löschen will, kann man es umbenennen: <tscreen><verb> mv linux linux.old </verb></tscreen> Da die ausgepackten Quelltexte etwa 20-30 MB auf der Platte belegen, sollte man sich überlegen, ob man das Verzeichnis nicht doch löscht: <tscreen><verb> rm -r linux </verb></tscreen> Die Quelltextarchive sind relativ zu <tt>/usr/src</tt> gepackt; zum Entpacken gibt man ein: <tscreen><verb> cd /usr/src tar zxvf /tmp/linux-2.0.37.tar.gz </verb></tscreen> Bei diesem Beispiel haben wir angenommen, daß das Archiv sich in <tt>/tmp</tt> befindet. Nachdem die Kernel-Quelltexte erfolgreich entpackt wurden, ruft man jetzt das Konfigurationsskript auf: <tscreen><verb> cd /usr/src/linux make menuconfig </verb></tscreen> Unter X11 kann statt dessen auch <tscreen><verb> make xconfig </verb></tscreen> verwendet werden. Hierfür wird ein installiertes Tcl/Tk in einer aktuellen Version benötigt. Etwas archaisch, aber bewährt und stabil: <tscreen><verb> make config </verb></tscreen> Im folgenden soll die Vorgehensweise bei <tt>make menuconfig</tt> beschrieben werden. Selbstverständlich lassen sich die beiden anderen Möglichkeiten auch nutzen, die Einstellungen sind entsprechend anzupassen. In jedem Fall werden viele Fragen gestellt, die man mit »y« (yes), »n« (no) oder »m« (Modul) beantworten kann. Einige Eigenschaften lassen sich nämlich auch als Module einrichten, um sie nur bei Bedarf nachzuladen und somit Speicher zu sparen. Der Einfachheit halber wird hier auf diese Möglichkeit nicht explizit eingegangen. Wer Module erstellen will, muß selbst die entsprechenden Veränderungen vornehmen. Weitere Informationen findet man im <em><htmlurl name="Module HOWTO" url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/unmaintained/Module-HOWTO"></em>, das zur Zeit leider nicht mehr betreut wird. Folgende Optionen sind für AX.25 wichtig: <tscreen><verb> Code maturity level options [*] Prompt for development and/or incomplete code/drivers Loadable Module Support [*] Enable loadable module support (wer Module vorsehen will) ... [?] Kernel daemon support (e.g. autoload of modules) General Setup [*] Networking support Networking options [*] TCP/IP networking [?] IP forwarding/gatewaying ... [?] IP tunneling ... [?] IP allow large windows (not recommended if < 16 MB of memory) ... [*] Amateur Radio AX.25 Level 2 [?] Amateur Radio Net/ROM [?] Amateur Radio X.25 PLP (ROSE) </verb></tscreen> Für Kernel 2.2.x zusätzlich: <tscreen><verb> [*] Packet socket (CONFIG_PACKET) Network Device Support [*] Network Device Support ... [*] Radio network interfaces [?] BAYCOM ser12 and par96 driver for AX.25 [?] Soundcard modem driver for AX.25 [?] Soundmodem support for Soundblaster and compatible cards [?] Soundmodem support for WSS and Crystal cards [?] Soundmodem support for 1200 baud AFSK modulation [?] Soundmodem support for 2400 baud AFSK modulation (7.3728 MHz crystal) [?] Soundmodem support for 2400 baud AFSK modulation (8 MHz crystal) [?] Soundmodem support for 2666 baud AFSK modulation [?] Soundmodem support for 4800 baud HAPN-1 modulation [?] Soundmodem support for 4800 baud PSK modulation [?] Soundmodem support for 9600 baud FSK G3RUH modulation [?] Serial port KISS driver for AX.25 [?] BPQ Ethernet driver for AX.25 [?] Gracilis PacketTwin support for AX.25 [?] Ottawa PI and PI/2 support for AX.25 [?] Z8530 SCC KISS emulation driver for AX.25 ... </verb></tscreen> Optionen, die mit einem <tt>[*]</tt> markiert sind, müssen eingeschaltet (mit »y« beantwortet) werden, die mit einem <tt>[?]</tt> markierten hängen von der zu verwendenden Hardware ab und welche weiteren Optionen einbezogen werden sollen. Einiges davon wird später noch genauer beschrieben, so daß es sinnvoll ist, bei Unklarheiten erst mal weiterzulesen und anschließend wieder zu diesem Abschnitt zurückzukehren. Nachdem die Konfiguration vervollständigt wurde, sollte es möglich sein, den Kernel problemlos zu kompilieren. Siehe dazu auch die Anmerkung zu KISS im Abschnitt <ref id="DE-AX25-HOWTO-kiss" name="KISS">. Wichtig ist es, in jedem Fall vor dem Kompilieren die Datei <tt>/usr/src/linux/Documentation/CHANGES</tt> zu lesen und sicherzustellen, daß die dort erwähnten Programmpakete mindestens in der angegebenen Version installiert sind. Kompiliert wird mit: <tscreen><verb> make dep make clean make zImage </verb></tscreen> Der make-Befehl akzeptiert die einzelnen Optionen auf einer Zeile, so daß man auch <tscreen><verb> make dep clean zImage </verb></tscreen> eingeben kann. Wurde der Kernel erfolgreich kompiliert, kann man ihn dorthin bringen, wo er hin muß: <tscreen><verb> cat /usr/src/linux/arch/i386/boot/zImage > /vmlinuz </verb></tscreen> Wer Lilo installiert hat, muß diesen starten: <tscreen><verb> lilo </verb></tscreen> Auf diese Weise erkennt Lilo, daß ein neuer Kernel installiert wurde und bootet diesen beim nächsten Neustart. Ein <tscreen><verb> make zlilo </verb></tscreen> automatisiert die Schritte <tt>zImage</tt>, Kernelkopie und LILO-Installation. Da hierbei gleichzeitig die Datei <tt>System.map</tt> aktualisiert wird, ist dieser Befehl von Vorteil. Wer sich aber nicht sicher ist, ob der neue Kernel auch wirklich startet, sollte dann aber eine Bootdiskette bereithalten. Weitere Informationen zu diesem Thema gibt das <em><htmlurl name="Kernel HOWTO" url="DE-Kernel-HOWTO.html"></em>. Wer seinen Kernel mit einem Patch auf die aktuelle Version bringen will, sollte nach dem Patchen mittels <tscreen><verb> cd usr/src/linux zcat /pfad/zum/patch-x.x.x.gz | patch -p1 </verb></tscreen> das Quelltextverzeichnis mit einem <tscreen><verb> find /usr/src/linux -name *.orig | xargs rm </verb></tscreen> aufräumen. Ein <tscreen><verb> find /usr/src/linux -name *.rej -print </verb></tscreen> sollte ohne Ausgaben bleiben, sonst ist mit dem Patchen etwas schiefgelaufen. <sect2>Ein Wort zu den Kernel-Modulen <p> Einsteigern wird zwar nicht empfohlen, die Treiber als Module zu kompilieren, es ist jedoch in der Testphase manchmal recht hilfreich. Das korrekte Funktionieren der Module hängt von passenden Einträgen in der Datei <tt>System.map</tt> ab. Bekommt man beim Laden von Modulen Fehlermeldungen bezüglich »unresolved symbols«, so gibt es dafür zwei Ursachen. Das Problem kann sowohl durch eine nicht zum laufenden Kernel passende <tt>System.map</tt> als auch durch ein nicht aktualisiertes Modul-Verzeichnis hervogerufen werden. Im ersteren Fall hilft das Kopieren der passenden <tt>System.map</tt> nach <tt>/</tt>. In letzterem Fall sollte man das Verzeichnis <tt>/lib/modules/{aktuelle Kernel-Version}</tt> leeren und die Module noch einmal neu erstellen und installieren: <tscreen><verb> cd /usr/src/linux make modules modules_install </verb></tscreen> Dieser Schritt ist selbstverständlich ebenfalls nach der Erstellung eines neuen Kernels fällig. Anschließend aktualisiert man die Abhängigkeiten der einzelnen Module untereinander mit: <tscreen><verb> depmod -a </verb></tscreen> Weiterhin ist es notwendig, einige Einträge in der Datei <tt>/etc/conf.modules</tt> hinzuzufügen, damit die Module im Bedarfsfall durch den <tt>kerneld</tt> automatisch geladen werden können. Der <tt>kerneld</tt> muß dafür gestartet sein, ein <tscreen><verb> ps fax | grep kerneld </verb></tscreen> sollte das auch anzeigen. Hier also ein Beispiel: <tscreen><verb> #/etc/conf.modules # # Konfigurationsdatei für den kerneld # # WICHTIG: Alle genannten Treiber müssen als gleichnamige # Module in /lib/modules/{Kernelversion} vorliegen! # alias net-pf3 ax25 # # Suche nach einem Treiber unterdrücken: # (Wichtig bei einigen Programmen der Debian-Distribution) # alias net-pf5 off # alias net-pf6 netrom alias net-pf-11 rose alias tty-ldisc-1 slip alias tty-ldisc-3 ppp alias tty-ldisc-5 mkiss # # Für jedes Device muß einzeln ein Alias-Eintrag erfolgen: # alias bc0 baycom alias bc1 baycom alias nr0 netrom alias pi0a pi2 alias pt0a pt # # Für die nächste Zeile den jeweils passenden # Treiber auswählen: alias scc0 optoscc # alias sm0 soundmodem alias tun10 newtunnel # # Wichtig für Anwernder der SuSE-Distribution, Version 6, # mit Kernel 2.2.x: # alias char-major-4 serial alias char-major-5 serial alias char-major-6 lp alias net-pf-17 af_packet # # ACHTUNG: Die folgenden Einträge werden nur für Kernel # ab 2.2.0 benötigt! alias bcsf0 baycom_ser_fdx alias bcsh0 baycom_ser_hdx alias bcp0 baycom_par alias bce0 baycom_epp # # Wer den neuen 6pack-Treiber nutzen will, braucht: alias tty-ldisc-7 6pack alias sp0 6pack </verb></tscreen> Insbesondere diejenigen, die BayCom- oder SoundModems verwenden wollen, sollten die entsprechenden Treiber als Module vorsehen. Dazu folgen später noch weitere Erklärungen. <sect2>Was ist neu in den verschiedenen Kernel-Versionen? <p> In den Kerneln der Versionen ab 2.0.35 und 2.1.xx sind verbesserte Versionen von fast allen Protokollen und Treibern enthalten. Die wichtigsten Verbesserungen sind: <descrip> <tag>modularisiert</tag> Alle Protokolle und Treiber liegen auch als Module vor, so daß man sie mit <tt/insmod/ laden und mit <tt/rmmod/ entfernen kann, wenn man es wünscht. Damit reduzieren sich die Speicheranforderungen des Kernels für selten genutzte Module, Entwicklung und Fehlersuche werden um einiges einfacher. Doch, wie bereits gesagt, die Konfiguration wird etwas schwieriger. <tag>Alle Treiber sind jetzt Netzwerktreiber</tag> Alle Devices wie PacketTwin, SCC und BayCom usw. bieten jetzt ein normales Netzwerkinterface an; sie erscheinen den Programmen wie der Ethernet-Treiber, nicht mehr wie KISS-TNCs. Wer will, kann mit dem neuen Utility net2kiss ein KISS-Interface auf diese Devices aufsetzen. <tag>Fehler beseitigt</tag> Viele Fehler wurden beseitigt, neue Eigenschaften wurden hinzugefügt. Eine wichtige Erweiterung ist das ROSE-Protokoll. </descrip> <sect1>Die Tools zur Netzwerkkonfiguration <p> Nachdem der Kernel kompiliert wurde (und auch startet), sollten die neuen Netzwerk-Tools kompiliert werden. Sie erlauben Veränderungen an der Konfiguration der Netzwerk-Devices und das Hinzufügen von Routen zur Routing-Tabelle. Informationen zur derzeit aktuellen Version (<tt>net-tools-1.52.tar.gz</tt>) finden sich hier: <tscreen> <htmlurl url="http://www.tazenda.demon.co.uk/phil/net-tools/" name="http://www.tazenda.demon.co.uk/phil/net-tools/"> </tscreen> Die Net-Tools werden von Phil Blundell (<tt>pb@nexus.co.uk</tt>) betreut, Bernd Eckenfels (<tt>Bernd.Eckenfels@inka.de</tt>) ist der "Co-Maintainer". Seine Net-Tools-Page findet man dieser Adresse: <tscreen> <htmlurl url="http://sites.inka.de/sites/lina/linux/NetTools/" name="http://sites.inka.de/sites/lina/linux/NetTools/"> </tscreen> <sect2>Die Standardfassung der Net-Tools erstellen <p> Nicht vergessen: nach dem Entpacken die Datei <tt/Release/ lesen und den dort stehenden Anweisungen folgen. Mit folgenden Schritten installiert man die Net-Tools: <tscreen><verb> cd /usr/src tar zxvf /tmp/net-tools-1.52.tar.gz cd net-tools-1.52 make config </verb></tscreen> An dieser Stelle werden, ähnlich wie bei der Kernel-Konfiguration, einige Fragen gestellt. Man muß nun sicherstellen, alle Protokolle und Typen von Netzwerk-Devices einzubinden, die genutzt werden sollen. Fragen, auf die man keine Antwort weiß, sollte man mit »y« beantworten. Wichtig: Die Protokolle müssen vorher auch bei der Kernel-Konfiguration eingeschaltet worden sein. Hat man zum Beispiel »AppleTalk« beim Kernel deaktiviert, so darf man die entsprechende Frage bei den Net-Tools nicht mit »y« beantworten. Beachtet man dies nicht, so können die Tools nicht kompiliert werden. Nach beendeter Kompilierung werden die Programme mit <tscreen><verb> make install </verb></tscreen> an passender Stelle installiert. <sect2>Ipfwadm und ipchains <p> Wer die IP-Firewall-Möglichkeiten nutzen will, benötigt das aktuelle Tool <tt/ipfwadm/ zur Administration der Firewalls. Das ältere Programm <tt/ipfw/ arbeitet mit den neueren Kernels nicht zusammen und wird daher durch <tt/ipfwadm/ ersetzt. Folgende Optionen beim Kernel-Kompilieren müssen gesetzt sein: <tscreen><verb> Networking options [*] Firewalling [*] IP Firewalling </verb></tscreen> Mit folgenden Befehlen wird <tt/ipfwadm/ kompiliert: <tscreen><verb> cd /usr/src tar zxvf /tmp/ipfwadm-2.3.0.tar.gz cd ipfwadm-2.3.0 make install cp ipfwadm.8 /usr/man/man8 cp ipfw.4 /usr/man/man4 </verb></tscreen> Nutzer eines Kernels der 2.2.x-Reihe benötigen an Stelle des <tt/ipfwadm/ das Programm <tt/ipchains/. Wenn die Datei <tt>/proc/net/ip_fwchains</tt> existiert, dann ist der Kernel mit <tt/ipchains/ funktionsfähig. Andernfalls muß er neu übersetzt werden; siehe dazu auch das im <tt/ipchains/-Archiv enthaltene HOWTO. Das Kompilieren ist auch hier recht einfach: <tscreen><verb> cd /usr/src tar zxvf /tmp/ipchains-1.3.9.tar.gz cd ipchains-1.3.9 make install </verb></tscreen> Wer diese Pakete bereits in seiner Distribution vorfindet, braucht sie natürlich nicht nochmals zu installieren. <sect1>Die Anwender- und Utilityprogramme zu AX.25 <p> Nachdem der neue Kernel erfolgreich kompiliert und mit diesem neu gestartet wurde, müssen jetzt die Anwenderprogramme kompiliert werden. Das geht mit folgenden Befehlen: <tscreen><verb> cd /usr/src tar zxvf /tmp/ax25-utils-2.1.42a.tar.gz cd ax25-utils-2.1.42a make config make make install </verb></tscreen> Debian-Nutzer müssen vorher die Verzeichnisse <tt>/usr/include/asm</tt> und <tt>/usr/include/linux</tt> umbenennen und an ihrer Stelle Links auf den Kernel-Quelltext legen: <tscreen><verb> cd /usr/include mv linux linux.debian mv asm asm.debian ln -s /usr/src/linux/include/linux linux ln -s /usr/src/linux/include/asm asm </verb></tscreen> Man sollte in diesem Zusammenhang kontrollieren, daß <tt>/usr/src/linux/include/asm</tt> ein Link auf <tt>asm-i386</tt> ist. Die Dateien werden im Verzeichnis <tt>/usr</tt> in die Unterverzeichnisse <tt/bin/, <tt/sbin/ und <tt/man/ installiert. Werden die AX.25-Utilities zum allerersten Mal installiert, d.h., sie befanden sich noch nie vorher auf dem System, so verwendet man auch den Befehl <tscreen><verb> make installconf </verb></tscreen> der einige Beispiel-Konfigurationsdateien unter <tt>/etc/ax25</tt> installiert, die als Grundlage für die eigene Konfiguration dienen können. Erscheinen Bildschirmmeldungen wie <tscreen><verb> gcc-Wall -Wstrict-prototypes -o2 -I../lib -c call.c call.c: In funktion `statline': call.c:268: warning: implicit declaration of function `attron' call.c:268: `A_REVERSE' undeclared (first use this function) call.c:268: (Each undeclared identifier is reported only once call.c:268: for each function it appears in) </verb></tscreen> sollte man doppelt überprüfen, ob das ncurses-Paket installiert ist. Das Konfigurationsskript versucht, ncurses an den üblichen Stellen zu finden, doch auf manchen Systemen ist ncurses nicht richtig installiert und es kann dann das Paket nicht finden. Wer Programme kompilieren will, die die AX.25-Bibliotheken nutzen, und dabei Fehlermeldungen erhält, kann die Bibliotheken mit <tscreen><verb> make installib </verb></tscreen> korrekt installieren. <sect2>Hinweis für die Benutzer libc6-basierter Systeme (S.u.S.E. 6.0, RedHat 5.2, Debian 2.0...) <p> Die im vorigen Abschnitt besprochenen AX-25-Utils lassen sich auf Systemen, die die libc6 bzw. glibc 2.x verwenden, nicht mehr kompilieren. Unter folgenden Adressen <itemize> <item><tt><htmlurl url="ftp://ftp.suse.com/pub/projects/ham/" name="ftp.suse.com:/pub/projects/ham/"></tt> <item><tt><htmlurl url="ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/packages/libc6/rpm" name="ftp.funet.fi:/pub/ham/unix/Linux/packet/ax25/packages/libc6/rpm"></tt> </itemize> findet man die Pakete <itemize> <item><tt>ax25util-2.1.42a-0.i386.rpm</tt> (<tt>ftp.suse.com</tt>) <item><tt>ax25util-2.1.42a-3.i386.rpm</tt> (<tt>ftp.funet.fi</tt>) <item><tt>ax25util-devel-2.1.42a-0.i386.rpm</tt> (<tt>ftp.suse.com</tt>) <item><tt>ax25util-devel-2.1.42a-3.i386.rpm</tt> (<tt>ftp.funet.fi</tt>) </itemize> die zur Verwendung auf den erwähnten Systemen gedacht sind. Auf <tscreen><htmlurl url="ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/packages/libc6/deb/" name="ftp.funet.fi:/pub/ham/unix/Linux/packet/ax25/packages/libc6/deb/"> </tscreen> findet sich das Paket <tt>ax25-utils_2.1.42a-6.deb</tt> für die Nutzer der Debian-Distribution. Da die Pakete bereits vorkompilierte Versionen der AX-25-Utilities enthalten, ist ein Selbstkompilieren nicht mehr unbedingt notwendig. Wichtig ist jedoch, auf die korrekte Installation der Header-Dateien zu achten (<tt>ax25util-devel-2.1.42a-0.i386.rpm</tt>), da sich sonst einige AX.25-Anwendungen, wie PR-Terminalprogramme, nicht kompilieren lassen. Dem Debian-Paket fehlt das Programm <tt/smdiag/. Deshalb sollte es nur eingesetzt werden, wenn kein BayCom- oder SoundModem verwendet werden soll. Wer dieses Programm benötigt, sollte das RPM-Archiv der AX.25-Utilities ebenso wie das Development-Archiv mit dem Tool <tt/alien/ nach <tt/*.deb/ konvertieren und mit <tt/dpkg/ installieren. Eine weitere Möglichkeit stellt das auf der Homepage von Patrick Ouellette (<tt>pouellet@eng.utoledo.edu</tt>) verfügbare Archiv <tt>ax25-utils-2.1.42.kb8pym.tar.gz</tt> dar, das Ergebnis von Patricks Modifikationen ist, die er in dem Patch <tt>ax25-utils-2.1.42.kb8pym.diff</tt> zusammengefaßt hat. Dieser Patch sollte mit dem Standardarchiv <tt>ax25-utils-2.1.42a.tar.gz</tt> funktionieren. Patrick weist jedoch ausdrücklich darauf hin, daß es sich hierbei um Testversionen handelt. Da zunächst nur Wert auf Kompilierbarkeit gelegt wurde, sind manche Programme evtl. nicht funktionsfähig. <sect2>Die aktuellen AX.25-Utilities 0.0.1 <p> Die neue Version der AX.25-Utilities wird erstellt, indem die drei Archive <itemize> <item><tt>ax25-apps-0.0.2.tar.gz</tt> <item><tt>ax25-tools-0.0.3.tar.gz</tt> <item><tt>libax25-0.0.5.tar.gz</tt> </itemize> in das Verzeichnis <tt>/usr/src</tt> entpackt und von dort aus installiert werden: <tscreen><verb> cd /usr/src tar -zxvf archivname cd {archivname ohne die Endung .tar.gz} ./configure make install </verb></tscreen> <sect>Ein Hinweis zu Rufzeichen, Adressen und all diesen Dingen <p> Jeder AX.25- oder NetROM-Port muß ein eigenes Rufzeichen/SSID besitzen. Diese werden in den weiter unten beschriebenen Konfigurationsdateien eingestellt. Bei manchen AX.25-Implementationen wie NOS und BPQ kann man jedem AX.25- und NetROM-Port das gleiche Rufzeichen zuteilen. Aus etwas komplizierten technischen Gründen ist das unter Linux nicht möglich. In der Praxis ist das nicht so ein großes Problem, wie es zunächst scheint. Das bedeutet, daß es einige Dinge gibt, die bei der Konfiguration beachtet werden müssen: <enum> <item>Jeder AX.25- und NetROM-Port muß sein eigenes Rufzeichen/SSID bekommen. <item>TCP/IP nutzt das Rufzeichen des Ports, über den es ausgesendet oder empfangen wird, d.h., das in Punkt 1. angegebene Rufzeichen. <item>NetROM nutzt das in seiner speziellen Konfigurationsdatei eingestellte Rufzeichen, dieses wird allerdings nur dann verwendet, wenn eine Verbindung zu einer anderen NetROM-Station besteht, es ist <em/nicht/ das Rufzeichen, welches AX.25-Nutzer verwenden müssen, wenn sie den Node rufen wollen. Mehr dazu später. <item>ROSE nutzt standardmäßig das Rufzeichen des AX.25-Ports, es sei denn, es wurde mit dem <tt/rsparms/-Befehl ein anderes Rufzeichen eingestellt. Wurde mit <tt/rsparms/ ein Rufzeichen vergeben, dann verwendet ROSE dieses auf allen (ROSE-)Ports. <item>Andere Programme, wie der <tt/ax25d/, können zum Mithören jedes Rufzeichen verwenden, das sie wollen, und diese können auch für verschiedene Ports genutzt werden. <item>Wenn man das Routing sorgfältig einstellt, kann man allen Ports dieselbe IP-Adresse zuordnen. </enum> <sect1>Was bedeuten T1, T2, N2,...? <p> Nicht jede AX.25-Implementation ist ein TNC2. Linux verwendet eine Nomenklatur, die etwas anders ist als die von einem TNC gewohnte. In der folgenden Tabelle sind die einstellbaren Parameter und ihre Bedeutung aufgelistet, so daß man hier immer wieder nachschlagen kann, wenn sie im Text erwähnt werden. <tscreen><verb> +--------------+--------------+----------+----------------------------------+ | Linux | TAPR TNC | TNC2 | Beschreibung | +--------------+--------------+----------+----------------------------------+ | T1 | FRACK | F | (Frame Acknowledgement Timer) | | | | | Gibt an, wie lange gewartet wird,| | | | | bevor ein unbestätigtes Paket | | | | | noch mal ausgesendet wird | +--------------+--------------+----------+----------------------------------+ | T2 | RESPTIME | @T2 | Minimale Zeit, die auf ein | | | | | weiteres Paket gewartet wird, | | | | | bevor Empfangsbestätigung | | | | | gesendet wird | +--------------+--------------+----------+----------------------------------+ | T3 | CHECK | @T3 | Zeit, die gewartet wird, bevor | | | | | der Link überprüft wird (Polling)| +--------------+--------------+----------+----------------------------------+ | N2 | RETRY | N | Zahl der Wiederholungen der | | | | | Aussendung eines Paketes, bevor | | | | | die Verbindung als zusammen- | | | | | gebrochen angesehen wird | +--------------+--------------+----------+----------------------------------+ | Idle | | | Zeit, die eine Verbindung | | | | | unbenutzt sein darf, bis sie | | | | | beendet wird (Link Timeout) | +--------------+--------------+----------+----------------------------------+ | Window | MAXFRAME | O | Maximale Anzahl unbestätigter | | | | | Pakete | +--------------+--------------+----------+----------------------------------+ </verb></tscreen> <sect1>Zur Laufzeit konfigurierbare Parameter <p> In den 2.1.xx-Kernels, den 2.0.xx-Kernels mit Module-xx-Patch und Kernels ab 2.0.35 lassen sich viele Parameter auch zur Laufzeit einstellen. Schaut man sich die Dateien unter <tt>/proc/sys/net</tt> an, so wird man viele Dateien mit selbsterklärenden Namen finden, die verschiedene Parameter der Netzwerkkonfiguration beschreiben. Jedes der Verzeichnisse unter <tt>/proc/sys/net/ax25</tt> repräsentiert einen AX.25-Port, wobei dessen Name vom Portnamen abhängt. Die folgenden Dateien sind unter <tt>/proc/sys/net/ax25/<portname>/</tt> zu finden: <tscreen><verb> Dateiname Bedeutung Wert Voreinstellung ----------------------------------------------------------------------------- ip_default_mode voreingestellter IP- 0=DG 1=VC 0 Modus ax25_default_mode voreingestellter AX.25- 0=Normal, 0 Modus 1=Erweitert backoff_type Backoff 0=Linear, 1 1=Exponentiell connect_mode Verbindungsstatus 0=nein, 1 1=ja standard_window_size Standard-Maxframe 1 <= O <= 7 2 extended_window_size Erweitertes Maxframe 1 <= O <= 63 32 t1_timeout T1-Timer 1s <=T1<= 30s 10 s t2_timeout T2-Timer 1s <=T2<= 20s 3 s t3_timeout T3-Timer 0s <=T3<= 3600s 300 s idle_timeout Link-Timeout 0min <=idle 20 min maximum_retry_count Anzahl Retries (N) 1 <= N <= 31 10 maximum_packet_length AX.25-Paketlänge 1 <=Länge<= 512 256 ----------------------------------------------------------------------------- </verb></tscreen> In dieser Tabelle sind die Werte für T1, T2 und T3 in Sekunden, für den idle-Timer (Link-Timeout) in Minuten angegeben, es muß aber beachtet werden, daß die Werte in dem sysctl-Interface in internen Einheiten gezählt werden. Diese entsprechen der Zeit in Sekunden * 10, so daß eine Schrittweite von 1/10 Sekunde möglich wird. Bei Zeitgebern, die einen Wert von 0 erlauben (z.B. T3 und idle), bedeutet 0, daß sie ausgeschaltet sind. In <tt>/proc/sys/net/netrom</tt> finden sich folgende Dateien: <tscreen><verb> Dateiname Wert Voreinstellung ----------------------------------------------------------------------------- default_path_quality 10 link_fails_count 2 network_ttl_initialiser 16 obsolescence_cont_initialiser 6 routing_control 1 transport_acknowledge_delay 50 transport_busy_delay 1800 transport_maximum_tries 3 transport_requested_window_size 4 transport_timeout 1200 ----------------------------------------------------------------------------- </verb></tscreen> In <tt>/proc/sys/net/rose</tt> sieht die Struktur so aus: <tscreen><verb> Dateiname Wert Voreinstellung ----------------------------------------------------------------------------- acknowledge_hold_back_timeout 50 call_request_timeout 2000 clear_request_timeout 1800 link_fail_timeout 1200 maximum_virtual_circuits 50 reset_request_timeout 1800 restart_request_timeout 1800 routing_control 1 window_size 3 ----------------------------------------------------------------------------- </verb></tscreen> Um einen Parameter einzustellen, muß man den gewünschten Wert in die entsprechende Datei schreiben, um zum Beispiel die Maxframe-Anzahl für ROSE zu prüfen und einzustellen, geht man so vor: <tscreen><verb> cat /proc/sys/net/rose/window_size Bildschirmausgabe: 3 echo 4 > /proc/sys/net/rose/window_size cat /proc/sys/net/rose/window_size Bildschirmausgabe: 4 </verb></tscreen> <sect>Einen AX.25-Port einrichten <p> Jede der AX.25-Anwendungen liest die Parametereinstellungen für die verschiedenen AX.25-Ports aus einer speziellen Konfigurationsdatei. Für reine AX.25-Ports ist dies die Datei <tt>/etc/ax25/axports</tt>. Sie muß für jeden auf dem System verwendeten AX.25-Port einen Eintrag erhalten. <sect1>Das AX.25-Netzwerk-Device erstellen <p> Das Netzwerk-Device ist das, was aufgelistet wird, wenn man <tt/ifconfig/ startet. Es sind die Objekte, an die der Linux-Kernel Netzwerkdaten sendet und von denen er sie empfängt. Fast immer ist das Netzwerk-Device mit einem physikalischen Port verbunden, in manchen Situationen ist dies aber nicht notwendig. Das Netzwerk-Device steht in direkter Beziehung zu einem Gerätetreiber. Der Linux-AX.25-Code enthält einige Gerätetreiber. Der gebräuchlichste ist sicher der KISS-Treiber, weiterhin gibt es noch SCC-Treiber, den BayCom- Treiber und den SoundModem-Treiber. Jeder dieser Treiber erzeugt ein Netzwerk-Device, wenn er gestartet wird. Wichtiger Hinweis für Nutzer eines 2.2.x-Kernels: Wird ein Kernel der 2.2.x-Reihe verwendet, so ist jedem AX.25-Netzwerk-Device eine IP-Adresse zuzuordnen, auch wenn damit kein TCP/IP gefahren werden soll. Im einfachsten Fall geschieht das mit <tt>ifconfig {Devicename} {IP-Adresse}</tt>: <tscreen><verb> ifconfig bcsf_0 44.136.8.5 netmask 255.255.255.0 up </verb></tscreen> <sect2>KISS <label id="DE-AX25-HOWTO-kiss"> <p> Optionen bei der Kernel-Kompilierung: <tscreen><verb> General Setup [*] Networking support Network Device Support [*] Network Device Support ... [*] Radio network interfaces ... [*] Serial port KISS driver for AX.25 </verb></tscreen> Die häufigste Konfiguration ist sicher ein KISS-TNC an der seriellen Schnittstelle. Dieser muß vorkonfiguriert und an die Schnittstelle angeschlossen sein. Der TNC kann mit einem Programm wie Minicom oder Seyon in den KISS-Modus gebracht werden. Um ein KISS-Device zu erzeugen, wird das Programm <tt/kissattach/ verwendet: (Annahmen: TNC hängt an <tt>/dev/ttyS0</tt> (COM1) und der vorgesehene Port in <tt>/etc/ax25/axports</tt> heißt radio) <tscreen><verb> /usr/sbin/kissattach /dev/ttyS0 radio kissparms -p radio -t 100 -s 100 -r 25 </verb></tscreen> Damit wird ein KISS-Netzwerk-Device erzeugt. Diese Devices erhalten die Namen <tt/ax0/ - <tt/ax9/. Beim ersten Aufruf erzeugt <tt/kissattach/ <tt/ax0/, beim zweiten <tt/ax1/ usw.. Jedes Kiss-Device hat eine zugehörige serielle Schnittstelle. Mit <tt/kissparms/ lassen sich verschiedene Parameter des Kiss-Device einstellen. Das oben dargestellte Beispiel erzeugt ein Kiss-Device, welches die erste serielle Schnittstelle und den Eintrag »radio« in der Datei <tt>/etc/ax25/axports</tt> nutzt. Anschließend wird es auf ein TXDelay und eine Slottime von 100 Millisekunden und einen Persistence-Wert von 25 eingestellt. Weitere Informationen geben die Hilfeseiten der einzelnen Programme. Erscheint die Fehlermeldung <tscreen><verb> kissattach: TIOCSETD: Invalid argument </verb></tscreen> so sollte man nochmals prüfen, ob der Serial port KISS driver auch wirklich in den Kernel einkompiliert oder als Modul geladen wurde. Der Treiber kann fest einkompiliert werden (<tt>CONFIG_MKISS=y</tt> in <tt>/usr/src/linux/config</tt>) wenn die AX-25-Unterstützung (siehe Abschnitt <ref id="DE-AX25-HOWTO-kernel-compilieren" name="Den Kernel kompilieren">) ebenfalls fest einkompiliert wurde. Andernfalls muß er als Modul kompiliert werden, oder die Erstellung des neuen Kernels würde fehlschlagen. Einrichtung von Dual-Port-TNCs Das <tt/mkiss/-Utility, das bei den AX.25-Utilities dabei ist, erlaubt die Nutzung beider Modems an einem Dual-Port-TNC. Die Konfiguration ist recht einfach. Der Multiport-TNC wird an eine serielle Schnittstelle des Rechners angeschlossen. Die anschließende Konfiguration läßt ihn dann als mehrere einzelne seriell angeschlossene TNCs erscheinen. Das Ganze muß <em/vor/ der AX.25-Konfiguration durchgeführt werden. Die Geräte, die dann einzurichten sind, sind Pseudo-TTY-Interfaces, (<tt>/dev/ttyq*</tt>) und nicht die eigentliche serielle Schnittstelle. Mit Pseudo-TTY wird eine Art Röhre (Pipe) erzeugt, durch die Programme, die mit TTY-Geräten Daten austauschen, mit anderen Programmen, die ebenfalls für Datenaustausch mit TTY-Geräten entwickelt wurden, kommunizieren können. Jede dieser Röhren hat ein »Master«- und ein »Slave«-Ende. Die »Master«-Enden heißen <tt>/dev/ptyq*</tt>, die »Slave«-Enden <tt>/dev/ttyq*</tt>. Jeder Master hat einen Slave, <tt>/dev/ptyq0</tt> ist also der Master einer Pipe, deren Slave <tt>/dev/ttyq0</tt> ist. Man muß das »Master«-Ende einer Pipe vor dem »Slave«-Ende öffnen. <tt/mkiss/ nutzt diesen Mechanismus, um ein einzelnes serielles Device auf mehrere virtuelle Devices aufzuteilen. Hat man z.B. einen Dual-Port-TNC an eine serielle Schnittstelle <tt>/dev/ttyS0</tt> mit 9600 bps angeschlossen, erzeugen die Befehle <tscreen><verb> /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1 /usr/sbin/kissattach /dev/ttyq0 port1 /usr/sbin/kissattach /dev/ttyq1 port2 </verb></tscreen> zwei Pseudo-TTY-Devices, die beide wie ein normaler Single-Port-TNC erscheinen. Nun lassen sich <tt>/dev/ttyq0</tt> und <tt>/dev/ttyq1</tt> wie serielle Schnittstellen mit daran angeschlossenen konventionellen KISS-TNCs behandeln. Das heißt, man verwendet <tt/kissattach/ wie oben beschrieben, für die AX.25-Ports port1 und port2. Auf die serielle Schnittstelle selbst kann kein <tt/kissattach/ angewendet werden, da <tt/mkiss/ diese ja bereits nutzt. Der Befehl <tt/mkiss/ kennt einige Optionen: <descrip> <tag/-c/ schaltet die Erzeugung einer Prüfsumme für jedes KISS-Paket ein. Die meisten KISS-Implementationen, außer dem G8BPG KISS-ROM, unterstützen dies jedoch nicht. <tag/-s/ <Baudrate> stellt die Baudrate der seriellen Schnittstelle ein. <tag/-h/ schaltet den Hardware-Handshake ein (Voreinstellung: Aus). Wird von den meisten KISS-Implementationen nicht unterstützt. <tag/-l/ schaltet eine Mitschrift (logging) in die syslog-Logdatei ein. </descrip> <sect2>BayCom <p> Folgende Optionen zur Kernel-Kompilierung sind wichtig: <tscreen><verb> Code maturity level options [*] Prompt for development and/or incomplete code/drivers General Setup [*] Networking support ... Network Device Support [*] Radio network interfaces [*] BAYCOM ser12 and par96 driver for AX.25 </verb></tscreen> Für erste Tests sollte der Treiber mit »m« als Modul kompiliert werden. Thomas Sailer (<tt/sailer@ife.ee.ethz.ch/) entwickelte trotz des weitverbreiteten Glaubens, es würde nicht sonderlich gut funktionieren, eine BayCom-Unterstützung für Linux. Sein Treiber unterstützt die seriellen Ser12, die parallelen Par96 und die verbesserten PicPar-Modems. Informationen über diese Modems erhält man auf der WWW-Seite des BayCom-Teams unter folgender URL: <tscreen> <htmlurl url="http://www.baycom.de" name="http://www.baycom.de"> </tscreen> Der erste Schritt ist, herauszufinden, welche I/O-Adresse und IRQ die Schnittstelle verwendet, an die das BayCom-Modem angeschlossen ist. Der BayCom-Treiber muß mit diesen Werten konfiguriert werden. Ist dies geschehen, erzeugt der Treiber Netzwerk-Devices mit den Namen <tt/bc0/, <tt/bc1/, <tt/bc2/ usw.. In den Kerneln der 2.2.x-Reihe wurden die Bezeichnungen für das Baycom-Modul und die von ihm erzeugten Devices geändert. Es gibt hier für Half- und Fullduplex getrennte Treiber: <tscreen><verb> Modul-Name Funktion Device ------------------------------------------------------------------------------ baycom_ser_fdx serielles BayCom-Modem, Fullduplex und bcsf0..bcsf3 Halfduplex, umschaltbar, wählbare Baudrate baycom_ser_hdx serielles BayCom-Modem, nur Halfduplex, bcsh0..bcsh3 nur 1200 Baud baycom_par paralleles PicPar- und Par96-Modem, bcp0..bcp3 baycom_epp EPP-Modem bce0..bce3 (Treiber noch in Entwicklung!) </verb></tscreen> Anstelle von <tscreen><verb> insmod baycom </verb></tscreen> schreibt man also <tscreen><verb> insmod baycom_ser_fdx </verb></tscreen> und konfiguriert <tt/bcsf0/ statt <tt/bc0/. Das sieht dann z.B. so aus: <tscreen><verb> insmod baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4 sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4 </verb></tscreen> Ausführlichere Informationen zu den neuen Treibern können in der Datei <tt>/usr/src/linux/Documentation/networking/baycom.txt</tt> nachgelesen werden. Die Parameter der verwendeten Schnittstelle können mit dem Utility <tt/sethdlc/ eingestellt werden, hat man nur ein BayCom-Modem installiert, so kann man die Parameter auf der Kommandozeile für insmod angeben, wenn der als Modul eingerichtete Treiber geladen wird. Als Beispiel eine einfache Konfiguration. Zunächst wird der normale serielle Treiber für die erste Schnittstelle (COM1) abgeschaltet, dann der BayCom-Treiber für ein serielles 1200-Baud-Modem an COM1 eingerichtet und die Software-DCD eingeschaltet: <tscreen><verb> setserial /dev/ttyS0 uart none insmod hdlcdrv insmod baycom mode="ser12*" iobase=0x3f8 irq=4 </verb></tscreen> <bf/Wichtig:/ Einige Schnittstellenbausteine bereiten Probleme im Zusammenhang mit dem BayCom-Treiber. Dieser wird zwar geladen, kann aber nicht auf die Schnittstelle zugreifen. Dies betrifft insbesondere viele der neueren 16550A-UARTs, wie sie auf Pentium-Motherboards oft eingebaut sind. Benutzer eines Kernel 2.2.x können in einem solchen Fall an Stelle von <tt/baycom_ser_fdx/ <tt/baycom_ser_hdx/ probieren, da dieser Treiber in anderer Weise auf die Hardware zugreift. Wer nun keine zusätzliche Schnittstellenkarte mit 8250 oder 16450 UART vorsehen will, der sollte vor die erste <tt/setserial/-Zeile des Beispiels einfügen: <tscreen><verb> setserial /dev/ttyS0 uart 16550A skip_test </verb></tscreen> Weiterhin stört der Linux-Treiber für die parallele Schnittstelle die korrekte Funktion des BayCom-Treibers. Man sollte daher auf den »parallel printer support« im Kernel verzichten oder diesen als Modul kompilieren, damit er bei Notwendigkeit via <tt/rmmod/ entfernt werden kann: <tscreen><verb> rmmod lp </verb></tscreen> Das komplette Skript sieht dann etwa so aus: <tscreen><verb> #!/bin/sh rmmod lp setserial /dev/ttyS0 uart 16550A skip_test sleep 3 setserial /dev/ttyS0 uart none insmod hdlcdrv insmod baycom mode="ser12*" iobase=0x3f8 irq=4 </verb></tscreen> Damit sollte der Treiber funktionieren, was man mit <tt/sethdlc -d/ einfach nachprüfen kann. Der Wert hinter <tt/dbg2/ sollte etwa 2000-3000 sein und sich ständig ändern. Die Probleme mit dem Schnittstellenbaustein sind ausschließlich auf Schwierigkeiten des Linux-BayCom-Treibers bei der Hardwareinitialisierung zurückzuführen und deshalb von der eingesetzten Modemschaltung weitestgehend unabhängig. Für den Test mit <tt/sethdlc/ braucht das Modem nicht angeschlossen zu sein. Ein Par96-Modem am Parallelport LPT1 mit Hardware-DCD richtet man so ein: <tscreen><verb> insmod hdlcdrv insmod baycom mode="par96" iobase=0x378 irq=7 options=0 </verb></tscreen> Dies ist aber nicht unbedingt der beste Weg. <tt/sethdlc/ arbeitet genau so gut mit einem Modem wie mit mehreren. In der Hilfeseite (<tt/man sethdlc/) findet man alle Details, einige Beispiele sollen diesen Aspekt hier verdeutlichen. Es wird angenommen, das BayCom-Modul ist mit <tscreen><verb> insmod hdlcdrv insmod baycom </verb></tscreen> bereits geladen oder als Treiber in den Kernel einkompiliert. Man kann das Netzwerk-Device bc0 nun einrichten: <itemize> <item>als Parallelport-Modem an LPT1 mit Software-DCD: <tscreen><verb> sethdlc -p -i bc0 mode par96 io 0x378 irq 7 </verb></tscreen> <item>als serielles Modem an COM1: <tscreen><verb> sethdlc -p -i bc0 mode "ser12*" io 0x3f8 irq 4 </verb></tscreen> </itemize> <sect3>AX.25-Kanalzugriffsparameter <p> Die AX.25-Kanalzugriffsparameter entsprechen den Parametern ppersist, txdelay und slottime. Wiederum wird dazu <tt/sethdlc/ verwendet. Genaueres steht wiederum in der Hilfeseite, aber ein weiteres Beispiel kann nicht schaden. Wir setzen also das oben begonnene Skript fort, indem wir den BayCom-Treiber mit TXDelay 200 ms, SlotTime 100 ms PPersist 40 und Half-Duplex einrichten: <tscreen><verb> sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half </verb></tscreen> Alle Zeitwerte werden in Millisekunden angegeben. Die AX.25-Unterstützung des Kernels für die Nutzung des BayCom-Device einrichten Der BayCom-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration fast dasselbe wie bei einer PI- oder PacketTwin-Karte. Zunächst gibt man dem BayCom-Device ein Rufzeichen: <tscreen><verb> /sbin/ifconfig bc0 hw ax25 VK2KTJ up </verb></tscreen> Einige Versionen von <tt/ifconfig/ unterstützen den eben angegebenen Weg nicht. Man kann dann so vorgehen: <tscreen><verb> /sbin/ifconfig bc0 up axparms -setcall bc0 VK2KTJ up </verb></tscreen> Als nächstes wird in der Datei <tt>/etc/ax25/axports</tt> ein Eintrag für BayCom hinzugefügt. Die Verbindung des Eintrags zum entsprechenden Netzwerk-Device geschieht über das eingestellte Rufzeichen. Verwendet ein Programm den Eintrag mit dem für BayCom vergebenen Rufzeichen, so wird das BayCom-Device angesprochen. Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt sich für TCP/IP einrichten, man kann es dem <tt/ax25d/ hinzufügen und NetROM oder ROSE darüber laufen lassen. <sect2>SoundModem <p> Folgende Optionen bei der Kernel-Kompilierung sind wichtig: <tscreen><verb> Code maturity level options [*] Prompt for development and/or incomplete code/drivers General Setup [*] Networking support Network Device Support [*] Radio network interfaces ... [*] Soundcard modem driver for AX.25 [?] Soundmodem support for Soundblaster and compatible cards [?] Soundmodem support for WSS and Crystal cards [?] Soundmodem support for 1200 baud AFSK modulation [?] Soundmodem support for 2400 baud AFSK modulation (7.3728 MHz crystal) [?] Soundmodem support for 2400 baud AFSK modulation (8 MHz crystal) [?] Soundmodem support for 2666 baud AFSK modulation [?] Soundmodem support for 4800 baud HAPN-1 modulation [?] Soundmodem support for 4800 baud PSK modulation [?] Soundmodem support for 9600 baud FSK G3RUH modulation </verb></tscreen> Thomas Sailer (<tt/sailer@ife.ee.ethz.ch/) entwickelte einen neuen Treiber für den Kernel, mit dem man die Soundkarte als Modem nutzen kann. Schließt das Funkgerät an die Soundkarte an, um damit Packet zu spielen! Thomas empfiehlt mindestens einen 486DX2/66, wenn man diese Software verwenden will, da die gesamte digitale Signalverarbeitung von der CPU übernommen wird. Der Treiber kann im Moment 1200 bps AFSK, 2400 bps AFSK, 4800 bps HAPN, 4800 bps PSK und 9600bps FSK (G3RUH-kompatibel) emulieren. Zur Zeit werden nur SoundBlaster- und Windows Sound System-kompatible Karten unterstützt. Da die Soundblaster-Emulation inzwischen selbst bei Billig-Karten recht gut geworden ist, lohnt sich ein Test in jedem Fall. Soundkarten, die vom Linux-Sound-Treiber nicht unterstützt werden, sollten unter DOS initialisiert werden. Dazu startet man ein Minimal-DOS, in dessen Konfigurationsdateien lediglich die Soundkartentreiber aufgerufen werden, und lädt anschließend Linux via LOADLIN. PCI-Soundkarten (z.B. SoundBlaster PCI64) werden derzeit noch <em/nicht/ unterstützt. Die Soundkarten benötigen eine kleine Zusatzschaltung zur Ansteuerung der PTT, Informationen dazu findet man auf Thomas Soundmodem-PTT-Seite: <tscreen><verb> <htmlurl url="http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html" name="http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html"> </verb></tscreen> Es gibt einige Möglichkeiten für die PTT-Schaltung: die Soundausgabe von der Karte auswerten oder die Ausgabe von der seriellen, parallelen oder MIDI- Schnittstelle zu nutzen. Die Webseite bietet für jede Option Beispielschaltungen. Wer die »2400 baud« Betriebsarten nutzen will, beachte eine kleine Besonderheit: Ursprünglich kam man auf 2400 baud, indem man den herkömmlichen 1200 baud-Modems auf der Basis des TCM3105 (siehe dazu auch <tt><htmlurl url="http://www.ardos.de/gerd/tcm3105.html" name="http://www.ardos.de/gerd/tcm3105.html"></tt>) einen Quarz mit höherer Frequenz verpaßte. Zwei Quarzfrequenzen sind üblich: 7.3728 und 8.0 MHz. Bevor man sich für eine davon entscheidet, sollte man in Erfahrung bringen, womit die Gegenstationen arbeiten, da die Wahl der falschen Frequenz die Verbindung stark beeinträchtigen bzw. unmöglich machen kann. Der SoundModem-Treiber erzeugt Netzwerk-Devices mit Namen <tt/sm0/, <tt/sm1/, <tt/sm2/ usw., wenn er eingerichtet wurde. Der SoundModem-Treiber beansprucht die gleichen Ressourcen wie Linux-Sound- und Parallelport-Treiber. Wenn man also den SoundModem-Treiber verwenden möchte, dürfen sowohl der Linux-Sound-Treiber als auch der Treiber für die parallele Schnittstelle nicht geladen sein. Natürlich lassen sich all diese als Module kompilieren, so daß sie mit <tt/insmod/ und <tt/rmmod/ nach Belieben geladen und entfernt werden können. Einige OMs laden zuerst den Linux-Sound-Treiber, um die Soundkarte zu initialisieren, enfernen diesen dann wieder und laden dann den SoundModem- Treiber: <tscreen><verb> (rmmod lp) insmod sound (evtl. Optionen) rmmod sound insmod hdlcdrv insmod soundmodem (evtl. Optionen, dazu später) </verb></tscreen> <sect3>Die Soundkarte einrichten <p> Der SoundModem-Treiber initialisiert die Soundkarte nicht. In den AX.25-Utilities ist zu diesem Zweck das Programm <tt/setcrystal/ enthalten, welches für Soundkarten mit dem Crystal-Chipset verwendet werden kann. Wer eine andere Karte hat, muß andere Software zum Initialisieren verwenden. Die Syntax von <tt/setcrystal/: <tscreen><verb> setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2] </verb></tscreen> Will man eine SoundBlaster auf I/O-Adresse 0x388, IRQ 10 und DMA 1 einrichten, so verwendet man: <tscreen><verb> setcrystal -s 0x388 -i 10 -d 1 </verb></tscreen> Ein Windows-Sound System konfiguriert man so auf IO-Adresse 0x534, IRQ 5, DMA 3: <tscreen><verb> setcrystal -w 0x534 -i 5 -d 3 </verb></tscreen> Mit »-f synthio« kann man die Adresse des Synthesizers einstellen, mit »-c dma2« richtet man den zweiten DMA-Kanal für Vollduplexbetrieb ein. <sect3>Den SoundModem-Treiber konfigurieren <p> Nachdem die Soundkarte eingerichtet ist, muß man dem SoundModem-Treiber mitteilen, wo sich die Soundkarte befindet und welche Art von Modem emuliert werden soll. Diese Einstellungen können mit <tt/sethdlc/ vorgenommen werden, ebenso können die erforderlichen Parameter dem SoundModem-Modul auf der <tt/insmod/-Kommandozeile mitgegeben werden. Als Beispiel eine einfache Konfiguration für eine SoundBlaster, die ein 1200 bps-Modem emuliert: <tscreen><verb> insmod hdlcdrv insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1 </verb></tscreen> Aber es geht auch genau so gut mit <tt/sethdlc/, das sowohl mit einer Karte als auch mit mehreren funktioniert: Zunächst muß auch hier das Modul geladen <tscreen><verb> insmod hdlcdrv insmod soundmodem </verb></tscreen> oder die SoundModem-Unterstützung in den Kernel einkompiliert sein. Wir richten damit beispielsweise das schon oben konfigurierte Windows Sound System ein, daß es ein 9600-bps-FSK-Modem nach G3RUH als Device <tt/sm0/ emuliert und einen Parallelport an 0x378 zur Ansteuerung der PTT nutzt: <tscreen><verb> sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 \ irq 5 dma 3 pario 0x378 </verb></tscreen> Die in Punkt 6.1.3.1. erwähnte SoundBlaster einrichten, daß sie als Device <tt/sm1/ ein 4800 bps-HAPN-Modem emuliert und eine serielle Schnittstelle an 0x2f8 zur PTT-Ansteuerung nutzt: <tscreen><verb> sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8 </verb></tscreen> ...als 1200-bps-AFSK-Modem mit PTT über serielle Schnittstelle an 0x2f8: <tscreen><verb> sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8 </verb></tscreen> Die Konfiguration der Kanalzugriffsparameter erfolgt analog dem bei BayCom Gesagten. Das Device <tt/sm0/ soll ein TXDelay von 100ms, eine Slottime von 50ms, eine Ppersist (Persistence) von 128 und full-Duplex-Betrieb fahren: <tscreen><verb> sethdlc -i sm0 -a txd 100 slot 50 ppersist 120 full </verb></tscreen> Alle Werte sind auch hier in Millisekunden anzugeben. <sect3>Die Audiopegel einstellen und den Treiber feinabstimmen <p> Es ist für die Funktion jedes Funkmodems sehr wichtig, daß die Audiopegel korrekt eingestellt sind. Dies gilt ebenso für das SoundModem. Thomas Sailer hat einige Utilities entwickelt, die diese Aufgabe erleichtern. Es sind die Programme <tt/smdiag/ und <tt/smmixer/. <tt/smdiag/ bietet zwei Anzeigearten, einmal als Oszilloskop, zum zweiten als Augenmuster an. Mit <tt/smmixer/ kann man die Sende- und Empfangspegel abgleichen. Um <tt/smdiag/ im »Augen-Modus« für das SoundModem-Device <tt/sm0/ zu starten: <tscreen><verb> smdiag -i sm0 -e </verb></tscreen> <tt/smmixer/ wird für <tt/sm0/ so gestartet: <tscreen><verb> smmixer -i sm0 </verb></tscreen> Beide Programme zeigen die aktuellen Einstellungen für die Pegel an den Aus- und Eingängen der Karte an. Um diese zu verändern, gibt es zwei Wege: <enum> <item>(bei von Linux unterstützten Karten): Man besorge sich ein Mixerprogramm - es finden sich einige auf <tscreen><htmlurl name="sunsite.unc.edu:/pub/Linux/apps/sound/mixers" url="ftp://sunsite.unc.edu/pub/Linux/apps/sound/mixers"> </tscreen> - und stelle damit die Werte ein. Günstig sind kommandozeilenorientierte Programme wie <tt/cmix/, da sie in das Startskript eingebunden werden können und so immer die gleichen Einstellungen gegeben sind. <item>bei nicht von Linux unterstützten Soundkarten, die über DOS-Treiber initialisiert werden müssen, sollte man das der Karte meist beiliegende Mixer-Utility für DOS nutzen. Dies trifft auf einen Großteil der Onboard-Soundkarten zu. Siehe dazu auch das <em><htmlurl name="Sound HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/Sound-HOWTO.html"></em>. </enum> <sect3>Die AX.25-Unterstützung des Kernels für die Nutzung des SoundModem-Device einrichten <p> Der SoundModem-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der eines BayCom-Modems, einer PI- oder PacketTwin-Karte vergleichbar. Zunächst gibt man dem SoundModem-Device ein Rufzeichen: <tscreen><verb> /sbin/ifconfig sm0 hw ax25 VK2KTJ up </verb></tscreen> Einige Versionen von <tt/ifconfig/ unterstützen den eben angegebenen Weg nicht. Dann kann man so vorgehen: <tscreen><verb> /sbin/ifconfig sm0 up axparms -setcall sm0 VK2KTJ up </verb></tscreen> Als nächstes wird in der Datei <tt>/etc/ax25/axports</tt> ein Eintrag für SoundModem hinzugefügt. Die Verbindung des Eintrags zum entsprechenden Netzwerk-Device geschieht über das eingestellte Rufzeichen. Verwendet ein Programm den Eintrag mit dem für SoundModem vergebenen Rufzeichen, so wird das SoundModem-Device angesprochen. Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt sich für TCP/IP einrichten, man kann es dem <tt/ax25d/ hinzufügen und NetROM oder ROSE darüber laufen lassen. Erscheinen Fehlermeldungen beim Aufruf von <tt/ifconfig/ wie diese <tscreen><verb> no such device permission denied </verb></tscreen> sollte man die Konfigurationsoptionen (I/O-Adresse, IRQ, DMA) nochmals überprüfen. <sect2>PI-Karte <p> Folgende Optionen sind bei der Kernel-Kompilierung wichtig: <tscreen><verb> General Setup [*] Networking support Network Device Support ... [*] Radio network interfaces ... [*] Ottawa PI and PI/2 support for AX.25 </verb></tscreen> Der Treiber erzeugt Netzwerk-Devices mit den Namen <tt/pi0/, <tt/pi1/, <tt/pi2/ usw., wobei die erste PI-Karte als <tt/pi0/ angesprochen wird, die zweite als <tt/pi1/ etc.. Wurde der Treiber in den Kernel kompiliert und hat er die Karte korrekt erkannt, läßt er sich einrichten: <tscreen><verb> /sbin/ifconfig pi0a hw ax25 VK2KTJ up </verb></tscreen> Damit wird die erste PI-Karte mit dem Rufzeichen VK2KTJ konfiguriert und aktiviert. Nun muß noch der entsprechende Eintrag in <tt>/etc/ax25/axports</tt> erfolgen, und es kann losgehen. Der PI-Karten-Treiber wurde von David Perry (<tt>dp@hydra.carleton.edu</tt>) geschrieben. <sect2>PacketTwin <p> Folgende Optionen beim Kernelkompilieren: <tscreen><verb> General Setup [*] Networking support Network Device Support ... [*] Radio network interfaces ... [*] Gracilis PacketTwin support for AX.25 </verb></tscreen> Der Treiber erzeugt Netzwerk-Devices mit den Namen <tt/pt0/, <tt/pt1/, <tt/pt2/ usw., wobei die erste PacketTwin-Karte als <tt/pt0/ angesprochen wird, die zweite als <tt/pt1/ etc.. Wurde der Treiber in den Kernel kompiliert und hat er die Karte korrekt erkannt, läßt er sich einrichten: <tscreen><verb> /sbin/ifconfig pt0a hw ax25 VK2KTJ up </verb></tscreen> Damit wird die erste PacketTwin-Karte mit dem Rufzeichen VK2KTJ konfiguriert und aktiviert. Nun muß noch der entsprechende Eintrag in <tt>/etc/ax25/axports erfolgen</tt>, und es kann losgehen. Der PacketTwin-Treiber wurde von Craig Small (<tt>csmall@triode.apana.org.au</tt>) geschrieben. <sect2>SCC, allgemein <p> Wichtige Kernel-Kompilier-Optionen: <tscreen><verb> General Setup [*] Networking support Network Device Support ... [*] Radio network interfaces ... [*] Z8530 SCC KISS emulation driver for AX.25 </verb></tscreen> Joerg Reuter, DL1BKE (<tt>jreuter@lykos.tng.oche.de</tt>) entwickelte die allgemeine Unterstützung für SCC-Karten. Sein Treiber ist für eine Vielzahl Karten konfigurierbar und stellt wie die anderen Netzwerk-Device zur Verfügung, so daß man die SCC-Karte wie eine Netzwerkkarte ansprechen kann. <sect3>Die Konfigurations-Tools finden und installieren <p> Während der Kernel-Treiber in den Standard-Quelltexten enthalten ist, gibt es bei Joerg neuere Versionen seines Treibers und die dazu notwendigen Konfigurationsprogramme. Diese findet man hier: <itemize> <item><tt><htmlurl url="ftp://ftp.tu-dresden.de/pub/soft/hamradio/packet/tcpip/linux/" name="ftp.tu-dresden.de:/pub/soft/hamradio/packet/tcpip/linux/"></tt> <item><tt><htmlurl url="ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linux" name="ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linux"></tt> </itemize> Es gibt verschiedene Versionen, man muß sich die für seinen Kernel passende heraussuchen. <descrip> <tag>Kernel 2.0.x:</tag> <tt>z8530drv-2.4a.dl1bke.tar.gz</tt> <tag>Kernel 2.1.6 oder neuer:</tag> <tt>z8530drv-utils-3.0.tar.gz</tt> </descrip> Mit folgenden Befehlen läßt sich das Paket installieren: <tscreen><verb> cd /usr/src gzip -dc /tmp/z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz - cd z8530drv make clean make dep make module (wenn der Treiber als Modul erstellt werden soll) make for_kernel (wenn der Treiber in den Kernel einkompiliert werden soll) make install </verb></tscreen> Nach dem erfolgreichen Kompilieren sollten sich drei neue Programme im Verzeichnis <tt>/sbin</tt> finden: <tt/gencfg/, <tt/sccinit/ und <tt/sccstat/. Diese Programme dienen zur Einrichtung des Treibers für die SCC-Karte. Der Treiber erzeugt Netzwerkdevices mit den Namenn <tt/scc0/ - <tt/scc7/. Hat man vorhin <tt/make for_kernel/ eingegeben, so muß der Kernel neu kompiliert werden. Die Option <tscreen><verb> [*] Z8530 SCC KISS emulation driver for AX.25 </verb></tscreen> beim »Network Device Support« muß angegeben sein. Hat man sich entschieden, den Treiber als Modul zu kompilieren (<tt/make module/), so wurde ein Modul namens <tt/scc.o/ in das entsprechende Verzeichnis <tt>/lib/modules/{kernelversion}/net</tt> kopiert, welches mit <tt/insmod/ geladen werden kann. <sect3>Den Treiber für die verwendete Karte einrichten <p> Der Z8530-SCC-Treiber ist so flexibel entwickelt worden, daß er möglichst viele verschiedene SCC-Karten unterstützt. Der Preis dafür ist eine etwas kompliziertere Konfiguration. In dem Treiber-Archiv findet sich eine ausführliche Dokumentation, wer Probleme hat, sollte diese lesen. Insbesondere <tt>doc/scc_eng.doc</tt> bzw. <tt>doc/scc_ger.doc</tt> bieten detailliertere Informationen, die nicht in diesem HOWTO enthalten sind. Das Programm <tt/sccinit/ liest die Datei <tt>/etc/z8530drv.conf</tt> als Haupt-Konfigurationsdatei aus. Sie ist in zwei große Abschnitte gegliedert, Hardware-Parameter und Kanal-Konfiguration. Nachdem diese Datei entsprechend editiert wurde, muß nur der Aufruf <tt/sccinit/ in das Skript, welches die Netzwerkkonfiguration während des Systemstarts vornimmt, eingetragen werden. Der Treiber läßt sich erst nach einem Aufruf von sccinit nutzen. <sect4>Konfiguration der Hardware-Parameter <p> Der erste Abschnitt ist in Absätze unterteilt, von denen jeder einen Z8530-Chip repräsentiert. Jeder Absatz besteht aus einer Liste mit Schlüsselwörtern und den zugeordneten Werten. Standardmäßig lassen sich bis zu 4 SCC-Chips angeben. Wer mehr braucht, muß in der Datei <tt/scc.c/ die Zeile <tscreen><verb> #define MAXSCC 4 </verb></tscreen> entsprechend anpassen. Erlaubte Schlüsselworte und Argumente: <descrip> <tag/chip/ Wird verwendet, um die einzelnen Abschnitte voneinander zu trennen. Beliebige Argumente sind erlaubt, sie werden nicht verwendet. <tag/data_a/ Wird zur Angabe der Adresse des Datenports für den SCC-Kanal »A« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x300. <tag/ctrl_a/ Wird zur Angabe der Adresse des Steuerports für den SCC-Kanal »A« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x304. <tag/data_b/ Wird zur Angabe der Adresse des Datenports für den SCC-Kanal »B« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x301. <tag/ctrl_b/ Wird zur Angabe der Adresse des Steuerports für den SCC-Kanal »B« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x305. <tag/irq/ Gibt den IRQ an, den der in diesem Abschnitt einzustellende Chip verwendet. Argument ist eine Integerzahl, wie 5. <tag/pclock/ Gibt die am PCLK-Pin des Z8530 anliegende Taktfrequenz an. Als Argument wird ein Integerwert erwartet (Frequenz in Hz), Voreinstellung ist 4915200 Hz, wenn dieses Schlüsselwort nicht angegeben wird. <tag/board/ Der Typ der 8530-SCC-Karte. Folgende Werte sind erlaubt: <descrip> <tag/PA0HZP/ die PA0HZP-SCC-Karte <tag/EAGLE/ die EAGLE-SCC-Karte <tag/PRIMUS/ die PRIMUS-PC (DG9BL-)Karte <tag/BAYCOM/ die BayCom-(U)SCC-Karte </descrip> <tag/escc/ Optional, schaltet die Unterstützung für erweiterte SCC-Chips (ESCC) wie den 8580, 85180 oder 85280 ein. Als Argument steht entweder das Wort yes oder no. Voreinstellung ist no. <tag/vector/ Optional, gibt die Adresse des Vector-Latch (auch als Intack-Port bekannt) für die PA0HZP-Karten an. Es gibt nur ein Vector-Latch für alle Chips. Voreinstellung: 0. <tag/special/ Optional, gibt die Adresse eines speziellen Funktionsregisters für manche Karten an. Voreinstellung: 0. </descrip> Einige Beispielkonfigurationen: <tscreen><verb> BayCom USCC chip 1 data_a 0x300 ctrl_a 0x304 data_b 0x301 ctrl_b 0x305 irq 5 board BAYCOM # # SCC Chip2 # chip 2 data_a 0x302 ctrl_a 0x306 data_b 0x303 ctrl_b 0x307 board BAYCOM PA0HZP SCC-Karte chip 1 data_a 0x153 data_b 0x151 ctrl_a 0x152 ctrl_b 0x150 irq 9 pclock 4915200 board PA0HZP vector 0x168 escc no # # SCC Chip2 # chip 2 data_a 0x157 data_b 0x155 ctrl_a 0x156 ctrl_b 0x154 irq 9 pclock 4915200 board PA0HZP vector 0x168 escc no DRSI-SCC-Karte chip 1 data_a 0x303 data_b 0x301 ctrl_a 0x302 ctrl_b 0x300 irq 7 pclock 4915200 board DRSI escc no </verb></tscreen> Bei wem die Karte bereits unter NOS funktioniert, der kann die Treiber-Befehle des PE1CHL-NOS-Treibers mit dem Befehl <tt/gencfg/ in eine für die Konfigurationsdatei des Z8530-Treibers nutzbare Form bringen. <tt/gencfg/ wird genau so wie für den PE1CHL-Treiber von NOS aufgerufen: Zum Beispiel erstellt <tscreen><verb> gencfg 2 0x150 4 2 0 1 0x168 9 4915200 </verb></tscreen> eine Grundkonfiguration für die OptoSCC-Karte. <sect3>Kanal-Konfiguration <p> Im Abschnitt Kanal-Konfiguration werden alle anderen für den jeweiligen Port relevanten Parameter eingestellt. Auch dieser Abschnitt ist in einzelne Absätze unterteilt. Jeder dieser Absätze steht für einen logischen Port, da jede SCC-Karte zwei Ports bereitstellt, gibt es für jeden Hardware-Absatz zwei solcher Absätze. Die dazu notwendigen Schlüsselworte und Werte müssen in der Datei <tt>/etc/z8530drv.conf</tt> immer <em/nach/ dem Abschnitt mit den Hardware-Parametern stehen. Die Reihenfolge in diesem Abschnitt ist sehr wichtig, mit der hier vorgeschlagenen Reihenfolge sollte es funktionieren. Folgende Schlüsselwörter und Werte gibt es hier: <descrip> <tag/device/ Muß in der ersten Zeile einer Port-Definition stehen und gibt den Namen der speziellen Gerätedatei an, auf die sich die weitere Konfiguration bezieht, z.B. <tt/scc0/. <tag/speed/ Gibt die Übertragungsrate in Bits pro Sekunde an, muß ganzzahlig sein, z.B. 1200. <tag/clock/ Gibt an, aus welcher Quelle der Datentakt stammt. </descrip> Erlaubte Werte sind: <descrip> <tag/dpll/ normaler Halbduplexbetrieb <tag/external/ Das Modem hat einen eigenen Sende-/Empfangstakt <tag/divider/ verwendet den Fullduplex-Teiler, wenn installiert <tag/mode/ Gibt die zu verwendende Datenkodierung an. Mögliche Werte sind nrz und nrzi. <tag/rxbuffers/ Gibt die Anzahl der im Speicher zu reservierenden Empfangs- puffer vor. Der Wert ist ganzzahlig, z.B. 8. <tag/txbuffers/ Gibt die Anzahl der im Speicher zu reservierenden Sende- puffer vor. Der Wert ist ganzzahlig, z.B. 8. <tag/bufsize/ Gibt die Größe der Sende-/Empfangspuffer vor. Der Wert wird in Bytes angegeben und stellt die Gesamtlänge eines Paketes dar, es muß also die Länge der AX.25-Header zum Datenfeld hinzugerechnet werden. Dieses Schlüsselwort ist optional, die Voreinstellung 384. <tag/txdelay/ Das von KISS bekannte TXDelay, der Wert ist ganzzahlig und wird in Millisekunden angegeben. <tag/persist/ Der Wert für die Persistence, ganzzahlig. <tag/slot/ KISS-Slottime, ganzzahlig, in Millisekunden. <tag/tail/ Der TXTail-Wert bei KISS, ganzzahlig, in Millisekunden. <tag/fulldup/ Das bei KISS verwendete Fullduplex-Flag, Wert ist entweder 1 für Vollduplex oder 0 für Halbduplex. <tag/wait/ Der Wait-Wert bei KISS, ganzzahlig, in Millisekunden. <tag/min/ Der Min-Wert bei KISS, ganzzahlig, in Sekunden. <tag/maxkey/ Die maximale Sendezeit bei KISS ganzzahlig, in Sekunden. <tag/idle/ Der Idle-Timer-Wert, ganzzahlig, in Sekunden. <tag/maxdef/ Der Maxdef-Wert bei Kiss, ganzzahlig. <tag/group/ Der group-Wert bei KISS, ganzzahlig. <tag/txoff/ Der txoff-Wert bei Kiss, ganzzahlig, in Millisekunden. <tag/softdcd/ Der Wert für SoftDCD (Software-Rauschsperre), ganzzahlig. <tag/slip/ Das Slip-Flag bei KISS, ganzzahlig. </descrip> <sect3>Den Treiber verwenden <p> Man verwendet die <tt/scc*/-Geräte wie andere Netzwerk-Devices auch. Beispiel: <tscreen><verb> /sbin/ifconfig scc0 44.136.8.5 netmask 255.255.255.0 /sbin/ifconfig scc0 up axparms -setcall scc0 VK2KTJ up </verb></tscreen> <sect3>Die Programme sccstat und sccparam <p> Bei der Fehlersuche kann das Programm <tt/sccstat/ helfen, indem man damit die aktuelle Konfiguration eines SCC-Device anzeigen lassen kann. Aufruf zum Beispiel mit: <tscreen><verb> sccstat scc0 </verb></tscreen> Es werden viele Informationen zur Einstellung und Funktion des SCC-Ports <tt/scc0/ angezeigt. Mit dem Programm <tt/sccparam/ kann man nach dem Booten die Konfiguration verändern. Die Syntax ist an den NOS-Befehl param angelehnt, zum Setzen des TXTail-Wertes auf 100 ms würde man eingeben: <tscreen><verb> sccparam scc0 txtail 0x8 </verb></tscreen> <sect2>BPQ-Ethernet <p> Folgende Optionen sind bei der Kernel-Kompilierung wichtig: <tscreen><verb> General Setup [*] Networking support Network Device Support ... [*] Radio network interfaces ... [*] BPQ Ethernet driver for AX.25 </verb></tscreen> Linux bietet Kompatibilität mit BPQ-Ethernet. Damit kann man das AX.25-Protokoll über Ethernet im lokalen Netzwerk verwenden, um mit anderen BPQ-Maschinen im Netzwerk zusammenzuarbeiten. Die BPQ-Devices tragen die Namen <tt/bpq1/ bis <tt/bpq9/. Das Device <tt/bpq0/ gehört zu <tt/eth0/, <tt/bpq1/ zu <tt/eth1/ usw.. Die Konfiguration ist sehr offen. Zunächst muß das Ethernet-Device eingerichtet sein. Das heißt, der Kernel muß mit Ethernet-Unterstützung kompiliert sein und diese muß auch funktionieren. Im <em><htmlurl name="Ethernet HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/Ethernet-HOWTO.html"></em> findet man dazu weiterführende Informationen. Um die BPQ-Unterstützung einzurichten, muß das Ethernet-Device mit einem Rufzeichen versehen werden: <tscreen><verb> /sbin/ifconfig bpq hw ax25 VK2KTJ up </verb></tscreen> Beachte, daß das Rufzeichen mit dem Rufzeichen in der Datei <tt>/etc/ax25/axports</tt> übereinstimmt, das für diesem Port gelten soll. <sect2>BPQ-Node mit Linux-AX.25-Unterstützung verbinden <p> BPQ verwendet normalerweise sogenannte Multicast-Adressen. Die Linux-Implementation macht das nicht, sie verwendet stattdessen die normale Ethernet Broadcast Address. Deshalb sollte die Datei <tt/NET.CFG/ für den BPQ-ODI-Treiber wie folgt geändert werden: <tscreen><verb> LINK SUPPORT MAX STACKS 1 MAX BOARDS 1 LINK DRIVER NE2000 ; oder anderer Bezeichner, passend zur Karte INT 10 ; entsprechend den Einstellungen der PORT 300 ; Netzwerkkarte FRAME ETHERNET_II PROTOCOL BPQ 8FF ETHERNET_II ; für BPQ erforderlich - kann die PID ; verändern BPQPARAMS ; optional, nur gebraucht, wenn ; die voreingestellte Zieladresse ; überschrieben werden soll ETH_ADDR FF:FF:FF:FF:FF:FF ; Zieladresse </verb></tscreen> <sect1>Die Datei /etc/ax25/axports <p> Diese Datei ist eine einfache Textdatei, die mit einem Texteditor erzeugt wird. Sie hat folgendes Format: <tscreen><verb> Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung </verb></tscreen> wobei gilt: <descrip> <tag/Portname/ Bezeichner für den Port <tag/Rufzeichen/ Rufzeichen, welches dem Port zugeordnet werden soll <tag/Baudrate/ Baudrate zum TNC <tag/Paketlänge/ Länge des Datenfeldes eines Paketes in Bytes <tag/Maxframe/ maximale Anzahl unbestätigter Pakete (AX.25-Window) <tag/Beschreibung/ kurzer beschreibender Text </descrip> Beispieldatei von Terry Dawson: <tscreen><verb> radio VK2KTJ-15 4800 256 2 4800 bps auf 144.800 MHz ether VK2KTJ-14 10000000 256 2 BPQ Ethernet-Device </verb></tscreen> Zur Erinnerung: Jeder AX.25-Port muß ein eigenes Rufzeichen/SSID bekommen. Jedes zu verwendende Device muß einen Eintrag in dieser Datei bekommen, dies betrifft KISS, BayCom, SCC, PI, PacketTwin und SoundModem-Ports. Jeder Eintrag beschreibt genau ein AX.25-Netzwerk-Device. Die Einträge in der Datei sind mit den Netzwerk-Devices über das Rufzeichen/SSID verbunden. Das ist nicht zuletzt ein Grund dafür, daß jeder Port ein eigenes Rufzeichen/SSID verlangt. <sect1>Das AX.25-Routing einrichten <p> Es ist sowohl für normale AX.25- als auch für IP-Verbindungen sinnvoll, voreingestellte Digipeaterpfade für spezielle Stationen zu erstellen. Dazu kann man das Programm <tt/axparms/ verwenden: <tscreen><verb> /usr/sbin/axparms -route add radio VK2XLZ VK2SUT </verb></tscreen> Mit diesem Befehl setzt man einen Digipeaterpfad für VK2XLZ via VK2SUT auf den AX.25-Port mit dem Namen radio. Weiterführende Informationen sind in der Hilfeseite zu <tt/axparms/ zu finden. <sect>Ein AX.25-Interface für TCP/IP einrichten <p> Es ist sehr einfach, einen AX.25-Port für TCP/IP einzurichten. Für KISS-Interfaces gibt es zwei Möglichkeiten, eine IP-Adresse einzurichten. Die konventionellere Methode mit dem Befehl <tt/ifconfig/ funktioniert mit allen Interface-Typen. Für einen an <tt>/dev/ttyS0</tt> angeschlossenen KISS-TNC gilt dieses Beispiel: <tscreen><verb> /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0 /sbin/route add default ax0 </verb></tscreen> Damit wird ein AX.25-Interface mit der IP-Adresse 44.136.8.5 und einer MTU (Maximum Transmit Unit, maximale Größe des ausgesendeten Datenpakets) von 512 Bytes erzeugt. Wenn notwendig, können mit dem <tt/ifconfig/-Befehl weitere Parameter eingestellt werden. Die anderen Interfaces können wie die Netzwerkkarte mit <tt/ifconfig/ auf IP-Adresse und Netzmaske eingestellt werden, ebenso wird die Route wie für eine Netzwerkkarte festgesetzt (<tt/man route/). Das folgende Beispiel ist für eine PI-Karte gedacht, funktioniert aber auch mit jedem anderen AX.25-Netzwerk-Device, statt <tt/pi0a/ ist der jeweilige Device-Name einzusetzen: <tscreen><verb> /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512 /sbin/route add -net 14.136.8.0 netmask 255.255.255.0 pi0a /sbin/route add default pi0a </verb></tscreen> Die hier aufgeführten Befehle sind typisch für diese Konfigurationen, vielen werden sie von NOS oder anderer TCP/IP-Software her bekannt sein. Beachten muß man, daß die Default-Route möglicherweise nicht gebraucht wird, wenn schon ein anderes Netzwerk-Device eingerichtet ist. Um das Ganze zu testen, versuche man ein ping oder telnet zum lokalen Host: <tscreen><verb> ping -i 5 44.136.8.58 </verb></tscreen> Beachte die Option -i 5, die Ping veranlaßt, seine Pakete nur aller 5 Sekunden statt wie voreingestellt, aller Sekunden zu senden. <sect>Einen NetROM-Port einrichten <p> NetROM basiert auf den vorher erstellten AX.25-Ports. Es setzt auf dem AX.25-Protokoll auf. Um ein NetROM-Interface auf einem AX.25-Port einzurichten, müssen zwei Dateien angepaßt werden. Die eine Datei beschreibt die NetROM-Interfaces, und die andere, auf welche AX.25-Ports NetROM aufsetzt. Man kann mehrere NetROM-Ports einrichten, für jeden ist die Vorgehensweise die gleiche. <sect1>Die Datei /etc/ax25/nrports <p> Die erste der beiden Dateien heißt <tt>/etc/ax25/nrports</tt>. Sie beschreibt die NetROM-Ports in etwa der gleichen Art wie <tt>/etc/ax25/axports</tt> die AX.25-Ports. Jedes NetROM-Device braucht seinen Eintrag in <tt>/etc/ax25/nrports</tt>. Normalerweise wird es auf einer Linux-Maschine nur ein NetROM-Device geben, das eine definierte Anzahl von AX.25-Ports nutzt. Manchmal will man aber einem besonderen Programm, wie einer Mailbox, ein separates NetROM-Alias vergeben. Dann kann man auch mehrere NetROM-Devices einrichten. Die Datei <tt>/etc/ax25/nrports</tt> hat folgendes Format: <tscreen><verb> Name Rufzeichen Alias Paketlänge Beschreibung </verb></tscreen> <descrip> <tag/Name/ Der Bezeichner für den Port. <tag/Rufzeichen/ Das Rufzeichen, welches für den NetROM-Verkehr verwendet wird. Dies ist <em/nicht/ das Rufzeichen, das andere Stationen als Nodecall verwenden können. Zu dem Node-Programm später. Es sollte nicht noch einmal in <tt>/etc/ax25/axports</tt> oder <tt>/etc/ax25/nrports</tt> auftauchen. <tag/Alias/ Der NetROM-Alias für diesen Port. <tag/Paketlänge/ Die maximale Größe der NetROM-Pakete. <tag/Beschreibung/ Eine kurze Beschreibung für den Port. </descrip> Ein Beispiel sähe so aus: <tscreen><verb> netrom VK2KTJ-9 LINUX 236 Linux Packet Switch </verb></tscreen> Damit wird ein NetROM-Port erzeugt, der im übrigen NetROM-Netz als LINUX:VK2KTJ-9 erscheint. Programme wie <tt/call/ nutzen diese Datei. <sect1>Die Datei /etc/ax25/nrbroadcast <p> Die zweite der Dateien ist <tt>/etc/ax25/nrbroadcast</tt>. In dieser Datei können viele Einträge enthalten sein. Normalerweise gibt es für jeden AX.25-Port, über den NetROM-Verbindungen laufen sollen, einen Eintrag. Die Datei hat folgendes Format: <tscreen><verb> axport min_obs def_qual worst_qual verbose </verb></tscreen> Wobei gilt: <descrip> <tag/axport/ Der aus der Datei <tt>/etc/ax25/axports</tt> entnommene Portname. Steht kein Eintrag in <tt>/etc/ax25/nrbroadcast</tt>, so bedeutet das, daß kein NetROM-Routing durchgeführt wird und alle empfangenen NetROM-Broadcasts auf diesem Port ignoriert werden. <tag/min_obs/ Minimalwert für die Obsolescence. <tag/def_qual/ Voreingestellte Qualität für den Port. <tag/worst_qual/ Wert für die schlechteste Verbindungsqualität, Verbindungen mit schlechteren Werten werden ignoriert. <tag/verbose/ Legt fest, ob NetROM auf diesem Port Routing-Broadcasts aussendet oder nur auf seine Anwesenheit hinweist. </descrip> Ein Beispiel sähe so aus: radio 1 200 100 1 <sect1>Das Netzwerk-Device für NetROM erstellen <p> Sind die beiden Konfigurationsdateien vervollständigt, dann muß das NetROM-Netzwerk-Device genau so wie die anderen AX.25-Devices erstellt werden. Diesmal wird dazu der Befehl <tt>nrattach</tt> verwendet. Dieser arbeitet wie <tt>axattach</tt>, im Unterschied zu diesem erzeugt er NetROM-Netzwerk-Devices mit den Namen <tt>nr0</tt> - <tt>nr9</tt>. Beim ersten Aufruf erzeugt <tt/nrattach/ das Device <tt/nr0/, beim zweiten <tt/nr1/ usw.. Um das Netzwerk-Device für den von uns definierten NetROM-Port zu erzeugen, geben wir ein: <tscreen><verb> nrattach netrom </verb></tscreen> Damit wird das NetROM-Device <tt/nr0/ mit dem Namen <tt/netrom/, dessen Details in der Datei <tt>/etc/ax25/nrports</tt> festgelegt wurden, gestartet. Wer einen Kernel der 2.2.x-Reihe verwendet, muß an dieser Stelle eine IP-Adresse angeben, auch wenn kein TCP/IP verwendet werden soll. Der Aufruf von <tt/nrattach/ sieht dann so aus: <tscreen><verb> nrattach -i 44.131.16.2 netrom </verb></tscreen> <sect1>Den NetROM-Daemon starten <p> Der Linux-Kernel übernimmt alle mit dem NetROM-Protokoll und dem Switching verbundenen Aufgaben bis auf einige Funktionen. Der NetROM-Daemon verwaltet die NetROM-Routing-Tabellen und erzeugt die NetROM-Routing-Broadcasts. Er wird mit folgendem Befehl gestartet: <tscreen><verb> /usr/bin/netromd -i </verb></tscreen> Schon bald darauf sollte man sehen, wie sich die Datei <tt>/proc/net/nr_neigh</tt> mit den Namen der benachbarten NetROM-Stationen füllt: <tscreen><verb> cat /proc/net/nr_neigh </verb></tscreen> Man sollte den <tt/netromd/-Aufruf in die während des Startens ausgeführten (rc-)Skripte einfügen, damit er automatisch beim Booten gestartet wird. <sect1>Das NetROM-Routing einrichten <p> Manchmal ist es wünschenswert, feste (statische) Routen für spezielle Rechner einzurichten. Dazu gibt es den Befehl <tt/nrparms/. Eine vollständige Beschreibung kann in der Hilfeseite nachgelesen werden. Ein kleines Beispiel dazu: <tscreen><verb> /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9 </verb></tscreen> Damit wird eine NetROM-Route zu #MINTO:VK2XLZ-10 über die benachbarte Station VK2SUT-9 auf dem AX.25-Port radio eingerichtet. Man kann damit auch manuell neue Einträge für benachbarte Stationen vornehmen: <tscreen><verb> /usr/sbin/nrparms -routes radio VK2SUT-9 +120 </verb></tscreen> Damit wird VK2SUT-9 als benachbarte NetROM-Station mit einer fest eingestellten Qualität von 120 eingetragen, die nicht automatisch gelöscht bzw. geändert wird. <sect>Ein NetROM-Interface für TCP/IP einrichten <p> Ein TCP/IP-Interface für NetROM wird fast genau so wie für AX.25 eingerichtet. Man kann entweder die IP-Adresse und MTU auf der Kommandozeile für <tt/nrattach/ angeben oder <tt/ifconfig/ und <tt/route/ benutzen. Es müssen jedoch per Hand die arp-Einträge für die Rechner, zu denen geroutet werden soll, ergänzt werden, da die Maschine nicht selbst herausbekommt, welche NetROM-Adresse sie verwenden muß, um einen bestimmten IP-Rechner zu erreichen. Will man also ein Device <tt/nr0/ mit der IP-Adresse 44.136.8.5, einer MTU von 512 und eingerichtet mit den Daten aus <tt>/etc/ax25/nrports</tt> für den NetROM-Port <tt/netrom/ erzeugen, gibt man ein: <tscreen><verb> /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom route add 44.136.8.5 nr0 </verb></tscreen> Oder man benutzt die folgenden Befehle: <tscreen><verb> /usr/sbin/nrattach netrom ifconfig nr0 44.136.8.5 \ netmask 255.255.255.0 hw netrom VK2KTJ-9 route add 44.136.8.5 nr0 </verb></tscreen> Anschließend müssen für jeden IP-Rechner, der über NetROM erreichbar sein soll, die Einträge für Route und ARP gesetzt werden. Um einen IP-Rechner mit der Adresse 44.136.80.4 auf NetROM-Adresse BBS:VK3BBS über die benachbarte Station VK2SUT-0 zu erreichen, gibt man folgendes ein: <tscreen><verb> route add 44.136.80.4 nr0 arp -t netrom \ -s 44.136.80.4 vk2sut-0 nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0 </verb></tscreen> Die Werte »120« und »6« beim <tt/nrparms/-Befehl stehen für die NetROM-Qualität und die Obsolescence dieser Route. <sect>Einen ROSE-Port einrichten <p> Die ROSE-Protokollebene entspricht der Ebene 3 der X.25-Spezifikation. Die im Kernel enthaltene ROSE-Unterstützung ist eine modifizierte Version des ROSE (RATS (Radio Amateur Teleprinter Society) Open System Environment) AX.25 Packet Switch (<tt><htmlurl url="http://www.rats.org/rose/" name="http://www.rats.org/rose/"></tt>). Das ROSE-Protokoll setzt auf den vorher erstellten AX.25-Ports auf. Um ROSE einzurichten, muß man eine Konfigurationsdatei erstellen, die die zu verwendenden ROSE-Ports definiert. Man kann mehrere ROSE-Ports erstellen, für jeden gilt die gleiche Vorgehensweise. <sect1>Die Datei /etc/ax25/rsports <p> Die ROSE-Ports werden in der Datei <tt>/etc/ax25/rsports</tt> eingerichtet. Sie beschreibt die ROSE-Ports ähnlich wie <tt>/etc/ax25/axports</tt> die AX.25-Ports. Die Datei hat folgendes Format: <tscreen><verb> Name Adresse Beschreibung </verb></tscreen> Wobei gilt: <descrip> <tag/Name/ Text-Bezeichner für den jeweiligen Port <tag/Adresse/ 10stellige ROSE-Adresse für den Port <tag/Beschreibung/ kurze, frei wählbare Beschreibung </descrip> Ein Beispiel: <tscreen><verb> rose 5050294760 ROSE-Port </verb></tscreen> Beachte, daß ROSE das für jeden AX.25-Port voreingestellte Rufzeichen verwendet, wenn nichts anderes angegeben wird. Um ein eigenes Rufzeichen/SSID für ROSE festzulegen, gibt man folgendes ein: <tscreen><verb> /usr/sbin/rsparms -call VK2KTJ-10 </verb></tscreen> Damit wartet Linux auf ROSE-Rufe unter dem Rufzeichen/SSID VK2KTJ-10 auf allen eingerichteten AX.25-Ports und verwendet dieses auch für ROSE- Verbindungen. <sect1>Das ROSE-Netzwerk-Device einrichten <p> Wurde die Datei <tt>/etc/ax25/rsports</tt> erstellt, kann man die ROSE-Netzwerk-Devices genau so wie die AX.25-Netzwerk-Devices erstellen. Diesmal wird dazu der Befehl <tt/rsattach/ verwendet. Dieser arbeitet wie <tt/axattach/, im Unterschied zu diesem erzeugt er ROSE-Netzwerk-Devices mit den Namen <tt/rose0/ - <tt/rose5/. Beim ersten Aufruf erzeugt <tt/rsattach/ das Device <tt/rose0/, beim zweiten <tt/rose1/ usw.. Beispiel: <tscreen><verb> rsattach rose </verb></tscreen> Damit wird das ROSE-Device <tt/rose0/ mit dem Namen <tt/rose/, dessen Details in der Datei <tt>/etc/ax25/rsports</tt> festgelegt wurden, gestartet. <sect1>Das Routing für ROSE einrichten <p> Zur Zeit unterstützt das ROSE-Protokoll nur statisches Routing. Mit dem <tt/rsparms/-Befehl kann die Routingtabelle eingerichtet werden: <tscreen><verb> rsparms -nodes add 5050295502 radio vk2xlz </verb></tscreen> Damit würde eine Route zum ROSE-Node 5050295502 über den AX.25-Port mit dem Bezeichner »radio« laut <tt>/etc/ax25/axports</tt> zu einer benachbarten Station mit dem Rufzeichen VK2XLZ hinzugefügt. Es kann auch eine Maske angegeben werden, um mehrere ROSE-Zielrechner in einem Routing-Eintrag zu erfassen: <tscreen><verb> rsparms -nodes add 5050295502/4 radio vk2xlz </verb></tscreen> Damit werden alle Zieladressen erfaßt, die in den ersten 4 Stellen mit der angegebenen übereinstimmen, die also mit »5050« beginnen. Der Befehl kann auch in dieser, sicher eindeutigeren, Form eingegeben werden: <tscreen><verb> rsparms -nodes add 5050/4 radio vk1xlz </verb></tscreen> <sect>AX.25/NetROM/ROSE-Verbindungen <p> Jetzt, da alle AX.25-, NetROM- und ROSE-Devices eingerichtet und aktiviert sind, sollte es möglich sein, Test-Verbindungen zu starten. In den AX.25-Utilities ist das Programm <tt/call/ enthalten, das ein Terminal mit geteiltem Bildschirm für AX.25, NetROM und ROSE darstellt. Ein einfacher AX.25-Verbindungsaufbau sähe so aus: <tscreen><verb> /usr/bin/call radio VK2DAY via VK2SUT </verb></tscreen> Ein einfacher NetROM-Verbindungsaufbau zu einem Node mit dem Alias »SUNBBS« sähe so aus: <tscreen><verb> /usr/bin/call netrom SUNBBS </verb></tscreen> Ein einfacher ROSE-Verbindungsaufbau an HEARD auf dem Node 5050882960 sähe so aus: <tscreen><verb> /usr/bin/call rose HEARD 5050882960 </verb></tscreen> Beachte: Man muß <tt/call/ mitteilen, auf welchem Port gerufen werden soll, da der Zielrechner möglicherweise auf allen eingerichteten Ports erreichbar ist. Das Programm <tt/call/ ist ein zeilenbasiertes Terminalprogramm, mit dem man AX.25-Stationen rufen kann. Zeilen, die mit einem »˜« beginnen, werden als Befehle interpretiert. Mit Eingabe von »˜.« am Beginn einer neuen Zeile beendet man die Verbindung. Weiterführende Informationen findet man in der Hilfeseite zu <tt/call/. <sect>Linux für ankommende Packet-Verbindungen einrichten <p> Linux ist ein mächtiges Betriebssystem und bietet große Flexibilität bei der Konfiguration. Dadurch wird es etwas langwieriger, es so einzurichten, daß es das tut, was man will. Wenn man eine Linux-Maschine für die Entgegennahme von ankommenden AX.25-NetROM- und ROSE-Rufen einrichtet, muß man sich einige Fragen stellen. Die wichtigste davon ist: »Was sollen die Nutzer zu sehen bekommen, wenn sie verbunden sind?« Es werden hübsche kleine Anwendungen entwickelt, die dazu verwendet werden können, den Anrufern bestimmte Dienste anzubieten. Ein einfaches Beispiel ist das in den AX.25-Utilities enthaltene Programm <tt/pms/, etwas komplexer ist das ebenfalls dort vorhandene <tt/node/-Programm. Als Alternative kann man den Nutzern einen Login-Prompt geben, so daß sie einen Shell-Account nutzen können, oder man hat sogar ein eigenes Programm, wie eine Datenbank oder ein Spiel, geschrieben, mit dem sich die Nutzer verbinden können. Was auch immer gewünscht wird, man muß es der AX.25-Software mitteilen, damit diese weiß, welches Programm bei einer hereinkommenden Verbindung gestartet werden soll. Das Programm <tt/ax25d/ entspricht hierfür dem üblicherweise zur Entgegennahme von TCP/IP-Verbindungen auf UNIX-Maschinen eingesetzten <tt/inetd/. Es wartet auf hereinkommende Verbindungen, wenn es eine erkennt, schaut es in einer Konfigurationsdatei nach, welches Programm zu starten und mit dieser Verbindung zu assoziieren ist. Da der <tt/ax25d/ das Standardwerkzeug für die Entgegennahme von AX.25-, NetROM- und ROSE-Verbindungen ist, soll hier die Konfiguration erläutert werden. <sect1>Die Datei /etc/ax25/ax25d.conf <p> Sie ist die Konfigurationsdatei für den AX.25-Daemon <tt/ax25d/, der die hereinkommenden AX.25-, NetROM- und ROSE-Verbindungen entsprechend handhabt. Die Datei sieht auf den ersten Blick etwas kryptisch aus, aber man wird bald sehen, daß sie in der Praxis recht einfach zu bearbeiten ist. Es gibt eine kleine Falle, die beachtet werden muß. Im allgemeinen hat die Datei <tt>/etc/ax25/ax25d.conf</tt> folgendes Format: <tscreen><verb> # Dieser Kommentar wird vom ax25d ignoriert. [port_name] <port_name> {port_name} window T1 T2 T3 idle N2 window T1 T2 T3 idle N2 parameters window T1 T2 T3 idle N2 window T1 T2 T3 idle N2 ... default window T1 T2 T3 idle N2 </verb></tscreen> Wobei gilt: Das Zeichen »#« am Anfang einer Zeile markiert einen Kommentar, die Zeile wird vom <tt/ax25d/ ignoriert. <descrip> <tag/port_name/ Der Name des AX.25-, NetROM- oder ROSE-Ports, wie er in <tt>/etc/ax25/axports</tt>, <tt>/etc/ax25/nrports</tt> respektive <tt>/etc/ax25/rsports</tt> definiert ist. <tag/peer/ Das Rufzeichen der Station, auf die sich die Konfiguration bezieht. Wird hier keine SSID angegeben, so sind alle SSID gültig. <tag/window/ Der AX.25-Window-Parameter (Maxframe) für diese Konfiguration. <tag/T1/ Der Timer T1 (Zeit bis zum Wiederaussenden eines Paketes) in halben Sekunden. <tag/T2/ Der Timer T2 (Zeit, die auf eine weiteres Paket gewartet wird, bevor Empfangsbestätigung gesendet wird) in Sekunden. <tag/T3/ Zeit, die die Verbindung inaktiv sein darf, bevor sie getrennt wird in Sekunden. <tag/idle/ Der Idle-Timer-Wert in Sekunden <tag/N2/ Anzahl Versuche (retries), bevor eine Verbindung als gescheitert betrachtet wird. <tag/mode/ Legt einige allgemeine Zugriffsrechte fest. Die Modes werden ein-/ausgeschaltet, indem eine Reihe von Zeichen angegeben werden, von denen jedes für ein bestimmtes Zugriffsrecht steht. Die Buchstaben dürfen groß- oder klein geschrieben werden und dürfen nicht durch Leerzeichen getrennt werden. Folgende Zeichen sind möglich: <descrip> <tag>u/U</tag> UTMP - zur Zeit nicht unterstützt <tag>v/V</tag> Validiere alles - zur Zeit nicht unterstützt <tag>q/Q</tag> Quiet - schreibe Verbindung nicht mit <tag>n/N</tag> überprüfe NetROM-Nachbar - zur Zeit nicht unterstützt <tag>d/D</tag> Digipeater nicht erlaubt, Verbindungen müssen direkt erfolgen, nicht über Digipeater. <tag>l/L</tag> Aussperren (Lockout) - keine Verbindung erlaubt. <tag>*/0</tag> Marker - Platzhalter, kein Mode gesetzt </descrip> <tag/uid/ Die Nutzerkennung (User ID) unter der das für die Verbindung aufgerufene Programm laufen soll. <tag/cmd/ Der volle Pfadname des aufzurufenden Programms, ohne Kommandozeilenparameter <tag/cmd_name/ Text, der beim Aufrufen von ps (Anzeige des Prozeßstatus) erscheinen soll, normalerweise dasselbe wie cmd, aber ohne die Pfadangabe <tag/arguments/ Kommandozeilenparameter, die der in cmd angegebenen Anwendung beim Start übergeben werden. Folgende Kürzel können dazu verwendet werden: <descrip> <tag/%d/ Name des Ports, auf dem die Verbindung eingegangen ist. <tag/%U/ AX.25-Rufzeichen der verbundenen Station ohne SSID, in Großbuchstaben. <tag/%u/ AX.25-Rufzeichen der verbundenen Station ohne SSID, in Kleinbuchstaben. <tag/%S/ AX.25-Rufzeichen der verbundenen Station mit SSID, in Großbuchstaben. <tag/%s/ AX.25-Rufzeichen der verbundenen Station mit SSID, in Kleinbuchstaben. <tag/%P/ AX.25-Rufzeichen des Nodes, von dem die Verbindung kam ohne SSID, in Großbuchstaben. <tag/%p/ AX.25-Rufzeichen des Nodes, von dem die Verbindung kam ohne SSID, in Kleinbuchstaben. <tag/%R/ AX.25-Rufzeichen des Nodes, von dem die Verbindung kam mit SSID, in Großbuchstaben. <tag/%r/ AX.25-Rufzeichen des Nodes, von dem die Verbindung kam mit SSID, in Kleinbuchstaben. </descrip> </descrip> Für jedes AX.25-, NetROM- oder ROSE-Interface, auf dem Verbindungen entgegengenommen werden sollen, muß ein Abschnitt in diesem Format vorgesehen werden. In jedem Abschnitt gibt es zwei besondere Zeilen, eine beginnt mit dem Wort »parameters«, die andere mit »default«. (Ja, das ist ein Unterschied.) Diese Zeilen dienen speziellen Funktionen. Der Zweck der default-Zeile dürfte klar sein, diese Zeile enthält die Parameter, die auf alle Stationen zutreffen, für die keine speziellen Parameter definiert wurden. Wird keine default-Zeile angegeben, so werden alle Verbindungen, für die keine speziellen Voreinstellungen getroffen wurden, sofort wieder getrennt. Die parameters-Zeile ist ein wenig kritischer, hier ist auch die vorhin erwähnte Falle. In jedem der Felder für alle aufgeführten Stationen kann das »*«-Zeichen benutzt werden, um den voreingestellten Wert zu übernehmen. Die parameters-Zeile setzt diese Voreinstellungen. Die Kernel-Software selbst hat einige Voreinstellungen, die dann verwendet werden, wenn die keine Voreinstellungen unter »parameters« angegeben sind. Die Falle besteht nun darin, daß die Parameters-Werte nur für die darunterliegenden Zeilen gelten, nicht für die darüberstehenden. Man kann mehrere parameters-Zeilen pro Interface-Definition haben und somit Gruppen von Stationen mit gleichen Voreinstellungen einrichten. <sect1>Ein einfaches Beispiel für /etc/ax25/ax25d.conf <p> <tscreen><verb> # ax25d.conf für VK2KTJ - 02/03/97 # Diese Konfiguration nutzt den vorher definierten AX.25-Port. # Win T1 T2 T3 idl N2 [] [VK2KTJ-0 via radio] parameters 1 10 * * * * * VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u + VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u + NOCALL * * * * * * L default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj [VK2KTJ-1 via radio] default * * * * * 0 root /usr/sbin/node node <netrom> parameters 1 10 * * * * * NOCALL * * * * * * L default * * * * * * 0 root /usr/sbin/node node {VK2KTJ-0 via rose} parameters 1 10 * * * * * VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u + VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u + NOCALL * * * * * * L default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj {VK2KTJ-1 via rose} default * * * * * 0 root /usr/sbin/node node radio </verb></tscreen> In diesem Beispiel gelten für jede Station, die eine Verbindung mit dem Rufzeichen VK2KTJ-0 aufbauen will und auf dem AX.25-Port »radio« gehört wurde, die folgenden Einstellungen: Jeder, dessen Rufzeichen auf »NOCALL« eingestellt ist, soll ausgesperrt bleiben, beachte die Verwendung des Mode »L«. Die parameters-Zeile ändert zwei der Kernel-Voreinstellungen (Window und T1) und startet das <tt/axspawn/-Programm für die Nutzer. Alle auf diese Weise gestarteten <tt/axspawn/ erscheinen in der Ausgabe des Befehls <tt/ps/ als »axspawn« zum besseren Verständnis. Die nächsten beiden Zeilen definieren für zwei Stationen, daß für sie diese Einstellungen gelten. Die defaults-Zeile dient als »Sammelbecken« für alle anderen Stationen (auch VK2XLZ und VK2DAY, wenn sie eine andere SSID als -1 verwenden). Hier werden alle Parameter implizit gesetzt und das Programm pms mit einer Kommandozeile aufgerufen, die anzeigt, daß es von einer AX.25-Verbindung aufgerufen wurde und das Rufzeichen des Eigentümers VK2KTJ ist. (Siehe den Abschnitt <ref id="DE-AX25-HOWTO-pms-einrichten" name="Das PMS (Personal Message System) einrichten"> für weitere Details.) Die nächste Konfiguration nimmt Rufe an VK2KTJ-1 über den Port »radio« entgegen. Sie startet das Programm <tt/node/ für alle Stationen, die eine Verbindung zu VK1KTJ-1 aufbauen. Anschließend folgt eine NetROM-Konfiguration, man beachte die Verwendung der »<>«-Klammern anstelle eckiger Klammern »[]«. Damit wird eine NetROM-Konfiguration markiert. Sie ist einfacher, da nur festgelegt wird, daß für jede Station, die eine Verbindung zu dem Port »netrom« aufgebaut hat, das Programm <tt/node/ gestartet wird. Stationen mit Rufzeichen NOCALL werden ausgesperrt. Die letzten beiden Konfigurationen betreffen hereinkommende ROSE-Verbindungen. Die erste ist für Stationen, die VK2KTJ-0 gerufen haben, und die zweite für Verbindungen mit VK2KTJ-1, dem ROSE-Node. Sie funktionieren genau gleich. Man beachte die Verwendung von geschweiften Klammern »{}«, um die Konfiguration als ROSE-Konfiguration zu kennzeichnen. Das Beispiel hier ist frei erfunden, doch es sollte die wichtigen Eigenschaften und Möglichkeiten der Syntax der Konfigurationsdatei aufzeigen. In der Hilfeseite zu <tt/ax25d/ wird die Konfigurationsdatei vollständig erklärt. Ein detaillierteres und sicher ebenfalls nützliches Beispiel ist in dem Archiv der AX.25-Utilities enthalten. <sect1>Den ax25d starten <p> Ist die Konfigurationsdatei vervollständigt, startet man den <tt/ax25d/: <tscreen><verb> /usr/sbin/ax25d </verb></tscreen> Nun sollten andere Stationen Verbindungen zu unserer Maschine aufbauen können. Der Aufruf des <tt/ax25d/ sollte in die beim Systemstart ausgeführten Skripts eingefügt werden, damit dieser automatisch nach dem Booten zur Verfügung steht. <sect>Die Node-Software einrichten <p> Die Node-Software wurde von Tomi Manninen (<tt>tomi.manninen@hut.fi</tt>) entwickelt und basiert auf dem Original-PMS-Programm. Es stellt eine vollständige und flexible Node-Funktion zur Verfügung, die man einfach einrichten kann. In den aktuellen AX.25-Utilities ist das Programm nicht mehr enthalten, es liegt vielmehr als separates Paket auf <tt>ftp.hes.iki.fi</tt>. Dieses Paket ist <em/nur/ mit einem Kernel 2.2.x lauffähig. Das Programm erlaubt den verbundenen Nutzern, Telnet-, NetROM-, ROSE- und AX.25-Verbindungen aufzubauen und bestimmte Informationen zu erhalten, wie Finger, Nodes und Heard-Listen usw. Der Node kann sehr einfach so eingestellt werden, daß er jedes gewünschte Linux-Kommando ausführen kann. Das Programm <tt/node/ wird normalerweise vom <tt/ax25d/ aufgerufen, kann aber auch vom <tt/inetd/ gestartet werden, um Nutzern Zugriff via Telnet zu ermöglichen. Auch ein Aufruf von der Kommandozeile ist möglich. <sect1>Die Datei /etc/ax25/node.conf <p> In dieser Datei wird die hauptsächliche Konfiguration des Programms <tt/node/ vorgenommen. Sie ist eine einfache Textdatei mit folgendem Format: <tscreen><verb> #/etc/ax25/node.conf # Konfigurationsdatei für das Programm node. # # Zeilen, die mit einem '#' beginnen, sind Kommentare und werden vom # Programm ignoriert. # Hostname # Gibt den Rechnernamen der Node-Maschine an hostname radio.gw.vk2ktj.ampr.org # Local Network # hier kann man einstellen, was als 'Lokal' gilt, wichtig für # Zugriffsrechte in node.perms localnet 44.136.8.96/29 # Hidden Ports # Die hier angegebenen Ports sind für Nutzer unsichtbar. Sie werden # vom Befehl (P)orts nicht ausgegeben. hiddenports rose netrom # Callserver # Wenn eingestellt, wird ein Callserver zur Verfügung gestellt callserver zone.oh7rba.ampr.org # Node-Identifikation. # Dieser Text erscheint im Node-Prompt NodeId LINUX:VK2KTJ-9 # NetRom port # Name des für vom Node ausgehende NetROM-Verbindungen verwendeten # NetROM-Ports NrPort netrom # Node Idle Timeout # Gibt an, nach welcher Zeit der Inaktivität eine Verbindung vom Node # beendet wird (in Sekunden) idletimout 1800 # Connection Idle Timeout # Gibt an, nach welcher Zeit der Inaktivität eine Verbindung, die über # den Node läuft, beendet wird (in Sekunden) conntimeout 1800 # Reconnect # Gibt an, ob die Nutzer zum Node zurückverbunden werden sollen, wenn # die abgehende Verbindung getrennt wurde (reconnect) oder ob sie # vollständig vom Node getrennt werden sollen reconnect on # Command Aliases # Eine Möglichkeit, komplexe Befehle einfacher zu gestalten alias CONV "telnet vk1xwt.ampr.org 3600" alias BBS "connect radio vk2xsb" # External Command Aliases # Möglichkeit, externe Befehle unter node ausführen zu können # extcmd # Nur Flag == 1 ist implementiert # hat das gleiche Format wie in der Datei /etc/ax25/ax25d.conf extcmd PMS 1 root /usr/sbin/pms pms -u %U -o VK2KTJ # Logging # Mitschriften ins System-Log. # 3 - ausführlichste Form, 0 - ausgeschaltet loglevel 3 </verb></tscreen> <sect1>Die Datei /etc/ax25/node.perms <p> Das Programm <tt/node/ erlaubt, einzelnen Nutzern Zugriffsrechte zuzuteilen. Diese erlauben festzulegen, welche Nutzer beispielsweise Befehle wie (T)elnet oder (C)onnect ausführen dürfen und welche nicht. Diese Information wird in der Datei <tt>/etc/ax25/node.perms</tt> abgelegt, welche fünf Felder enthält. In allen Feldern ist der Stern »*« das Zeichen dafür, daß alle möglichen Optionen für das jeweilige Feld gelten sollen. Das ist nützlich, wenn man Standard-Festlegungen treffen will. Die einzelnen Felder: <descrip> <tag/user/ Das Rufzeichen des Nutzers, für den die folgenden Regelungen gelten sollen. SSID-Werte werden ignoriert, man sollte also nur das Rufzeichen angeben. <tag/method/ Für jedes Protokoll oder Zugriffsmethode gibt es auch Zugriffsrechte. Beispielsweise kann man Nutzern, die über AX.25 oder NetROM verbunden sind, erlauben, die (C)onnect-Option zu verwenden, diese aber anderen, die z.B. über telnet eingeloggt sind, verwehren. Man kann hier also festlegen, für welches Protokoll die Zugriffsrechte gelten sollen: <descrip> <tag/ampr/ Nutzer ist über eine AMPR-Adresse via Telnet verbunden <tag/ax25/ Nutzer ist über AX.25 verbunden <tag/host/ Node wurde von der Kommandozeile gestartet <tag/inet/ Nutzer ist von einer nicht-lokalen, nicht- AMPR-Adresse aus verbunden <tag/local/ Nutzer ist von einem »lokalen« Rechner aus verbunden <tag/netrom/ Nutzer ist über NetROM verbunden <tag/rose/ Nutzer ist über ROSE verbunden <tag/*/ Alle möglichen Verbindungsarten </descrip> <tag/port/ Für AX.25-Nutzer lassen sich Zugriffsrechte auch auf der Basis des verwendeten Ports festlegen. Damit kann man definieren, was AX.25-Nutzer in Abhängigkeit von dem Port, über den sie verbunden sind, tun dürfen. Im dritten Feld steht bei dieser Möglichkeit dann der Portname. Das Ganze ist nur für AX.25-Verbindungen sinnvoll. <tag/password/ Optional kann man den Node so einstellen, daß er die Nutzer nach einem Paßwort fragt. Das kann sinnvoll sein, um Nutzer mit vielen Zugriffsrechten zu schützen. Das Paßwort steht dann im vierten Feld der Datei. <tag/permissions/ Zugriffsrechte. Dieses Feld ist das letzte bei jedem Eintrag in <tt>/etc/ax25/node.perms.</tt> Es ist als Bit-Feld codiert, wobei jede Option einem Bit entspricht, das diese einschaltet, wenn es gesetzt ist, und ausschaltet, wenn es nicht gesetzt ist. Hier eine Liste der steuerbaren Optionen und ihrer Bitwerte: <tscreen><verb> Wert Beschreibung ------------------------------------------------------------ 1 Login erlaubt 2 AX.25-(C)onnects erlaubt 4 NetROM-(C)onnects erlaubt 8 (T)elnet zu lokalen Rechnern erlaubt 16 (T)elnet zu AMPR-Net-Rechnern (44.0.0.0) erlaubt 32 (T)elnet zu nicht-lokalen, nicht-AMPR-Net- Rechnern erlaubt 64 Versteckte Ports für AX.25-(C)onnects erlaubt 128 ROSE-(C)onnects erlaubt </verb></tscreen> Um die Zugriffsrechte festzulegen, rechnet man die Werte für alle Rechte des Users zusammen und schreibt die Summe in das fünfte Feld. </descrip> Die Datei <tt>node.perms</tt> könnte also etwa so aussehen: <tscreen><verb> # etc/ax25/node.perms # # Der Nodebetreiber ist VK2KTJ, sein Paßort ist "secret" # und er hat alle Zugriffsrechte bei allen Verbindungsarten vk2ktj * * secret 255 # Folgende Nutzer dürfen keine Verbindungen aufbauen NOCALL * * 0 PK232 * * 0 PMS * * 0 # INET-Nutzer dürfen keine Verbindungen aufbauen * inet * 0 # AX.25-, NetROM, lokale, Host- und AMPR-Nutzer können (C)onnects # und (T)elnet-Verbindungen zu anderen lokalen und AMPR-Rechnern, # jedoch nicht zu anderen IP-Adressen aufbauen * ax25 * * 159 * netrom * * 159 * local * * 159 * host * * 159 * ampr * * 159 </verb></tscreen> <sect1>node vom ax25d aus starten <p> Das Programm <tt/node/ wird normalerweise vom <tt/ax25d/ aus gestartet. Dazu müssen entsprechende Einträge in der Datei <tt>/etc/ax25/ax25d.conf</tt> vorgenommen werden. In der Beispielkonfiguration haben die Nutzer die Wahl, ob sie eine Verbindung zum Node oder zu anderen Diensten aufbauen wollen. Bei <tt/ax25d/ gibt es zu diesem Zweck sogenannte Port-Aliases. Beispiel: Bei der weiter oben angegebenen Konfiguration für <tt/ax25d/ soll unter dem Rufzeichen VK2KTJ-1 der Node erreichbar sein. Dazu wird folgendes in der Datei <tt>/etc/ax25/ax25d.conf</tt> hinzugefügt: <tscreen><verb> [vk2ktj-1 via radio] default * * * * * 0 root /usr/sbin/node node </verb></tscreen> Damit wird festgelegt, daß der Linux-Kernel-Code alle Verbindungsanforderungen für das Rufzeichen VK2KTJ-1, die er auf dem AX.25-Port radio hört, beantwortet und das Programm <tt/node/ startet. <sect1>node vom inetd aus starten <p> Es ist leicht möglich, den Node auch von einer Telnet-Verbindung aus zu nutzen. Zunächst ist festzulegen, zu welchem Port die die Nutzer ihre Verbindung aufbauen sollen. Im Beispiel wurde willkürlich Port 3694 gewählt, Informationen darüber, wie man den Telnet-Daemon durch <tt/node/ ersetzen kann, finden sich in Tomis Dokumentation. Zwei Dateien sind anzupassen. Der Datei <tt>/etc/services</tt> fügt man hinzu: <tscreen><verb> node 3694/tcp # OH2BNS's Node-Programm </verb></tscreen> und in <tt>/etc/inetd.conf</tt> kommt zusätzlich: <tscreen><verb> node stream tcp nowait root /usr/sbin/node node </verb></tscreen> Nach einem Neustart des <tt/inetd/ (vorher ein <tt>kill -HUP 1</tt>) bekommen alle Nutzer, die eine Telnet-Verbindung zum Port 3694 aufgebaut haben, eine Abfrage nach Loginname und Paßwort (wenn eingerichtet) und werden dann an <tt/node/ weitergegeben. <sect>axspawn einrichten <p> <tt/axspawn/ ist ein einfaches Programm, das anrufenden AX.25-Stationen den Login auf die eigene Maschine erlaubt. Es kann vom <tt/ax25d/ in gleicher Weise wie <tt/node/ gestartet werden. Um einem Nutzer ein Login auf die eigene Maschine zu erlauben, muß der Datei <tt>/etc/ax25/ax25d.conf</tt> eine Zeile ähnlich dieser hinzugefügt werden: <tscreen><verb> default * * * * * 1 root /usr/sbin/axspawn axspawn %u </verb></tscreen> Endet diese Zeile mit einem »+«, so muß der jeweilige Nutzer Return drücken, bevor er sich einloggen darf. Voreingestellt ist, daß nicht auf das Return gewartet wird. Für alle dieser Zeile folgenden Konfigurationen wird <tt/axspawn/ gestartet. <tt/axspawn/ prüft, ob das auf der Kommandozeile übergebene Rufzeichen gültig ist, entfernt dann eine etwaige SSID und schaut in <tt>/etc/passwd</tt> nach, ob der betreffende Nutzer einen Account besitzt. Gibt es einen Account , und das Paßwort ist entweder »« (nichts) oder »+«, dann ist der Nutzer eingeloggt, steht etwas im Paßwort-Feld, so wird der Nutzer nach einem Paßwort gefragt. Gibt es keinen Account für den Nutzer, so kann <tt/axspawn/ so eingestellt werden, daß es automatisch einen einrichtet. Achtung: Bei Distributionen, die mit dem sogenannten Password-Shadowing arbeiten, bei denen das Paßwort also nicht in <tt>/etc/passwd</tt> steht, kann es mit dem automatischen Anlegen von Nutzer-Accounts Probleme geben. In diesem Fall ist es günstiger, für alle nicht speziell definierten Nutzer eine Art Gast-Account vorzusehen, auf den jeder von ihnen zugreifen kann. <sect1>Die Datei /etc/ax25/axspawn.conf <p> Das Verhalten von <tt/axspawn/ kann mit der Datei <tt>/etc/ax25/ax25spawn.conf</tt> in verschiedener Weise beeinflußt werden. Diese Datei hat folgendes Format: <tscreen><verb> # /etc/ax25/axspawn.conf # # Automatische Erzeugung von Accounts für Nutzer? create yes # # Gastzugang, wenn oben 'no' eingestellt ist - oder nichts geht # Gastzugang ausgeschaltet mit 'no' guest no # # Gruppen-ID oder Name für Auto-Account group ax25 # # Erste zu verwendende Nutzerkennung (User-ID) first_uid 2001 # # Maximum für User-ID max_uid 3000 # # Home-Verzeichnis für die neuen Nutzer home home/ax25 # # Shell für die neuen Nutzer shell /bin/bash # # User-ID mit Rufzeichen für ausgehende Verbindungen verknüpfen associate yes </verb></tscreen> Ein »#« in der Datei markiert einen Kommentar; der Rest der Zeile wird ignoriert. Folgende acht Charakteristika von <tt/axspawn/ können eingestellt werden: <descrip> <tag/create/ Wenn auf »yes« gesetzt, versucht <tt/axspawn/, einen Account für alle Nutzer, die noch nicht in <tt>/etc/passwd</tt> aufgeführt sind, zu erzeugen. <tag/guest/ Dieses Feld bezeichnet den Loginnamen, der verwendet wird, wenn create auf »no« gestellt ist. Im Normalfall ist das »guest« oder »ax25«. <tag/group/ Bezeichnet den Gruppennamen, der für neu (create) angelegte Nutzer-Accounts verwendet wird. <tag/first_uid/ Nummer der ersten Benutzerkennung (User-ID), die für mit create neu angelegte Nutzer-Accounts verwendet werden soll. <tag/max_uid/ Höchste für Benutzerkennungen von mit create angelegten Accounts zu vergebende Zahl <tag/home/ Home-(Login-)Verzeichnis für neu angelegte Nutzer-Accounts <tag/shell/ Die für die neu angelegten Accounts zu verwendende Login-Shell <tag/associate/ Legt fest, ob abgehende Verbindungen unter dem Rufzeichen des ankommenden Nutzers oder dem der eigenen Station laufen sollen. </descrip> <sect>Das PMS (Personal Message System) einrichten <label id="DE-AX25-HOWTO-pms-einrichten"> <p> Das Programm <tt/pms/ ist eine Implementation eines einfachen Personal Message Systems. Es wurde von Alan Cox geschrieben und von Dave Brown, NR2JT (<tt>dcb@vectorbd.com</tt>) weiter verbessert. Zur Zeit ist das Programm noch sehr einfach, es erlaubt nur, Mitteilungen an den Eigentümer des Systems zu richten und einige begrenzte Systeminformationen abzufragen. Dave arbeitet daran, die Möglichkeiten des Programms zu erweitern. Es gibt einige Dateien, die man erzeugen sollte, um den Nutzern einige Informationen über das eigene System zu geben. Weiterhin müssen der Datei <tt>/etc/ax25/ax25d.conf</tt> die entsprechenden Einträge hinzugefügt werden, um das PMS den Nutzern zur Verfügung zu stellen. <sect1>Die Datei /etc/ax25/pms.motd <p> Diese Datei enthält den »Spruch des Tages« (Message Of The Day), den die Nutzer nach Aufbau der Verbindung und Empfang des üblichen BBS-ID-Headers lesen können. Es ist eine einfache Textdatei, deren Inhalt an die Nutzer gesendet wird. <sect1>Die Datei /etc/ax25/pms.info <p> Diese ist ebenfalls eine einfache Textdatei, die detailliertere Informationen über die eigene Systemkonfiguration oder Station enthält. Sie wird als Antwort auf den info-Befehl ausgesendet, den die Nutzer am PMS> - Prompt eingeben können. <sect1>AX.25-Rufzeichen Systembenutzern zuordnen <p> Sendet ein mit dem System verbundener Nutzer eine Mail an ein AX.25-Rufzeichen, so erwartet <tt/pms/, daß das Rufzeichen einem realen Systembenutzer auf der Maschine zugeordnet ist. Dies wird in einem gesonderten Abschnitt beschrieben. <sect1>PMS in die Datei /etc/ax25/ax25d.conf einbauen <p> Dies ist sehr einfach. Eine Sache muß aber beachtet werden: Dave hat für <tt/pms/ Kommandozeilenparameter vorgesehen, damit dieses verschiedene Konventionen für die Zeilenendmarkierung verarbeiten kann. AX.25 und NetROM erwarten die Zeilenendmarkierung als Carriage Return+Linefeed (CR+LF), während unter Unix ein New Line Standard ist. Will man also beispielsweise einen Eintrag in <tt>/etc/ax25/ax25d.conf</tt> vorsehen, der für jede auf einem AX.25-Port hereinkommende Verbindung das PMS startet, so fügt man etwa eine solche Zeile hinzu: <tscreen><verb> default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj </verb></tscreen> Damit wird das PMS gestartet und ihm mitgeteilt, daß es mit einer AX.25-Verbindung assoziiert ist und der Eigentümer des PMS VK2KTJ ist. Für andere Verbindungsarten gibt die Hilfeseite weiterführende Auskünfte. <sect1>Das PMS testen <p> Als Test für das PMS eignet sich z.B. folgender Befehl, der auf der Kommandozeile eingegeben wird: <tscreen><verb> /usr/sbin/pms -u vk2ktj -o vk2ktj </verb></tscreen> An Stelle von »vk2ktj« gibt man sein eigenes Rufzeichen an. PMS wird gestartet, es verwendet die unter UNIX übliche Zeilenendemarkierung und der eingeloggte Nutzer ist hier vk2ktj. Jetzt kann man alle Befehle, die den verbundenen Nutzern zur Verfügung stehen, ausprobieren. Zusätzlich kann man eine andere Station bitten, sich mit der eigenen zu verbinden, um zu prüfen, ob die Einstellungen in <tt>/etc/ax25/ax25d.conf</tt> funktionieren. <sect>Die user_call - Programme einrichten <p> Die user_call-Programme heißen in Wirklichkeit <tt/ax25_call/ und <tt/netrom_call/. Es sind sehr einfache Programme, die für den Aufruf durch den <tt/ax25d/ vorgesehen sind und Netzwerkverbindungen zu entfernten Rechnern automatisieren sollen. Natürlich können sie auch von Shellskripts oder anderen Programmen, wie <tt/node/, aufgerufen werden. Die Programme sind ähnlich wie das Programm <tt/call/: Sie verändern die Daten nicht, man muß sich also selbst darum kümmern, wie beispielsweise das Zeilenende behandelt werden soll. Zunächst ein Beispiel für die Verwendung. Angenommen, man habe ein kleines Netzwerk zu Hause und man habe eine Linux-Maschine als Funk-Gateway und einen BPQ-Node, über Ethernet mit dieser verbunden. Im Normalfall müßten Nutzer über Funk die Linux-Maschine als Digipeater verwenden oder eine Verbindung zum Node-Programm aufbauen und sich von da aus weiterverbinden lassen, wenn sie den BPQ-Node erreichen wollten. Dies kann durch das Programm <tt/ax25_call/ erleichtert werden, wenn es durch <tt/ax25d/ aufgerufen wird. Angenommen, der BPQ-Node habe das Rufzeichen VK2KTJ-9 und die Linux-Maschine habe den AX.25/Ethernet-Port namens bpq sowie einen Funk-Port namens radio. Mit einem Eintrag in <tt>/etc/ax25/ax25d.conf</tt> <tscreen><verb> [VK2KTJ-1 via radio] default * * * * * * * root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9 </verb></tscreen> erlaubte man Nutzern eine direkte Verbindung zu VK2KTJ-1 und damit zum Linux-AX.25-Daemon, der sie dann automatisch auf eine AX.25-Verbindung zu VK2KTJ-9 über das Interface bpq schalten würde. Es gibt eine Menge möglicher Konfigurationen. Die Programme <tt/netrom_call/ und <tt/rose_call/ funktionieren analog zu <tt/ax25_call/. Ein Funkamateur verwendete dieses Utility, um Verbindungen zu einer entfernten Mailbox leichter aufbauen zu können. Im Normalfall hatten die Nutzer eine lange Zeichenkette zum Aufbau der Verbindung einzugeben. Deshalb erzeugte er einen Eintrag, der die Box als im lokalen Netzwerk befindlich erscheinen ließ und übertrug <tt/ax25d/ und <tt/ax25_call/ den weiteren Verbindungsaufbau (Proxy-Prinzip). <sect>Die Befehle zum ROSE-Up- und -Downlink einrichten <p> Wer sich mit der ROM-basierten ROSE-Implementation auskennt, wird auch die Art des Verbindungsaufbaus über ein ROSE-Netzwerk kennen. Hat ein lokaler ROSE-Node eines AX.25-Nutzers das Rufzeichen VK2KTJ-5 und der Nutzer will eine Verbindung zu VK5XXX auf dem entfernten Node 5050882960, dann wird er folgenden Befehl eingeben: <tscreen><verb> c vk5xxx v vk2ktj-5 5050 882960 </verb></tscreen> Die entfernte Station VK5XXX würde dann eine unter dem Rufzeichen des lokalen Nutzers über das Rufzeichen des entfernten ROSE-Nodes (via) hereinkommende Verbindung erkennen. Diese Funktionen werden bei der ROSE-Implementation unter Linux nicht vom Kernel unterstützt, es gibt zwei Programme namens <tt/rsuplnk/ und <tt/rsdownlnk/ dafür. <sect1>Einen ROSE-Downlink einrichten <p> Damit die eigene Linux-Maschine hereinkommende ROSE-Verbindungen annimmt und entsprechend an das gewünschte Zielrufzeichen weiterleitet, muß der Datei <tt>/etc/ax25/ax25d.conf</tt> ein Eintrag hinzugefügt werden. Im Normalfall wird dieser als Voreinstellung für alle hereinkommenden ROSE-Verbindungen eingerichtet. Beispielsweise kann man ROSE-Nutzer für HEARD-0 oder NODE-0 lokal arbeiten lassen, für alle anderen Zielrufzeichen <tt/rsdownlink/ aufrufen: <tscreen><verb> # {* via rose} NOCALL * * * * * * L default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5 # </verb></tscreen> Bei dieser Einstellung wird jede über die ROSE-Node-Adresse hereinkommende Verbindung in eine AX.25-Verbindung auf dem AX.25-Port mit Namen 4800 mit dem Digipeater-Pfad VK2KTJ-5 umgewandelt, sofern kein gesondert zu behandelndes Zielrufzeichen angegeben wurde. <sect1>Einen ROSE-Uplink einrichten <p> Damit die eigene Linux-Maschine in gleicher Weise wie das ROM-basierte ROSE Verbindungen entgegennimmt, muß ein Eintrag in die Datei <tt>/etc/ax25/ax25d.conf</tt> eingefügt werden, etwa so: <tscreen><verb> # [VK2KTJ-5* via 4800] NOCALL * * * * * * L default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose # </verb></tscreen> Man beachte die spezielle Syntax für das lokale Rufzeichen. Das Zeichen »*« zeigt an, daß die Anwendung (hier <tt/rsuplnk/) gestartet werden soll, wenn das Rufzeichen im Digipeater-Pfad einer Verbindung auftaucht. Mit dieser Einstellung würde man einem AX.25-Nutzer erlauben, ROSE-Verbindungen mit dem unter 18. einleitend angegebenen Befehl herzustellen. Jeder Nutzer, der den Digipeater über VK2KTJ-5 auf dem AX.25-Port 4800 nutzen will, wird über <tt/rsuplnk/ weiterverbunden. <sect>AX.25-Rufzeichen Linux-Nutzern zuordnen <p> In vielen Situationen ist es wünschenswert, ein Rufzeichen einem Linux-Nutzer-Account zuzuordnen. Beispielsweise könnten mehrere Funkamateure die gleiche Linux-Maschine nutzen und unter ihrem eigenen Rufzeichen Verbindungen aufbauen wollen. Oder Nutzer des PMS wollen einem bestimmten Linux-Nutzer eine Nachricht zukommen lassen. Die AX.25-Software stellt eine Möglichkeit zur Verfügung, die Account-Namen von Linux-Nutzern mit Rufzeichen zu verbinden. Dies wurde im Abschnitt PMS bereits erwähnt, soll hier aber genauer dargestellt werden. Die Verknüpfung wird mit dem Befehl <tt/axparms/ hergestellt, beispielsweise so: <tscreen><verb> axparms -assoc vk2ktj terry </verb></tscreen> Dieser Befehl verknüpft einen User-Account namens terry auf der Maschine mit dem Funk-Rufzeichen vk2ktj. Jede Nachricht vom PMS an vk2ktj wird jetzt an den Account terry weitergeleitet. Nicht vergessen sollte man, diese Verknüpfungen in das beim Starten des Systems ausgeführte Skript einzubauen, damit sie bei jedem Neustart zur Verfügung stehen. Beachte: Man sollte <em/nie/ den root-Account mit einem Rufzeichen verknüpfen, da dies zu Konfigurationsproblemen in anderen Programmen führen kann. In den meisten Fällen funktionieren diese dann nicht wie erwartet. <sect>Die Einträge im /proc-Dateisystem <p> In dem Dateisystem unter <tt>/proc</tt> finden sich eine Reihe für die AX.25- und NetROM-Kernel-Software spezifische Dateien. Sie werden normalerweise von den AX.25-Utilities genutzt, sind aber einfach formatiert, so daß es interessant sein kann, ihren Inhalt zu studieren. Da das Format so einfach ist, sollte keine spezielle Erklärung notwendig sein. <descrip> <tag>/proc/net/arp</tag> Enthält die Liste der Address Resolution Protocol-Mappings zu Adressen auf MAC-Protokollebene. Diese können AX.25, Ethernet oder eine andere MAC-Protokollebene sein. <tag>/proc/net/ax25</tag> Enthält eine Liste der geöffneten AX.25-Sockets. Dies können aktive Sitzungen oder solche, die auf eine Verbindung warten, sein. <tag>/proc/net/ax25_bpqether</tag> Enthält die Mappings für die Rufzeichen für AX.25 über BPQ-Ethernet. <tag>/proc/net/ax25_calls</tag> Enthält die Zuordnungen von User-IDs zu Rufzeichen, wie sie mit <tt/axparms -assoc/ eingestellt wurden. <tag>/proc/net/ax25_route</tag> Enthält den AX.25-Digipeater-Pfad <tag>/proc/net/nr</tag> Enthält eine Liste der geöffneten NetROM-Sockets. Dies können aktive Sitzungen oder solche, die auf eine Verbindung warten, sein. <tag>/proc/net/nr_neigh</tag> Enthält Informationen über die der NetRom-Software bekannten benachbarten NetROM-Stationen. <tag>/proc/net/nr_nodes</tag> Enthält Informationen über die der NetRom-Software bekannten NetROM-Nodes. <tag>/proc/net/rose</tag> Enthält eine Liste der geöffneten ROSE-Sockets. Dies können aktive Sitzungen oder solche, die auf eine Verbindung warten, sein. <tag>/proc/net/rose_neigh</tag> Enthält Informationen über die der ROSE-Software bekannten benachbarten ROSE-Stationen. <tag>/proc/net/rose_nodes</tag> Enthält eine Zuordnung von ROSE-Zielen zu benachbarten ROSE-Stationen. <tag>/proc/net/rose_routes</tag> Enthält eine Liste aller bestehenden ROSE-Verbindungen </descrip> <sect>AX.25-, NetROM- und ROSE-Programmierung <p> Der vielleicht größte Vorteil bei der Nutzung der kernelbasierten Implementationen der Packet-Radio-Protokolle besteht in der Leichtigkeit, mit der Programme und Anwendungen zu ihrer Nutzung entwickelt werden können. Das Thema Netzwerk-Programmierung unter UNIX würde den Rahmen dieses Textes sprengen; hier sollen die elementaren Details der Nutzung der AX.25-, NetROM- und ROSE-Protokolle in eigener Software besprochen werden. <sect1>Adreßfamilien <p> Die Netzwerkprogrammierung für AX.25, NetROM und ROSE ist der TCP/IP-Programmierung unter Linux sehr ähnlich. Die hauptsächlichen Unterschiede ergeben sich aus den verwendenden Adreßfamilien und -strukturen, die entsprechend angeordnet werden müssen. Die Adreßfamilien tragen die Namen AF_AX25, AF_NETROM und AF_ROSE für die jeweiligen Protokolle. <sect1>Headerdateien <p> In eigenen Quelltexten muß immer ein »include«-Statement für <tt/ax25.h/, <tt/netrom.h/ oder <tt/rose.h/ vorgesehen werden, wenn man mit diesen Protokollen arbeitet. Für AX.25: <tscreen><verb> #include <ax25.h> int s, addrlen = sizeof(struct full_sockaddr_ax25); struct full_sockaddr_ax25 sockaddr; sockaddr.fsa_ax25.sax25_family = AF_AX25 </verb></tscreen> Für NetRom: <tscreen><verb> #include <ax25.h> #include <netrom.h> int s, addrlen = sizeof(struct full_sockaddr_ax25); struct full_sockaddr_ax25 sockaddr; sockaddr.fsa_ax25.sax25_family = AF_NETROM; </verb></tscreen> Für ROSE: <tscreen><verb> #include <ax25.h> #include <rose.h> int s, addrlen = sizeof(struct sockaddr_rose); struct sockaddr_rose sockaddr; sockaddr.srose_family = AF_ROSE; </verb></tscreen> <sect1>Rufzeichenhandhabung und Beispiele <p> Die Rufzeichenumwandlungen werden von Routinen erledigt, welche in der zu den AX.25-Utilities gehörenden Bibliothek <tt>/lib/ax25.a</tt> stehen. Natürlich kann man sich auch seine eigenen schreiben. Die User_call-Programme sind ein gutes Beispiel, von dem man starten kann. Ihre Quelltexte sind im Paket der AX.25-Utilities mit enthalten. Wenn man sich ein wenig damit befaßt, wird man feststellen, daß 90% der Arbeit in der Vorbereitung zum Öffnen des Sockets bestehen. Die Herstellung einer Verbindung ist einfach, nur die Vorbereitung braucht Zeit. Diese Beispiele sollten so einfach sein, daß sie nicht zu Verwirrungen führen. Wer Fragen hat, sollte sie an die Linux-Hams-Mailingliste schicken. Es wird sich dann sicherlich jemand finden, der weiterhilft. <sect>Einige Beispielkonfigurationen <p> Im folgenden werden Beispiele für einige der üblichsten Konfigurationen vorgestellt. Sie sollen als Anregung für die eigene Konfiguration dienen. <sect1>Kleines Ethernet-LAN mit Linux als Router auf Funk-LAN <p> <tscreen><verb> --- . | Netzwerk /---------\ . Netzwerk | 44.136.8.96/29 | | . 44.136.8/24 \ | / | | Linux | . \|/ | | | . | | eth0 | Router | . /-----\ /----------\ | |----------------| |-----| TNC |----| Radio |---/ | 44.136.8.97 | und | . \-----/ \----------/ | | | sl0 | | Server | 44.136.8.5 | | | . | | | . | \_________/ . --- . . . . . . </verb></tscreen> <tscreen><verb> #!/bin/sh # /etc/rc.net # Diese Konfiguration stellt einen KISS basierten AX.25-Port und # ein Ethernet-Device zur Verfügung. echo "/etc/rc.net" echo " Configuring:" echo -n " loopback:" /sbin/ifconfig lo 127.0.0.1 /sbin/route add 127.0.0.1 echo " done." echo -n " ethernet:" /sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \ broadcast 44.136.8.103 up /sbin/route add 44.136.8.97 eth0 /sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0 echo " done." echo -n " AX.25: " kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800 ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255 route add -host 44.136.8.5 sl0 route add -net 44.136.8.0 window 1024 sl0 echo -n " Netrom: " nrattach -i 44.136.8.5 netrom echo " Routing:" /sbin/route add default gw 44.136.8.68 window 1024 sl0 echo " default route." echo done. # end </verb></tscreen> <tt>/etc/ax25/axports</tt> <tscreen><verb> # name callsign speed paclen window description 4800 VK2KTJ-0 4800 256 2 144.800 MHz </verb></tscreen> <tt>/etc/ax25/nrports</tt> <tscreen><verb> # name callsign alias paclen description netrom VK2KTJ-9 LINUX 235 Linux Switch Port </verb></tscreen> <tt>/etc/ax25/nrbroadcast</tt> <tscreen><verb> # ax25_name min_obs def_qual worst_qual verbose 4800 1 120 10 1 </verb></tscreen> <itemize> <item>IP_FORWARDING muß im Kernel eingeschaltet sein. <item>Die AX.25-Konfigurationsdateien entsprechen weitestgehend den weiter oben aufgeführten Beispielen, siehe auch dort. <item>Für den Funkport wurde eine IP-Adresse gewählt, die nicht im Adreßblock des eigenen Netzwerkes enthalten ist. Das ist nicht unbedingt so notwendig, genausogut hätte man auch 44.136.8.97 für diesen Port vorsehen können. <item>44.136.8.68 ist hier der lokale IPIP-gekapselte Gateway - daher wird die voreingestellte Route dorthin gesetzt. <item>Jede der Maschinen im Ethernet-Netzwerk hat eine Route: <tscreen><verb> route add -net 44.0.0.0 netmask 255.0.0.0 \ gw 44.136.8.97 window 512 mss 512 eth0 </verb></tscreen> Mit der Verwendung der MSS und Window-Parameter erhält man optimale Performance sowohl im Ethernet als auch bei den Funkverbindungen. <item>Auf dem Router laufen ebenso die Daemonen smail, http, ftp und andere, so daß sie die einzige Maschine ist, die anderen Nutzern Dienste anbietet. <item>Der Router ist ein langsamer 386DX20 mit 20MB-Festplatte und minimaler Linux-Konfiguration. </itemize> <sect1>IPIP-gekapselter Gateway <p> Linux wird oft auch für TCP/IP-gekapselte Gateways verwendet. Der neue Tunnel-Treiber unterstützt mehrere gekapselte Routen und löst den veralteten ipip-Daemon ab. Eine typische Konfiguration würde etwa so aussehen: <tscreen><verb> . . . . . . --- . | Netzwerk /---------\ . Netzwerk | 154.27.3/24 | | . 44.136.16/24 \ | / | | Linux | . \|/ | | | . | | eth0 | IPIP | . /-----\ /----------\ | ---|---------------| |-----| TNC |----| Radio |---/ | 154.27.3.20 | Gateway | . \-----/ \----------/ | | | sl0 | | | 44.136.16.1 | | | . | | | . | \_________/ . --- . . . . . . </verb></tscreen> Einige zu beachtende Punkte: <itemize> <item>Der neue Tunnel-Treiber nutzt das GW-Feld in der Routing-Tabelle an Stelle des pointopoint-Parameters, zur Angabe der Adresse des entfernten IPIP-Gateway. Auf diese Weise unterstützt er nun mehrere Routen pro Interface. <item>Man kann zwei Netzwerk-Devices mit gleicher Adresse einrichten. In diesem Beispiel wurden die Devices sl0 und tunl0 mit der IP-Adresse des Funkports konfiguriert. Auf diese Weise erkennt der entfernte Gateway die korrekte Adresse des eigenen Gateways in den gekapselten Paketen, die an ihn gesendet wurden. <item>Die Route-Befehle zur Angabe der gekapselten Routen können automatisch mit einer modifizierten Version des Munge-Skripts erzeugt werden, die weiter unten abgedruckt ist. Die Route-Befehle werden dann in eine separate Datei geschrieben und mit dem Bash-Befehl <tscreen><verb> source /etc/ipip.routes </verb></tscreen> (angenommen, die Datei mit den Route-Befehlen heiße <tt>/etc/ipip.routes</tt>) wie dargestellt eingelesen. Die Quelldatei muß das NOS-Format für Route-Befehle haben. <item>Beachte die Verwendung des Window-Arguments bei dem Route-Befehl. Der richtige Wert für diesen Parameter erhöht die Performance der Funkverbindung. </itemize> Das neue Tunnel-munge-Script: <tscreen><verb> #!/bin/sh # # Von: Ron Atkinson # # Dieses Skript basiert auf dem ursprünglich für den IPIP- # Daemon geschriebenen »munge«-Skript von Bdale N3EUA, # es wurde von Ron Atkinson N8FOW modifiziert. # Es dient zur Umwandlung einer Gateway-Route-Datei im KA9Q NOS-Format # (üblicherweise »encap.txt«) in das Format der Linux-Routing-Tabelle # für den IP -Tunnel-Treiber. # # Aufruf: Gateway-Datei auf stdin, Linux -Routingtabelle auf stdout. # z.B. tunnel-munge < encap.txt > ampr-routes # # ACHTUNG: Bevor das Skript nutzbar ist, muß folgendes überprüft werden: # # 1) Trage für »Local routes« und »Misc user routes« die im eigenen # Gebiet gültigen Routen ein und entferne die Beispiele! # 2) Auf der »fgrep«-Zeile muß die EIGENE Internet-Gateway-Adresse # eingetragen werden. Wird dies nicht getan, so entstehen # ernsthafte Probleme durch Routing-Schleifen. # 3) Der voreingestellte Name des Interfaces ist »tunl0«. # Es ist sicherzustellen, daß dies auf dem eigene System zutrifft. echo "#" echo " # IP tunnel route table built by $LOGNAME on `date`" echo "# by tunnel-munge script v960307." echo "#" echo "# Local routes" echo " route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0" echo "#" echo "# Misc user routes" echo "#" echo "# remote routes" fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \ awk '{ split($3, s, "/") split(s[1], n,".") if (n[1] == "") n[1]="0" if (n[2] == "") n[2]="0" if (n[3] == "") n[3]="0" if (n[4] == "") n[4]="0" if (s[2] == "1") mask="128.0.0.0" else if (s[2] == "2") mask="192.0.0.0" else if (s[2] == "3") mask="224.0.0.0" else if (s[2] == "4") mask="240.0.0.0" else if (s[2] == "5") mask="248.0.0.0" else if (s[2] == "6") mask="252.0.0.0" else if (s[2] == "7") mask="254.0.0.0" else if (s[2] == "8") mask="255.0.0.0" else if (s[2] == "9") mask="255.128.0.0" else if (s[2] == "10") mask="255.192.0.0" else if (s[2] == "11") mask="255.224.0.0" else if (s[2] == "12") mask="255.240.0.0" else if (s[2] == "13") mask="255.248.0.0" else if (s[2] == "14") mask="255.252.0.0" else if (s[2] == "15") mask="255.254.0.0" else if (s[2] == "16") mask="255.255.0.0" else if (s[2] == "17") mask="255.255.128.0" else if (s[2] == "18") mask="255.255.192.0" else if (s[2] == "19") mask="255.255.224.0" else if (s[2] == "20") mask="255.255.240.0" else if (s[2] == "21") mask="255.255.248.0" else if (s[2] == "22") mask="255.255.252.0" else if (s[2] == "23") mask="255.255.254.0" else if (s[2] == "24") mask="255.255.255.0" else if (s[2] == "25") mask="255.255.255.128" else if (s[2] == "26") mask="255.255.255.192" else if (s[2] == "27") mask="255.255.255.224" else if (s[2] == "28") mask="255.255.255.240" else if (s[2] == "29") mask="255.255.255.248" else if (s[2] == "30") mask="255.255.255.252" else if (s[2] == "31") mask="255.255.255.254" else mask="255.255.255.255" if (mask == "255.255.255.255") printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\ ,n[1],n[2],n[3],n[4],$5 else printf "route add -net %s.%s.%s.%s gw %s netmask %s dev tunl0\n"\ ,n[1],n[2],n[3],n[4],$5,mask }' echo "#" echo "# default the rest of amprnet via mirrorshades.ucsd.edu" echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0" echo "#" echo "# the end" </verb></tscreen> Für den Kernel 2.2.x mit aktuellem AX.25-Subsystem gilt ein neues Skript: <tscreen><verb> #!/usr/bin/perl # # Von: Ron Atkinson # # Dieses Skript basiert auf dem ursprünglich für den IPIP- # Daemon geschriebenen »munge«-Skript von Bdale N3EUA, # es wurde von Ron Atkinson N8FOW modifiziert. # Es dient zur Umwandlung einer Gateway-Route-Datei im KA9Q NOS-Format # (üblicherweise »encap.txt«) in das Format der Linux-Routing-Tabelle # für den IP -Tunnel-Treiber. # # Verbesserte Perl-Version by Heikki Hannikainen # # Versionen: # # 2.1 hessu Thu Jul 8 19:41:18 EEST 1999 # - Modifiziert für /sbin/ip # # Aufruf: z.B. munge encap.txt rc.tun-routes # # ACHTUNG: Bevor das Skript nutzbar ist, muß folgendes # überprüft werden: # # 1) Die @my_addresses-Liste muß STATT DER in diesem # Text stehenden Adressen die IP-Adresse des eigenen # Gateways (und Adressen, für die manuell eingetragene # statische Routen existieren) enthalten. # # verwendetes Tunnel-Device $tunnel_device = "tunl0"; # Adressen lokaler Gateways (deren Routen werden übergangen) @my_addresses = ("193.167.178.112", "193.166.55.160", "195.148.207.30"); # route binary $routebin = "/sbin/ip"; # tcp window to set $window = 840; if ($#ARGV != 1) { print "Aufruf: $0 encap.txt rc.tun-routes\n"; exit 1; } open(inf, @ARGV[0]) || die "Kann nicht oeffnen: @ARGV[0]: $!"; open(upf, ">@ARGV[1]") or die "Kann nicht oeffnen: @ARGV[1]: $!";; $hdr = "#\n# IP tunnel route table\n#\n#\n"; print upf $hdr; LOOP: while ($line = ) { @fields = (); @abytes = (); $bits = ""; @fields = split(' ', $line); if (@fields[0] ne "route") { next LOOP; } $gw = @fields[4]; $net = @fields[2]; ($addr, $bits) = split('/', $net); if (!$bits) { $bits = 32; } @abytes = split('\.', $addr); for ($i = 0; $i < 4; $i++) { if (@abytes[$i] eq "") { @abytes[$i] = "0"; } } $addr = join('.', @abytes); foreach $my (@my_addresses) { if ($gw eq $my) { print "$addr/$bits > $gw blocked, local gw\n"; next LOOP; } } if ($addr !~ /^44\./) { print "$addr/$bits > $gw blocked, non-amprnet address!\n"; next LOOP; } if ($gw =~ /^44\./) { print "$addr/$bits > $gw blocked, inside amprnet!\n"; next LOOP; } if ($bits < 16) { print "$addr/$bits > $gw blocked, mask smaller than 16 bits!\n"; next LOOP; } print upf "$routebin route add $addr/$bits via $gw dev $tunnel_device onlink 2>/dev/null\n"; } print upf "#\n# the end\n#\n"; close(inf); close(upf); </verb></tscreen> Zum Schluß ist das Tunnel-Device mit <tscreen><verb> ifconfig tunl0 44.139.39.66 mtu 250 up </verb></tscreen> zu aktivieren, wobei für 44.139.39.66 die eigene IP-Adresse einzusetzen ist. <sect1>Die Einrichtung des AXIP-encapsulated Gateway <p> Auf vielen Internet-Gateways des Amateurfunks werden AX.25, NetRom und ROSE zusätzlich zu TCP/IP gekapselt. Die Kapselung von AX.25-Frames innerhalb von IP-Datagrammen wird in RFC-1226 von Brian Kantor beschrieben. Mike Westerhof schrieb 1991 einen Daemon für AX.25-Kapselung für UNIX. Die AX-25-Utils enthalten eine leicht verbesserte Version für Linux. Ein Programm zur AXIP-Kapselung nimmt an einem Ende AX.25-Frames entgegen, prüft die AX.25-Empfängeradresse, um festzulegen, an welche IP-Adresse das gekapselte Paket weitergeleitet werden muß, kapselt es sodann in ein TCP/IP-Datagramm und sendet es schließlich an das passende Ziel. In umgekehrter Richtung nimmt es in TCP/IP-Datagrammen enthaltene AX.25-Frames entgegen, packt diese aus und behandelt sie weiter, als ob sie direkt von einem AX.25-Port empfangen worden wären. Um TCP/IP-Datagramme, die AX.25-Frames enthalten, von anderen ohne solchen Inhalt unterscheiden zu können, werden AXIP-Datagramme mit einer Protokoll-Identifizierung von 4 (oder früher 94) versehen. Dies wird in RFC-1226 beschrieben. Das in den AX-25-Utils enthaltene Programm <tt/ax25ipd/ stellt sich als KISS-Interface, über das AX.25-Frames übertragen werden, und als Interface zu TCP/IP dar. Es wird mit einer einzigen Konfigurationsdatei, <tt>/etc/ax25/ax25ipd.conf</tt>, eingerichtet. <sect2>Einstellungsoptionen für AXIP <p> Das Programm <tt/ax25ipd/ kennt zwei hauptsächliche Betriebsarten, »Digipeater«- und »TNC«-Modus. Im TNC-Modus wird der Daemon wie ein KISS-TNC verwendet, man schickt KISS-Pakete an das Programm und es sendet diese weiter - dies ist die übliche Konfiguration. Im »Digipeater«-Modus wird der Daemon wie ein AX.25-Digipeater behandelt. Es gibt einige feine Unterschiede zwischen diesen Betriebsarten. In der Konfigurationsdatei definiert man »routes« oder mappings zwischen den AX.25-Ziel-Rufzeichen und den IP-Adressen der Rechner, denen man die Pakete schicken will. Jede Route besitzt Optionen, die später beschrieben werden. Weiterhin kann man hier folgendes einrichten: <itemize> <item>die tty-Schnittstelle, die vom <tt/ax25ipd/ geöffnet werden soll und deren Geschwindigkeit (üblicherweise ein Ende einer Pipe) <item>das Rufzeichen, welches für den »Digipeater«-Modus verwendet werden soll <item>Bakenintervall und -text <item>ob die AX.25-Frames in IP-Datagramme oder in UDP/IP-Datagramme gekapselt werden sollen. </itemize> So gut wie alle AXIP-Gateways verwenden IP-Kapselung, doch einige befinden sich hinter Firewalls, die keine IP-Pakete mit der Protokoll-ID des AXIP durchlassen, und sind daher gezwungen, UDP/IP zu verwenden. Die hier getroffene Einstellung muß mit der des TCP/IP-Zielrechners übereinstimmen. <sect2>Eine typische Datei /etc/ax25/ax25ipd.conf <p> <tscreen><verb> # # ax25ipd -Konfigurationsdatei für die Station floyd.vk5xxx.ampr.org # # Datentransportart wählen. »ip« für die Kompatibilität # mit den meisten anderen Gateways. socket ip # # Betriebsart des ax25ipd einstellen. (digi oder tnc) # mode tnc # # Wurde digi eingestellt, muß ein Rufzeichen angegeben werden. # Im tnc -Modus ist das rufzeichen zur Zeit optional, doch das kann # sich in Zukunft ändern! (2 Rufzeichen bei dual port kiss) # #mycall vk5xxx-4 #mycall2 vk5xxx-5 # # In digi -Modus können Aliases genutzt werden. (2 für dual port) # #myalias svwdns #myalias2 svwdn2 # # Aussenden einer Indentifikation aller 540 Sekunden ... # beacon after 540 # btext ax25ip -- tncmode rob/vk5xxx -- Experimenteller AXIP Gateway # # Serielle Schnittstelle oder mit einem kissattach verbundene Pipe # in diesem Fall: device /dev/ttyq0 # # Transferrate einstellen: # speed 9600 # # loglevel 0 - keine Ausgabe # loglevel 1 - nur Konfigurationsinformationen # loglevel 2 - Schwerwiegende Ereignisse und Fehler # loglevel 3 - Schwerwiegende Ereignisse und Fehler, AX.25-Paketmitschnitt # loglevel 4 - Alle Ereignisse # loglevel 2 # # im Digi-Modus mit einem echten TNC verwendet man param zur Einstellung # der TNC-Parameter... # #param 1 20 # # Definition der Broadcast-Adresse . Jede der aufgeführten Adressen # wird an jede als broadcastfähig markierte Route weitergeleitet # broadcast QST-0 NODES-0 # # Definition der AX.25-Routen, soviele einstellbar, wie benötigt. # Format: Route (Rufzeichen/Wildcard) (Adresse des IP-Zielrechners) # ssid of 0 routes all ssid's # # route [flags] # # Gültige Flags: # b - Broadcasts dürfen über diese Route # geschickt werden # d - diese Route ist die standardmäß voreingestellte # route vk2sut-0 44.136.8.68 b route vk5xxx 44.136.188.221 b route vk2abc 44.1.1.1 # # </verb></tscreen> <sect2>ax25ipd starten <p> Zunächst wird der Datei <tt>/etc/ax25/axports</tt> ein Eintrag hinzugefügt: <tscreen><verb> # /etc/ax25/axports # axip VK2KTJ-13 9600 256 AXIP port # </verb></tscreen> Dann wird <tt/kissattach/ gestartet, um diesen Port zu erzeugen: <tscreen><verb> /usr/sbin/kissattach /dev/ptyq0 axip </verb></tscreen> Schließlich startet man <tt/ax25ipd/: <tscreen><verb> /usr/sbin/ax25ipd & </verb></tscreen> Die AXIP-Verbindung testet man mit: <tscreen><verb> call axip vk5xxx </verb></tscreen> <sect2>Einige Bemerkungen zu Routen und Flags <p> Mit dem »route«-Befehl gibt man an, wo die AX.25-Pakete gekapselt hingeschickt werden sollen. Empfängt <tt/ax25ipd/ ein Paket von seinem Interface, so vergleicht das Programm das Zielrufzeichen mit jedem Rufzeichen in seiner Routing-Tabelle. Bei einer Übereinstimmung wird das AX.25-Paket in ein IP-Datagramm gekapselt und an den Rechner mit der entsprechend angegebenen IP-Adresse geschickt. Zwei Flags können jedem »route« Befehl in der Datei <tt>/etc/ax25ipd.conf</tt> hinzugefügt werden. Es sind folgende: <descrip> <tag/b/ Pakete mit einer Zieladresse, die einer der mit dem Schlüsselwort »Broadcast« definierten Adressen entspricht, sollen über diese Route weitergeleitet werden. <tag/d/ Pakete, die mit keiner festgelegten Route übereinstimmen, sollen über diesen Weg weitergeleitet werden. </descrip> Das Flag »b« (Broadcast) ist sehr nützlich, da es ermöglicht, Informationen, die normalerweise für alle Stationen gedacht waren, auch einer bestimmten Anzahl AXIP-Stationen zukommen zu lassen. Normalerweise sind AXIP-Routen Punkt-zu-Punkt-Verbindungen und können nichts mit »Broadcast«-Paketen anfangen. <sect1>Wie verbindet man NOS und die Linux-Kernel-Netzwerk-Software <p> Viele Leute verwenden eine NOS-Version unter Linux, da es alle von ihnen gewünschten Eigenschaften und Möglichkeiten bietet. Die meisten von ihnen würden gern das NOS mit dem Linux-Kernel verbinden, so daß einige der Linux-Möglichkeiten für Funk-Nutzer zur Verfügung stünden. <sect2>NOS und Linux mit einer Pipe verbinden <p> Von Brandon S. Allbery, KF8NH, wurden die folgenden Informationen beigesteuert, die erklären, wie man das NOS mit dem Linux-Kernel-Code mittels einer Linux-Pipe verbindet. Da sowohl Linux als auch NOS das SLIP-Protokoll unterstützen, kann man beide über SLIP miteinander verbinden. Man könnte dazu zwei serielle Schnittstellen mit einem Loopback-Kabel verwenden, doch das wäre langsam und kostspielig. Linux stellt wie viele andere UNIX-ähnliche Betriebssysteme sogenannte Pipes zur Verfügung. Dabei handelt es sich um Pseudo-Devices, die für die Software wie TTY-Devices erscheinen, aber in Wirklichkeit eine Schleife (Loopback) auf ein anderes Pipe-Device darstellen. <!--fixme: link --> Um diese Pipes zu verwenden, muß das erste Programm das »master«-Ende und das zweite das »slave«-Ende der Pipe öffnen. Siehe dazu auch den Absatz »Dual-Port-TNCs einrichten« unter dem Abschnitt »7.1. KISS«. Sind beide Enden eröffnet, so können die beiden Programme miteinander Daten austauschen, indem sie Zeichen in die Pipe wie in ein normales TTY-Device schreiben. Damit das Ganze genutzt werden kann, um den Linux-Kernel und NOS oder irgendein anderes Programm miteinander zu verbinden, muß zunächst das zu verwendende Pipe-Device aus dem <tt>/dev</tt>-Verzeichnis ausgewählt werden. Die »master«-Enden der Pipes tragen die Namen <tt/ptyq1/ bis <tt/ptyqf/, die »slave«-Enden <tt/ttyq1/ bis <tt/ttyqf/. Zu jedem »master« gehört immer ein »slave«, so daß man <tt/ttyqf/ als »slave« verwenden muß, wenn <tt/ptyqf/ als »master« ausgewählt wurde. Wenn man nun ein solches Device-Paar gewählt hat, sollte man das »master«-Ende mit dem Linux-Kernel und das »slave«-Ende mit NOS verbinden, da der Linux-Kernel als erstes startet und das »master«-Ende immer vor dem »slave«-Ende geöffnet werden muß. Ebenso muß der Linux-Kernel eine andere IP-Adresse als NOS haben, so daß man diesem eine eigene IP-Adresse zuweisen sollte, wenn das nicht bereits geschehen ist. Die Pipe wird wie ein serielles Device eingerichtet, um eine SLIP-Verbindung vom Linux-Kernel aus zu erstellen, kann man etwa folgende Befehle verwenden: <tscreen><verb> /sbin/slattach -s 38400 -p slip /dev/ptyqf & /sbin/ifconfig sl0 broadcast 44.255.255.255 \ pointopoint 44.70.248.67 mtu 1536 44.70.4.88 /sbin/route add 44.70.248.67 sl0 /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 \ gw 44.70.248.67 </verb></tscreen> In diesem Beispiel hat der Linux-Kernel die IP-Adresse 44.70.4.88 und NOS die IP-Adresse 44.70.248.67. Der route-Befehl in der letzten Zeile veranlaßt den Linux-Kernel, alle Datagramme (Pakete) für das AMPRNet (44.0.0.0) über die SLIP-Verbindung, die mit <tt/slattach/ vorher erzeugt wurde, weiterzuleiten. Im Normalfall kommen diese Befehle in das Skript <tt>/etc/rc.d/rc.inet2</tt> (Slackware) nach die übrige Netzwerkkonfiguration, damit die SLIP-Verbindung beim Neustart automatisch wiederhergestellt wird. Man beachte, daß die Verwendung von CSLIP (compressed SLIP) hier keinen Vorteil bringt, da die Verbindung nur virtuell ist und durch das Komprimieren ein Performanceverlust eintreten würde. Dadurch würden die Pakete mit komprimiertem Header langsamer übertragen als die unkomprimierten Pakete. Um das NOS-seitige Ende der SLIP-Verbindung einzurichten, kann man diese Befehle verwenden: <tscreen><verb> # Das Interface kann einen beliebigen Namen tragen; hier wird # wegen der Eindeutigkeit »linux« verwendet attach asy ttyqf - slip linux 1024 1024 38400 route \ addprivate 44.70.4.88 linux </verb></tscreen> Damit wird ein SLIP-Port mit Namen linux über das »slave«-Ende der Pipe zum Linux-Kernel erzeugt. Der Route-Befehl aktiviert diesen dann. Wenn NOS gestartet wurde, sollte man jetzt in der Lage sein, ping und telnet von NOS nach Linux und umgekehrt ausführen zu können. Funktioniert dies nicht, so muß man nochmals überprüfen, ob kein Fehler, besonders beim Konfigurieren der Adressen, aufgetreten ist und die Pipe-Devices ordnungsgemäß verfügbar sind. <sect>Wo finde ich Informationen zu ...? <p> Da dieser Text einige Erfahrung mit Packet Radio voraussetzt und dies nicht immer der Fall ist, hat Terry einige Verweise zu nützlichen Informationsquellen zusammengestellt. <sect1>Packet Radio <p> Allgemeine Informationen zu Packet Radio findet man hier: <descrip> <tag/American Radio Relay League/ <tt><htmlurl url="http://www.arrl.org/" name="http://www.arrl.org/"></tt> <tag/Radio Amateur Teleprinter Society/ <tt><htmlurl url="http://www.rats.org" name="http://www.rats.org"></tt> <tag/Tucson Amateur Packet Radio Group/ <tt><htmlurl url="http://www.tapr.org/" name="http://www.tapr.org/"></tt> </descrip> <sect1>Protokolldokumentation <p> Jonathan Naylor hat eine Reihe von Dokumenten gesammelt, die sich mit den im Packet Radio verwendeten Protokollen beschäftigen. Sie wurden gepackt und sind hier zu finden: <tscreen> <htmlurl url="ftp://ftp.pspt.fi/pub/ham/linux/ax25/ax25-doc-1.0.tar.gz" name="ftp.pspt.fi:/pub/ham/linux/ax25/ax25-doc-1.0.tar.gz"> </tscreen> <sect1>Hardware-Dokumentation <p> Informationen zur PI2-Karte werden von der Ottawa Packet Radio Group, zur Verfügung gestellt. Informationen zur Baycom-Hardware ist auf der Baycom-WWW-Seite <tscreen> <htmlurl url="http://www.baycom.de/" name="http://www.baycom.de/"> </tscreen> zu finden. Eine Seite mit vielen Links zum Thema Amateurfunk und Packet Radio findet man hier: <tscreen> <htmlurl url="http://www.ardos.de/gerd/ham.html" name="http://www.ardos.de/gerd/ham.html"> </tscreen> <sect>Diskussionsforen zu Amateurfunk und Linux <p> Diskussionen zu Amateurfunk und Linux finden an vielen Stellen statt. Sowohl in den Newsgroups der <tt>comp.os.linux.*</tt>-Hierarchie, als auch in der HAM-Liste auf <tt>vger.rutgers.edu</tt> kann man an ihnen teilnehmen. Ebenso gibt es noch die tcp-group-Mailingliste auf <tt/ucsd.edu/ als Heimat für die Diskussionen über TCP/IP im Amateurfunk und ebenso den Channel <tt>#linpeople</tt> auf IRC. Die Mailingliste für FPAC erreicht man unter <tt>fpac@qth.net</tt>. Um der Mailingliste linux-hams beizutreten, sendet man eine E-Mail an <tt>Majordomo@vger.rutgers.edu</tt>, die den Text <tscreen><verb> subscribe linux-hams </verb></tscreen> enthält. Die »Subject«-Zeile wird ignoriert (freilassen). Diese Mailingliste wird hier archiviert: <itemize> <item><tt><htmlurl url="http://hes.iki.fi/archive/" name="http://hes.iki.fi/archive/"></tt> <item><tt><htmlurl url="http://zone.oh7rba.ampr.org/archive/linux-hams/" name="http://zone.oh7rba.ampr.org/archive/linux-hams"></tt> </itemize> Für den Anfang sollte man diese Archive verwenden, da viele häufige Fragen hier bereits beantwortet werden. Der tcp-Gruppe tritt man so bei: E-mail an <tt>listserver@ucsd.edu</tt> mit der Zeile <tscreen><verb> subscribe tcp-group </verb></tscreen> als Text schicken. Beachte: Die TCP/IP-Gruppe ist primär für Diskussionen über verbesserte Protokolle, wie TCP/IP, im Amateurfunk gedacht. Linux-spezifische Fragen sollten möglichst nicht dort gestellt werden. <sect>Danksagung <p> Folgende Leute haben auf die eine oder andere Weise, wissentlich oder unwissentlich, zum Entstehen dieses Textes beigetragen. In ungeordneter Reihenfolge sind dies Jonathan Naylor, Thomas Sailer, Joerg Reuter, Ron Atkinson, Alan Cox, Craig Small, John Tanner, Brandon Allbery - und nicht zuletzt der Autor des englischen Originaltextes, Terry Dawson, dem ich an dieser Stelle für seine geduldigen und kompetenten Antworten in der Linux-Ham-Mailingliste danken will. Bitte Fragen zur deutschen Version <em/nicht/ an Terry Dawson oder in die Linux-Ham-Mailingliste sonder an Gerd Röthig (<tt>roetg@medizin.uni-leipzig.de</tt>) schicken. Ich würde mich freuen, wenn ich über evtl. notwendige Veränderungen, Umformulierungen oder Korrekturen in Kenntnis gesetzt würde. Viel Freude also mit Linux und Packet Radio, 55 & 73. <sect>Copyright <p> Dieses Dokument ist urheberrechtlich geschützt. Das Copyright für die englische <em/AX25 HOWTO/, auf der dieses Dokument basiert, liegt bei Terry Dawson. Das Copyright für die deutsche Version liegt bei Gerd Röthig und Marco Budde. Das Dokument darf gemäß der GNU General Public License verbreitet werden. Insbesondere bedeutet dieses, daß der Text sowohl über elektronische wie auch physikalische Medien ohne die Zahlung von Lizenzgebühren verbreitet werden darf, solange dieser Copyright Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt und ausdrücklich erwünscht. Bei einer Publikation in Papierform ist das Deutsche Linux HOWTO Projekt hierüber zu informieren. <sect>ANHANG: Einige aus dem Englischen übernommene Fachbegriffe und deren Erklärung <p> <descrip> <tag>Broadcast</tag> Aussendungen, die nicht an eine bestimmte Adresse, sondern an alle gerichtet sind und daher unprotokolliert gesendet werden (Beispiel: Aussendung der Routing- Informationen durch NetROM, auch Baken können in diesem Sinne als Broadcast betrachtet werden) <tag>Device</tag>hier im Sinne eines sogenannten »virtuellen Geräts« gebraucht, d.h., ein Treiber (Driver) stellt ein Software-Interface zur Verfügung, das ähnlich wie eine Gerätedatei angesprochen werden kann. Auf diese Weise wird die Unterscheidung zwischen den Protokollen realisiert - jedem dieser Devices ist genau ein Übertragungsprotokoll zugeordnet. Sie können auf weiteren Devices aufsetzen, also deren Geladensein voraussetzen. <tag>Digipeater</tag>Station, die die eigenen Pakete, so wie sie sie empfängt, wiederholt (DIgital rePEATER), es erfolgt kein direkter Verbindungsaufbau zu diesem Rechner, sondern man baut einen Link "über" (via) ihn auf <tag>Encapsulation</tag> svw. Kapselung (hier auch so übersetzt), bezeichnet einen Weg der Übertragung über mit TCP/IP arbeitende Netzwerke, indem AX.25-Pakete in spezielle IP-Datagramme hineingeschrieben werden. Die Protokoll-Informationen des IP wirken dann wie eine »Kapsel« um das AX.25-Frame herum, die dessen unbeschadeten Transport und Identifikation ermöglicht <tag>Heard, MHeard</tag>Ausgabe, welche Stationen auf einem bestimmten Kanal gehört (aufgenommen) werden konnten <tag>Gateway</tag>hier: mit mehreren Netzen gleichzeitig verbundener Rechner, an den alle Pakete gehen, die innerhalb eines Netzes nicht zugestellt werden können - diese Pakete werden dann in eines der anderen erreichbaren Netze weitergeleitet <tag>Nodes</tag>meist TNCs mit spezieller Node-Software ohne daran angeschlossenen Host-Rechner, aber auch PCs mit entsprechender Software (z.B. node oder BPQ), zu denen man im Unterschied zu den Digipeatern eine direkte Verbindung aufbaut und ihnen dann den Befehl zum Weiterverbinden gibt <tag>Obsolescence</tag>(svw. Alterung) NetROM-Begriff, der die Aktualität einer Verbindung angibt, Zeitspanne, die seit der letzten gehörten Aktivität der betreffenden Station vergangen ist, zur Beurteilung der Qualität einer Funkverbindung hilfreich <tag>Routing</tag>Weiterleiten von Paketen/Daten auf einem vorgegebenen Weg/an einen in der Routing-Tabelle (routing table) festgelegten Rechner, evtl. auf einem dort definierten Weg (Routing-Path). <tag>Switching</tag>svw. Umschalten: Aussenden/Weiterleiten von Daten über einen anderen Kanal/Port, netzwerktechnisch Schalten einer Punkt-zu-Punkt-Verbindung zwischen Sender und Empfänger für die Zeitdauer der Übertragung des entsprechenden Paketes </descrip> Ein Wort zu Kernel 2.2 und dessen derzeitigem Entwicklungsstand Aktuelle Mitteilung: Das AX.25-Subsystem ist im Kernel 2.2.x noch unvollständig. Wenn man beispielsweise ein AX.25-Netzwerk-Device bei einem noch laufenden Connect herunterfährt, bekommt man einen Systemabsturz (»Oops«). Um das System wieder nutzbar zu machen, ist anschließend ein Neustart fällig. Ich wurde gefragt, weshalb der aktuelle Kernel 2.2 momentan in diesem HOWTO keine ausführlichere Erwähnung findet. Meine persönliche Meinung dazu gibt folgendes Statement wieder: Zum derzeitigen Zeitpunkt ist ein Upgrade auf den Kernel 2.2 keine gute Wahl. Der Kernel verwendet in vielen Bereichen eine andere Treiberarchitektur, was zur Folge hat, daß bestimmte Hardware neu eingerichtet werden muß. Was auf die Hardware-Treiber zutrifft, ist auch beim Kernel-AX.25 der Fall - eine völlige Neueinrichtung wird fällig. Da die Systemschnittstelle auch im AX.25-Bereich abgewandelt wurde, werden ältere Binärversionen der AX.25-Programme nicht mehr vollständig funktionieren. Es kann nur geraten werden, abzuwarten, bis das neue AX.25-Subsystem und die Programmierschnittstelle fertiggestellt ist. Zu deren Neuübersetzung siehe Bemerkung am Ende dieses Textes. Fakt ist weiterhin, daß der Kernel 2.2 höhere Speicheranforderungen als die 2.0.x-Reihe stellt. Da aber als PR-Rechner meistens ältere und weniger gut ausgestattete Systeme zum Einsatz kommen, ist ein Upgrade auch aus diesem Grunde nicht ratsam. Hinzu kommt noch die Tatsache, daß laut Alan Cox auch die Kernel der 2.0.x-Reihe weiterentwickelt werden sollen. Man kann sich also die Upgrade-Orgie noch etwas aufsparen (neben den neuen Kernelsourcen wird die Aktualisierung einiger anderer Programmpakete fällig) und abwarten, bis es beispielsweise Version 2.2.30 gibt. Nicht ohne Grund beobachtet man derzeit eine sehr rasche Folge neuer Versionen in der 2.2.x-Reihe. </article>