Das AX.25-Subsystem besteht nach dem im vorigen Abschnitt Gesagten aus drei Teilen:
Während man die beiden ersten Punkte im allgemeinen als Bestandteil des Kernel-Quelltextes findet, müssen die Konfigurationsprogramme und die Programmierschnittstelle in Form zusätzlicher Pakete installiert werden.
Man sollte möglichst einen aktuellen Kernel verwenden, da Probleme mit früheren Versionen hier beseitigt wurden und am wahrscheinlichsten mit einer unkomplizierten Funktion zu rechnen ist.
In einigen modernen Distributionen enthalten die mitgelieferten vorkompilierten Kernel bereits die Unterstützung für AX.25 oder es werden die passenden Treiber in Modulform mitgeliefert. Ein Beispiel hierfür ist die SuSE-Distribution in der aktuellen Version. Hier ist es nicht mehr unbedingt notwendig, sich einen neuen Kernel zu übersetzen.
Wie kann man prüfen, ob die Treiber bereits vorhanden sind? Für die allgemeine AX.25-Unterstützung reicht probeweises Eingeben von
insmod ax25
aus. Erhält man keine Fehlermeldung, kann man davon ausgehen, daß das
Modul geladen werden konnte, wovon man sich mit
lsmod
überzeugen kann.
Wer sich auf diese Art und Weise vom Vorhandensein der AX.25-Unterstüzung überzeugt hat, kann den folgenden Abschnitt überspringen und auf die eben beschriebene Art und Weise nachsehen, ob auch der Treiber für »seine« Hardware bereits in vorkompilierter Form vorliegt.
Nochmaliger Hinweis: Das Herunterladen und Neuübersetzen des Kernel-Quelltextes ist nicht mehr zwingend erforderlich, um die AX.25-Unterstützung unter Linux einzurichten. Man sollte in jedem Fall nachsehen, ob die erforderlichen Treiber nicht bereits mit der Distribution geliefert werden.
Den Quelltext der empfehlenswerten Kernel-Versionen 2.0.38 bzw.
2.2.14 findet man am sichersten auf dem nächsten Mirror von
http://www.kernel.org,
den man durch Einsetzen des Landes-Suffixes nach das www erhält;
für Deutschland wäre das
WWW.De.Kernel.Org, für Nutzer kommerzieller Onlinedienste
WWW.De2.Kernel.Org.
Auch FTP ist möglich, indem das »www« durch »ftp« ersetzt wird.
Die Quelltexte liegen dort unter /pub/linux/kernel/2.0 bzw.
/pub/linux/kernel/2.2.
Beim Übersetzen des Quelltextes kann angegeben werden, welche Funktionen in den Kernel integriert bzw. welche der im Quelltext enthaltenen Treiber verfügbar sein sollen.
Zunächst müssen die Kernelquellen entpackt werden.
Vor dem Entpacken sollte jedoch ein bereits bestehendes Verzeichnis
/usr/src/linux umbenannt werden:
cd /usr/src
mv linux linux.old
Die Quelltexte werden folgendermaßen entpackt:
cd /usr/src
tar -zxvf /tmp/linux-2.0.38.tar.gz
bzw.
cd /usr/src
tar -zxvf /tmp/linux-2.2.14.tar.gz
oder für den Entwicklerkernel:
cd /usr/src
tar -zxvf /tmp/linux-2.3.18.tar.gz
Dieser benötigt für das neueste AX.25-Subsystem noch einen Patch,
ax25-kernel-2.3.9-2.patch.gz, den man auf
ftp://ftp.hes.iki.fi/pub/ham/linux/ax25
finden kann. Der Patch wird mit
cd /usr/src/linux
zcat /tmp/ax25-kernel-2.3.9-2.patch.gz | patch -p1
installiert.
Nach erfolgreichem Entpacken bzw. Patchen ruft man das Konfigurationsskript auf.
Neben dem guten alten make config gibt es ein grafisches
Skript make xconfig, das jedoch neben einem installierten
X-Window-System auch ein Tcl/TK in einer halbwegs aktuellen Version
voraussetzt.
Gut bedienbar und auf den meisten Systemen funktionsfähig ist
make menuconfig, auf das sich im folgenden bezogen wird.
Es erscheinen in jedem Fall viele Konfigurationsoptionen, die man fest vorsehen (»y« für »yes«), als Modul laden (»m« für »module«) oder abwählen (»n« für »no«) kann.
Folgende Optionen sind für AX.25 wichtig:
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)
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
...
Für Kernel 2.2.x zusätzlich:
Networking Options
[*] Packet socket (CONFIG_PACKET)
Mit [*] markierte Optionen müssen eingeschaltet (»y«) oder wenigstens
als Modul (»m«) vorgesehen werden, wenn die AX.25-Unterstützung gewünscht
wird, mit einem »[?]« markierte Einstellungen hängen von der zu verwendenden
Hardware ab und sind entsprechend auszuwählen. Die wichtigen Einstellungen
werden bei der Einrichtung der einzelnen Treiber nochmals beschrieben, so daß
man bei Unklarheiten zunächst den Abschnitt zu »seinem« Gerät durchlesen und
dann wieder an diese Stelle zurückkehren sollte. Siehe dazu auch die Anmerkung
zu KISS im Abschnitt
KISS.
Nach abgeschlossener Konfiguration sollte der Kernel kompiliert werden können.
Zuvor sollte man in jedem Fall /usr/src/linux/Documentation/CHANGES
lesen und sicherstellen, daß die dort angegebenen Pakete in passender Version
installiert sind!
Ist hier alles in Ordnung, übersetzt man den neuen Kernel mit
make dep
make clean
make zImage
Man kann die make-Befehle auch auf eine Zeile schreiben, damit sie
nacheinander selbständig ablaufen:
make dep && make clean && make zImage
Das hat gegenüber der früheren Empfehlung
make dep clean zImage
den Vorteil, daß bei Auftreten eines Fehlers und folgendem Abbruch eines Befehls gestoppt und nicht etwa mit den folgenden Kommandos weitergemacht wird, was dann zusätzliche Probleme bringen könnte.
Wurde der Kernel erfolgreich compiliert, kann man ihn dorthin bringen, wo er hin muß:
cat /usr/src/linux/arch/i386/boot/zImage > /vmlinuz
Wer Lilo installiert hat, muß diesen starten:
lilo
Auf diese Weise erkennt Lilo, daß ein neuer Kernel installiert wurde und
bootet diesen beim nächsten Neustart. Ein
make zlilo
an Stelle von
make zImage
automatisiert die Schritte zImage, Kernelkopie und Lilo-Installation. Da
hierbei gleichzeitig die Datei /System.map 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.
Erscheint beim Kompilieren eine Fehlermeldung wie
make tools/build bootsect setup compressed / vmlinux.out CURRENT > zImage
Root device is (3,6)
Boot sector 512 bytes
Setup is 4392bytes
System is 552kB
System is too big
make[1]: ***[zImage] Error 1
make[1]: leaving directory '/usr/src/linux/arch/i386/boot'
make: ***[zImage] Error 2
muß entweder durch Verändern der Einstellungen in der Kernelkonfiguration (Treiber als Module vorsehen) der Kernel kleiner gemacht oder mit
make bzImage
bzw.
make bzlilo
kompiliert werden.
Vor einem erneuten Übersetzungsversuch ist es jedoch ratsam, das Quelltextverzeichnis mit
make clean
bzw.
make mrproper
aufzuräumen und alle Punkte, von der Kernel-Konfiguration beginnend, nochmals zu überprüfen und schrittweise erneut abzuarbeiten.
In diesem Zusammenhang fällt ein kleiner Fehler beim Kernel
2.2.14 auf. Auch wenn make keine Fehlermeldung ausgibt,
kann es vorkommen, daß lilo die Installation eines neuen
Kernels mit der Begründung
»Image too big« ablehnt. Auch hier hilft nur ein
make bzlilo
weiter, das bei diesem Kernel allerdings problemlos ohne zwischenzeitliches
make clean
unmittelbar nach Auftreten der Fehlermeldung eingegeben werden
kann.
Weitere Informationen zu diesem Thema gibt das Kernel HOWTO, das viele Aspekte berücksichtigt, die in diesem Dokument nicht dargestellt werden können.
Wer seinen Kernel mit einem Patch auf die aktuelle Version bringen will, sollte nach dem Patchen
(cd usr/src/linux; zcat /pfad/zum/patch-x.x.x.gz | patch -p1)
das Quelltextverzeichnis mit einem
find /usr/src/linux -name *.orig | xargs rm
aufräumen. Ein
find /usr/src/linux -name *.rej -print
sollte ohne Ausgaben bleiben, sonst ist mit dem Patch etwas schiefgelaufen.
Treiber als Module auszulegen, bringt neben einem kleineren Kernel (siehe auch
vorigen Abschnitt) viele weitere
Vorteile. Module können zur Laufzeit geladen und wieder entladen werden. Man
spart mit dem Laden nur der benötigten Module Speicher und vermeidet Konflikte
zwischen auf gleiche Ressourcen zugreifenden Treibern (Beispiel: sound
und soundmodem). Außerdem kann man verschiedene Einstellungen für die
Treiber probieren. Schließlich kann das Laden und Entladen der Module durch
den kerneld automatisiert werden.
Weitere Informationen findet man im Module-HOWTO, das zur Zeit leider nicht betreut wird.
Die besonders Einsteiger abschreckende Einrichtung der Module gestaltet sich
einfach, wenn man einige mögliche Fallstricke beachtet. Das korrekte
Funktionieren der Module hängt von passenden Einträgen in der Datei
System.map 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 System.map
als auch durch ein nicht aktualisiertes Modul-Verzeichnis hervorgerufen
werden. Im ersteren Fall hilft das Kopieren der passenden System.map
nach /. In letzterem Fall sollte man das Verzeichnis
/lib/modules/`uname -r` leeren und die Module noch einmal neu
erstellen und installieren:
cd /usr/src/linux
make modules
modules_install
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
depmod -a
Weiterhin ist es notwendig, einige Einträge in der Datei
/etc/conf.modules
hinzuzufügen, damit die Module im Bedarfsfall durch den kerneld
automatisch geladen werden können.
Der kerneld muß dafür gestartet sein, ein
ps fax | grep kerneld
sollte das auch anzeigen.
Hier also ein Beispiel:
#/etc/conf.modules
#
# Konfigurationsdatei für den kerneld
#
# WICHTIG: Alle genannten Treiber müssen als gleichnamige
# Module in /lib/modules/`uname -r` 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 Anwender 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
Diese Datei ist ein recht ausführliches Beispiel; Treiber, die man nicht verwendet, brauchen hier natürlich nicht eingetragen zu werden.
Insbesondere diejenigen, die BayCom- oder SoundModems verwenden wollen, sollten die entsprechenden Treiber als Module vorsehen. Dazu folgen später noch weitere Erklärungen.
Bevor die Hardwaretreiber eingerichtet werden, sollte man die AX.25-Utilities installieren, da sie einige spezielle Konfigurationsprogramme und Software zum Testen enthalten.
Wie bereits erwähnt, gibt es unterschiedliche Entwicklungsstufen des AX.25-Subsystems mit dafür angepaßter Software.
Dieses, bis zum Kernel 2.0.35 verfügbare System enthielt veraltete und zum Teil fehlerhafte Treiber. Es konnte durch einen Patch auf einen aktuelleren Stand gebracht werden und wird hier nur der Vollständigkeit halber erwähnt.
Es handelt sich hier um das System, das sich mit einer Kernel-Version
von 2.0.35 bis 2.0.38 einrichten läßt. Ältere Kernel erforderten den
ax.25-modules-14f-Patch, um auf diesen Stand gebracht zu werden.
Hierfür wurden die AX.25-Utilities 2.1.42a entwickelt.
Die Neustrukturierungen im Kernel 2.2.x haben auch vor dem AX.25-Subsystem nicht halt gemacht. In der Folge machte sich die Entwicklung neuer Software für diesen Kernel erforderlich, da die älteren Programme nicht mehr vollständig funktionierten. Diese Software ist noch sehr neu und konnte deshalb noch nicht ausgiebig getestet werden. Es können also unvorhersehbare Effekte oder Funktionseinschränkungen auftreten.
Wer sich dennoch entschließt, dieses System zu installieren, sollte stets nach neuen Softwareversionen Ausschau und sich über Änderungen auf dem laufenden halten.
Für Kernels der neuen Entwickler-Reihe in der Version ab 2.3.9 ist ein völlig neu geschriebenes AX.25-Subsystem verfügbar, bei dem vor allem Wert auf gesteigerte Performance im Zusammenhang mit TCP/IP gelegt wurde.
Weitere Informationen und entsprechende Software zum Download gibt es auf
http://dl0td.afthd.tu-darmstadt.de/~dg2fef/ax25.html
Der aktuellste Stand kann derzeit unter
http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html
abgerufen werden.
Dieses Paket wurde jetzt für den Kernel 2.2.14 verfügbar gemacht, eine Installationsanleitung findet man im Abschnitt Das aktuelle DG2FEF-AX.25-Subsystem
Diese Version wurde für das in den Kernelversionen 2.0.35 bis 2.0.38
enthaltene AX.25-Subsystem entwickelt. Wer einen älteren Kernel
einsetzt, muß vor dem Übersetzen eines neuen Kernels einen Patch
(ax25-module-14f) einspielen.
Das Quelltextarchiv ax.25-utils-2.1.42a.tar.gz ist
ausschließlich für Kernel 2.0.35 bis 2.0.38
(ältere mit Patch) gedacht, die auf libc5-basierten Systemen laufen.
ls -l /lib/libc*
zeigt, welche libc installiert ist.
Zu finden ist es beispielsweise auf:
ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/
ftp://ftp.pspt.fi/pub/linux/ham/ax25/
oder bei metalab:
http://sunsite.unc.edu/pub/Linux/apps/ham/ax25/
Ältere Versionen sollten nicht eingesetzt werden.
Wer ein libc6/glibc-basiertes System benutzt und keines der im
nächsten Abschnitt vorgestellten Binärpakete installieren will, findet in dem
Archiv ax25-utils-2.1.42a.glibc.tar.gz auf
ftp://sun01.idf.uni-heidelberg.de/pub/ax25/
die Quelltextversion der AX.25-Utilities, die sich unter
libc6/glibc übersetzen lassen sollte.
Die Utilities werden folgendermaßen installiert:
cd /usr/src
tar -zxvf /tmp/ax25-utils-2.1.42a.tar.gz
cd ax25-utils-2.1.42a
make config
make
make install
Debian-Nutzer müssen vorher die Verzeichnisse
/usr/include/asm und /usr/include/linux
umbenennen und an ihrer Stelle Links auf den Kernel-Quelltext legen:
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
Man sollte in diesem Zusammenhang kontrollieren, daß
/usr/src/linux/include/asm ein Link auf
asm-i386 ist.
Die Dateien werden in die Verzeichnisse /usr/bin,
/usr/sbin und /usr/man installiert.
Werden die AX.25-Utilities zum allerersten Mal installiert, d.h., befanden sich noch nie vorher auf dem System, dann installiert der Befehl
make installconf
einige Beispiel-Konfigurationsdateien unter /etc/ax25,
die als Grundlage für die eigene Konfiguration dienen können.
Erscheinen Bildschirmmeldungen wie
gcc-Wall -Wstrict-prototypes -o2 -I../lib -c call.c
call.c: In function `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)
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
make installib
korrekt installieren.
Diese vorkompilierte Version wurde für alle Benutzer libc6-basierter
Systeme mit Kernel 2.0.35 bis 2.0.38 (ältere wiederum mit
Patch) entwickelt, um dem Anwender den hier problematischen Kompiliervorgang
zu ersparen.
Zu finden ist diese Version auf:
ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/packages/libc6/rpm
Wichtig ist hierbei, sowohl die Programme
(ax25-utils-2.1.42a-3.i386.rpm) als auch die Bibliotheken und
Headerdateien (ax25-utils-devel-2.1.42a-3.i386.rpm
zu installieren, damit auf dem
AX.25-Subsystem aufbauende Software kompiliert werden kann.
Vorkompilierte Pakete für die Slackware finden sich auf
ftp://sharon.esrac.ele.tue.nl/pub/linux/slackware-current/contrib/ham/
Diese Pakete funktionieren nur unter Slackware 5.x beta oder höher (glibc2-
basiert), sie sind nicht mit älteren Slackware-Versionen einsetzbar.
Benutzer der Slackware 4 und älter finden vorkompilierte und mit pkginstall
installierbare Pakete unter
ftp://sharon.esrac.ele.tue.nl/pub/linux/slakware/ham/
als
ax25util.tgz, z8530drv.tgz, xforms.tgz.
Die aktuelle Slackware 7.0 enthält auch passende vorkompilierte Pakete. Unter der oben angegebenen Adresse finden sich Aktualisierungen und Verbesserungen zu den Slackware-Paketen.
Dem Debian-Archiv
ax25-utils_2.1.42a-6.deb
fehlt auf Grund einer Fehlinformation der Verantwortlichen (man nahm
Lizenzprobleme an) das Programm smdiag, so daß es nur für diejenigen
geeignet ist, die kein SoundModem verwenden möchten.
Die Pakete werden über den Paketmanager der jeweiligen Distribution oder einfach mit
rpm -i paketname
eingespielt.
Speziell für modernere, auf Kernel 2.2.x und libc6/glibc 2.1
basierende Systeme wurden die AX.25-Utilities und die Programmierschnittstelle
neu geschrieben. Betreuer und Hauptverantwortlicher für diese Version ist
Craig Small
(csmall@scooter.eye-net.com.au, csmall@eye-
net.com.au, csmall@debian.org, csmall@ieee.org).
Diese Version der AX.25-Utilities funktioniert bis auf die Programme
listen, ax25rtd und ax25ipd auch mit der neuesten Version
des AX.25-Subsystems von Matthias Welwarsky, DG2FEF,
matze@stud.fbi.fh-darmstadt.de,
dg2fef@afthd.tu-darmstadt.de.
Sobald Patches zur Beseitigung dieses Problems verfügbar werden, sollte
http://dl0td.afthd.tu-darmstadt.de/~dg2fef/ax25.html
darüber informieren.
Da sich sowohl Software als auch Bibliotheken der Version 0.0.x in stetiger Weiterentwicklung befinden, wurde das Paket in die Bestandteile
aufgeteilt, die zur Installation dieser Version vollständig benötigt werden. Sie können beispielsweise von
ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/
heruntergeladen werden, wobei man auf aktuelle Versionen (höchste Versionsnummer) achten sollte.
Weitere Informationen liefert
http://www.eye-net.com.au/hamradio/
.
Vorausgesetzt wird ein installiertes XFree86, zumindest aber die
Bibliothek libX11, da sich sonst das Programm smdiag nicht
compilieren läßt.
Die neue Version der AX.25-Utilities wird installiert, indem die drei Archive
in das Verzeichnis /usr/src entpackt und von dort aus installiert
werden:
cd /usr/src
tar -zxvf archivname
cd {archivname ohne die Endung .tar.gz}
./configure
make install
Zunächst sollte libax25 eingerichtet werden, da diese Voraussetzung
für die Übersetzung der beiden anderen Pakete ist. Hierzu kann nach
erfolgtem make install das Programm ldconfig verwendet werden.
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.
Im Fall der AX.25-Utilities Version 0.0.x sollte man immer die aktuellste Version installieren (höchste Versionsnummer der Archive), da es immer noch Verbesserungen und Fehlerbeseitigungen gibt. Da deren Entwicklung noch andauert, empfiehlt es sich, an den oben angegebenen Stellen regelmäßig nach neuen Versionen zu suchen.
Von Matthias Welwarsky (DG2FEF) stammt ein komplett neu geschriebenes AX.25-Subsystem, das ursprünglich für die Entwicklerkernels ab 2.3.9 vorgesehen war, nun aber auch mit dem Kernel 2.2.14 genutzt werden kann. Es ist in Form eines Kernel- Patches unter http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html verfügbar. Ebenso wurden die AX.25-Applikationen, Tools und die libax25 angepaßt und sind von der genannten Adresse herunterladbar.
Hinweis:
Diese Software befindet sich noch in Entwicklung, es kann Probleme durch Fehler oder noch nicht unterstützte Funktionen geben!
Das betrifft vor allem die Hardwaretreiber für
Diese Treiber dürfen nach Anwendung des Kernel-Patches nicht zur Kompilierung ausgewählt werden, da sonst die Kernel-Übersetzung fehlschlagen würde!
Eine Neuerung betrifft den allgemeinen Kernel-AX.25-Treiber: Er funktioniert nur, wenn folgende Optionen für die Kernel-Kompilierung angegeben wurden:
Networking Options
<*> Packet Socket
[*] Kernel/User netlink socket
Diese Optionen sind für die Verwendung des ax25rtd wichtig.
Wie bei der Version 0.0.x der AX.25-Software werden auch hier die Bibliotheken, die Tools und die Applikationen benötigt, die als drei getrennte Archive von http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html heruntergeladen werden können.
Zunächst ist die AX.25-Bibliothek zu installieren:
cd /usr/src
tar -zxvf /tmp/libax25-kjd-1-0.0.7.tar.gz
cd libax25-kjd-1-0.0.7
./configure
make
make install
ldconfig
Die Bibliothek wird unter /usr/local/lib installiert;
bei einigen Distributionen (z.B. Caldera OpenLinux) muß dieses
Verzeichnis zusätzlich in /etc/ld.so.conf eingetragen
werden, bevor man ldconfig ausführt.
Nachdem die Bibliothek nun installiert ist, kann man Applikationen und Tools einrichten:
cd /usr/src
tar -zxvf /tmp/ax25-tools-kjd-1-0.0.5.tar.gz
cd ax25-tools-kjd-1-0.0.5
./configure
make
make install
cd /usr/src
tar -zxvf /tmp/ax25-apps-kjd-1-0.0.5.tar.gz
cd ax25-apps-kjd-1-0.0.5
./configure
make
make install
Auf einigen Distributionen gibt es Probleme mit der Einbindung
von ncurses. Hier sollte man neben der Installation einer
aktuellen ncurses - Version (ab 4.2) nachsehen, ob die
Datei /usr/include/curses.h existiert. Ist dies der
Fall, erscheinen
jedoch trotzdem Fehlermeldungen wie
Making all in call
make[2]: Entering directory `/usr/src/ax25-apps-kjd-1-
0.0.4/call' /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o
call call.o menu.o crc.o yapp.o dostime.o -lax25 gcc -g -O2 -
Wall -o call call.o menu.o crc.o yapp.o dostime.o -lax25
call.o: In function `statline':
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:342: undefined reference to `stdscr'
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:342: undefined reference to `wmove'
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:343: undefined reference to `stdscr'
/usr/src/ax25-apps-kjd-1-0.0.4/call/call.c:343: undefined reference to `wattr_on'
...
make: *** [all-recursive-am] Error 2
sollte man ncurses dennoch neu installieren und danach
erneut ./configure aufrufen. Die eben beschriebenen
Probleme traten nur unter Caldera OpenLinux 2.3 auf, sie ließen
sich unter Slackware 7 bzw. SuSE 6.3 nicht nachvollziehen.
Nachdem die Programme installiert sind, sollte der Neuerung, die
Konfigurationsdateien unter /usr/local/etc/ax25
abzulegen, Rechnung getragen werden, indem man einen Link
anlegt:
mkdir /usr/local/etc/ax25
cd /etc
ln -s /usr/local/etc/ax25 ax25
Damit wahrt man Kompatibilität mit älterer Software und trägt
gleichzeitig der Tatsache Rechnung, daß einige der neuen
Programme bei der Wahl des Verzeichnisses für die
Konfigurationsdateien nicht konsequent sind und diese teilweise
von /etc/ax25 lesen wollen.
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 ifconfig {Devicename} {IP-Adresse}:
ifconfig bcsf0 44.136.8.5 netmask 255.255.255.0 up
Dieser Befehl muß in entsprechender Form für jedes neu eingerichtete Netzwerkdevice ausgeführt werden.
Eine weitere Besonderheit betrifft das Programm call, wenn
es mit dem neuen AX.25-Subsystem von DG2FEF verwendet wird. Es
ist hier in jedem Fall notwendig, mit
axparms -route add bcsf0 VK1SUT
eine neue AX.25-Route zum Zielrufzeichen zu setzen (für bcsf0
ist freilich das zu verwendende Device und für VK1SUT das
gewünschte Zielrufzeichen einzusetzen). Ohne diese Einstellung
funktioniert call nicht. Möglicherweise wird dieses Problem
in späteren Versionen wieder behoben.
Nachdem neuer Kernel und passende AX.25-Utilities installiert sind, kann man nun zur Einrichtung der Hardware übergehen. Die meisten Treiber sind mittlerweile Bestandteil des Kernel- Quelltextes; viele Autoren bieten jedoch weiterentwickelte Versionen ihrer Treiber an. Einige Treiber für neue Hardware sind noch nicht im Kernel enthalten.
Die in den Beispielen angegebenen Rufzeichen sind selbstverständlich durch das eigene Rufzeichen zu ersetzen.
Für die call-Aufrufe verwendet man
das Rufzeichen einer benachbarten, gut erreichbaren Station, zu
der man sicher Verbindungen aufbauen kann.
Wohl am häufigsten eingesetzt werden KISS-TNCs oder KISS-
kompatible Geräte an einer seriellen Schnittstelle. Viele Exoten
lassen sich so nutzen, indem man sie einfach in den KISS-Modus
versetzt.
Das geschieht mit einem Terminalprogramm wie
minicom oder seyon,
für den TNC2 reicht es, mit
echo -e "\33@K" > /dev/ttyS0
den entsprechenden Befehl direkt an die Schnittstelle zu schicken.
(Für /dev/ttyS0 ist selbstverständlich die Schnittstelle
einzusetzen, an die der TNC angeschlossen ist.)
Mit
kissparms -p /dev/ttyS0 -x
kann man den TNC2 wieder zurück in den Terminalmode schalten.
Optionen bei der Kernel-Compilierung:
General Setup
[*] Networking support
Network Device Support
[*] Network Device Support
...
[*] Radio network interfaces
...
[*] Serial port KISS driver for AX.25
Selbstverständlich kann KISS auch als Modul vorgesehen und nur bei
Bedarf geladen werden.
Ein KISS-TNC kann dann folgendermaßen ins System eingebunden werden:
insmod mkiss
kissattach -i 44.130.56.160 -m 255 /dev/ttyS0 kiss1
Das erzeugt ein Netzwerkdevice ax0 für einen an /dev/ttyS0 (COM1)
angeschlossenen TNC. Diese Devices erhalten die Namen ax0 - ax9.
Beim ersten Aufruf erzeugt kissattach
ax0, beim zweiten ax1 usw.
Der Zugriff auf das KISS-Device gescheiht über den angegebenen AX.25-Port »kiss1«,
der zuvor in /etc/ax25/axports definiert sein muß:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
kiss1 VK2KTJ 1200 255 1 KISS-TNC an COM1
Jedes KISS-Gerät entspricht genau einem Netzwerkdevice.
Erscheint die Fehlermeldung:
kissattach: TIOCSETD: Invalid argument
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 eincompiliert werden (CONFIG_MKISS=»y« in
/usr/src/linux/config), wenn die AX-25-Unterstützung (siehe Abschnitt
Kernel übersetzen)
ebenfalls fest einkompiliert wurde.
Andernfalls muß er als Modul kompiliert werden, oder die Erstellung des neuen Kernels würde fehlschlagen.
Verwendet ein Programm den Eintrag »kiss1« mit dem für den KISS-TNC vergebenen Rufzeichen, so wird das KISS-Netzwerkdevice angesprochen.
Ein einfacher Test wäre der Aufbau einer Verbindung zu einer anderen Station
mit dem Programm call:
call kiss1 VK2SUT
Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt
sich für TCP/IP einrichten, man kann es der ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Mit kissparms lassen sich verschiedene Parameter des
KISS-Netzwerkdevice
einstellen.
Das oben dargestellte Beispiel erzeugt ein KISS-Device, welches die erste
serielle Schnittstelle und den Eintrag »kiss1« in der Datei
/etc/ax25/axports nutzt.
Mit
kissparms -p kiss1 -t 100 -s 100 -r 25
wird es beispielsweise auf ein TXDelay und eine Slottime von 100 Millisekunden und einen Persistence-Wert von 25 eingestellt.
Weitere Informationen geben die Hilfeseiten der einzelnen Programme.
Das den AX.25-Utilities beiliegende Programm mkiss 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ß vor der AX.25-Konfiguration der beiden Ports durchgeführt werden.
Die Geräte, die dann einzurichten sind, sind Pseudo-TTY-Interfaces,
(/dev/ttyq*) 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 /dev/ptyq*,
die »Slave«-Enden /dev/ttyq* . Jeder Master hat einen Slave,
/dev/ptyq0 ist also der Master einer Pipe, deren Slave /dev/ttyq0 ist.
Man muß das »Master«-Ende einer Pipe vor dem »Slave«-Ende öffnen.
mkiss nutzt diesen Mechanismus, um ein einzelnes serielles Device auf
mehrere virtuelle Devices aufzuteilen.
Beispiel: Hat man einen Dual-Port-TNC an eine serielle Schnittstelle
/dev/ttyS0 mit 9600 bps angeschlossen, erzeugen die Befehle
/usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
/usr/sbin/kissattach /dev/ttyq0 port1
/usr/sbin/kissattach /dev/ttyq1 port2
zwei Pseudo-TTY-Devices, die beide wie ein normaler Single-Port-TNC erscheinen.
Nun lassen sich /dev/ttyq0 und /dev/ttyq1 wie serielle
Schnittstellen mit daran angeschlossenen konventionellen KISS-TNCs behandeln.
Das heißt, man verwendet kissattach wie oben beschrieben,
für die AX.25-Ports »port1« und »port2«, die entsprechend in der
Datei /etc/ax25/axports eingerichtet sein müssen.
Auf die serielle Schnittstelle selbst kann kein kissattach angewendet
werden, da mkiss diese ja bereits nutzt. Der Befehl mkiss kennt
einige Optionen:
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.
<Baudrate> stellt die Baudrate der seriellen Schnittstelle ein.
schaltet den Hardware-Handshake ein (Voreinstellung: Aus). Wird von den meisten KISS-Implementationen nicht unterstützt.
schaltet eine Mitschrift (logging) in die syslog-Logdatei ein.
Thomas Sailer (sailer@ife.ee.ethz.ch) entwickelte einen Linux-Treiber
für BayCom- und BayCom-ähnliche Modems. Er unterstützt die seriellen (ser12),
parallelen (par96) und PicPar-Modems. Informationen über diese Modems
erhält man auf der WWW-Seite des BayCom-Teams
(
http://www.baycom.de).
In Kernel 2.2.x gibt es zusätzlich Treiber für das EPP-Modem (noch in Entwicklung).
Folgende Optionen zur Kernel-Compilierung sind wichtig:
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
Wer für die parallele Schnittstelle entwickelte Baycom-Modems nutzen will (picpar, EPP) benötigt das Parport-Modul:
[*] Support for parallel port devices
Empfehlenswert für erste Tests ist die Übersetzung des Treibers als Modul.
Bevor man den Treiber installiert, sollte man sich vergewissern, welche Schnittstelle für das Modem verwendet wird. Wichtig sind I/O-Adresse und IRQ. Beispiel:
insmod baycom
sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4
Diese Befehle laden das BayCom-Modul und stellen es für ein an COM1
angeschlossenes Modem ein. Wenn der Treiber geladen wurde, erzeugt er ein
Netzwerk-Device mit Namen bc0. Wird er ein zweites Mal für ein weiteres
Modem geladen, erzeugt er ein Netzwerk-Device bc1. Insgesamt sind vier
Devices bc0 bis bc3 möglich.
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:
Folgende Treiber sind verfügbar:
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!)
Anstelle von »insmod baycom« schreibt man also
insmod baycom_ser_fdx
und konfiguriert bcsf0 statt bc0.
Beispiel:
insmod baycom_ser_fdx
sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4
Ausführlichere Informationen zu den neuen Treibern können in der
Datei
/usr/src/linux/Documentation/networking/baycom.txt
nachgelesen werden.
Die Parameter der verwendeten Schnittstelle können mit dem Utility
sethdlc eingestellt werden, hat man nur ein BayCom-Modem installiert, so
kann man die Parameter auch auf der Kommandozeile für insmod angeben,
wenn der als Modul eingerichtete Treiber geladen wird.
Zunächst wird der normale serielle Treiber für die erste
Schnittstelle /dev/ttyS0 (»COM1«) abgeschaltet, dann der
BayCom-Treiber für ein serielles 1200-Baud-Modem an
/dev/ttyS0 (»COM1«) eingerichtet und die Software-DCD
eingeschaltet:
setserial /dev/ttyS0 uart none
insmod hdlcdrv
insmod baycom mode="ser12*" iobase=0x3f8 irq=4
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 baycom_ser_fdx
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
setserial-Zeile des Beispiels einfügen:
setserial /dev/ttyS0 uart 16550A skip_test
Weiterhin stören 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 rmmod entfernt werden kann:
rmmod lp
Hinweis:
Der in neueren Kerneln enthaltene parport-Treiber ist für die Funktion
der neuen EPP- und Parallelport-Modems notwendig. Er sollte jedoch auch entfernt
werden, wenn ein klassisches BayCom-Modem zu Einsatz kommen soll.
Das komplette Skript sieht dann etwa so aus:
#!/bin/sh
rmmod lp
/sbin/setserial /dev/ttyS0 uart 16550A skip_test
sleep 3
/sbin/setserial /dev/ttyS0 uart none
insmod hdlcdrv
insmod baycom mode="ser12*" iobase=0x3f8 irq=4
Damit sollte der Treiber funktionieren, was man mit sethdlc -d
einfach nachprüfen kann. Der Wert hinter »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 sethdlc
braucht das Modem nicht angeschlossen zu sein.
Ein Par96-Modem am Parallelport LPT1 mit Hardware-DCD richtet man so ein:
insmod parport
insmod hdlcdrv
insmod baycom_par mode="par96" iobase=0x378 irq=7 options=0
Die Optionen lassen sich auch nachträglich mit sethdlc einstellen,
das sich auch für mehrere Modems einsetzen läßt. In der Hilfeseite (»man
sethdlc«) findet man alle Details, einige Beispiele sollen diesen Aspekt hier
verdeutlichen. Es wird angenommen, das BayCom-Modul ist mit
insmod hdlcdrv
insmod baycom
bereits geladen oder als Treiber in den Kernel eincompiliert. Man kann
das Netzwerk-Device bc0 nun einrichten:
sethdlc -p -i bc0 mode par96 io 0x378 irq 7
sethdlc -p -i bc0 mode "ser12*" io0x3f8 irq 4
Mit sethdlc lassen sich die AX.25-Kanalzugriffsparameter
Persistence (ppersist), TX-Delay und slottime (TX-Wait)
für den BayCom-Treiber einstellen.
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:
sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
Alle Zeitwerte werden in Millisekunden angegeben.
Der BayCom-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar. Zunächst gibt man dem BayCom-Device ein Rufzeichen:
/sbin/ifconfig bc0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig bc0 up
axparms -setcall bc0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
BayCom hinzugefügt. Die Verbindung des Eintrags zum entsprechenden Netzwerk-
Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
BayCom1 VK2KTJ 1200 255 1 BayCom Modem COM1
Verwendet ein Programm den Eintrag BayCom1 mit dem für BayCom vergebenen Rufzeichen, so wird das BayCom-Device angesprochen.
Ein einfacher Test wäre der Aufbau einer Verbindung zu einer anderen Station
mit dem Programm call:
call BayCom1 VK2SUT
Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt
sich für TCP/IP einrichten, man kann es der ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Thomas Sailer (sailer@ife.ee.ethz.ch) entwickelte neben dem
BayCom-Treiber einen weiteren Treiber, mit dem man viele Soundkarten für
Packet-Radio nutzen kann. Diese originelle Idee funktioniert erstaunlich gut,
setzt allerdings ein Mindestmaß an Rechenleistung voraus.
Ein 486DX2/66 wird von Thomas Sailer als Minimalsystem angegeben.
Folgende Optionen bei der Kernel-Compilierung sind wichtig:
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 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
Wie die vorigen Treiber läßt sich auch SoundModem als Modul einrichten. 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.EXE.
Viele Soundkarten können auch mit Hilfe der isapnptools eingerichtet werden.
Hierzu erstellt man sich mit
pnpdump > config
eine Auflistung der von den installierten PNP-Karten unterstützten Einstellungen.
Die passenden Einstellungen werden dann durch Entfernen der Kommentarzeichen '#'
aktiviert; schließlich muß am Ende der Konfigurationsvorschläge für die Karte noch
ACT Ygesetzt werden. Anschließend kann man bei im Kernel vorhandenem PNP-Support diese Datei einfach als
/etc/isapnp.conf abspeichern; der Kernel liest sie beim Systemstart
automatisch aus und stellt die Karte entsprechend ein.
PCI-Soundkarten (z.B. SoundBlaster PCI64) werden derzeit noch nicht unterstützt!
Die Soundkarten benötigen eine kleine Zusatzschaltung zur Ansteuerung der PTT, Informationen dazu findet man auf Thomas' Soundmodem-PTT-Seite
http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html
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
http://www.ardos.de/gerd/tcm3105.html)
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 sm0,
sm1, sm2 usw., wenn er eingerichtet wurde. Beachte: 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 Treiber für die parallele Schnittstelle
nicht geladen sein. Natürlich lassen sich all diese als Module compilieren, so
daß sie mit insmod und 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:
(rmmod lp; rmmod parport)
insmod sound (evtl. Optionen)
sleep 3
rmmod sound
insmod hdlcdrv
insmod soundmodem (evtl. Optionen, dazu später)
Der SoundModem-Treiber initialisiert die Soundkarte nicht. In den AX.25-
Utilities ist zu diesem Zweck das Programm setcrystal enthalten, das
für Soundkarten mit dem Crystal-Chipset verwendet werden kann. Wer eine andere
Karte hat, muß andere Software zum Initialisieren verwenden.
Die Syntax von setcrystal:
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]
Will man eine SoundBlaster auf I/O-Adresse 0x388, IRQ 10 und DMA 1 einrichten, so verwendet man:
setcrystal -s 0x388 -i 10 -d 1
Ein Windows-Sound System konfiguriert man so auf IO-Adresse 0x534, IRQ 5, DMA 3:
setcrystal -w 0x534 -i 5 -d 3
Mit [-f synthio] kann man die Adresse des Synthesizers einstellen, mit [-c dma2] richtet man den zweiten DMA-Kanal für Vollduplexbetrieb ein.
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 sethdlc vorgenommen
werden, ebenso können die erforderlichen Parameter dem SoundModem-Modul auf
der insmod- Kommandozeile mitgegeben werden. Als Beispiel eine
einfache Konfiguration für eine SoundBlaster, die ein 1200bps-Modem emuliert:
insmod hdlcdrv
insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
Die Optionen für den Treiber können auch mit sethdlc, das sowohl mit
einer Karte als auch mit mehreren funktioniert, eingestellt werden. Zunächst
muß auch hier das Modul geladen
insmod hdlcdrv
insmod soundmodem
oder die SoundModem-Unterstützung in den Kernel eincompiliert sein.
Wir richten damit beispielsweise das im vorigen Abschnitt konfigurierte
Windows Sound System ein, daß es ein 9600-bps-FSK-Modem nach G3RUH als
Device sm0 emuliert und einen Parallelport an 0x378 zur Ansteuerung
der PTT nutzt:
sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
Die oben erwähnte SoundBlaster einrichten, daß sie als Device sm1 ein
4800 bps-HAPN-Modem emuliert und eine serielle Schnittstelle an 0x2f8 zur PTT-
Ansteuerung nutzt:
sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
...als 1200-bps-AFSK-Modem mit PTT über serielle Schnittstelle an 0x2f8:
sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
Die Konfiguration der Kanalzugriffsparameter erfolgt analog dem bei BayCom
Gesagten. Beispiel: Das Device sm0 soll ein TXDelay von 100ms, eine
Slottime von 50ms, eine Ppersist (Persistence) von 128 und Full-Duplex-Betrieb
fahren:
sethdlc -i sm0 -a txd 100 slot 50 ppersist 120 full
Alle Werte sind auch hier in Millisekunden anzugeben.
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 smdiag und smmixer. Smdiag bietet zwei
Anzeigearten, einmal als Oszilloskop, zum zweiten als Augenmuster an.
Mit smmixer kann man die aktuellen Sende-und Empfangspegel anzeigen.
smdiag im »Augen-Modus« für das SoundModem-Device
sm0 starten:
smdiag -i sm0 -e
smmixer wird für sm0 so gestartet:
smmixer -i sm0
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:
sunsite.unc.edu:/pub/Linux/apps/sound/mixers
- und stelle damit die Werte ein.
Günstig sind kommandozeilenorientierte Programme wie
cmix, da sie in das Startskript eingebunden werden können
und so immer die gleichen Einstellungen gegeben sind.
Thomas Sailer empfiehlt die Verwendung eines passenden
Mixerprogramms an Stelle von smmixer,
da die Entwicklung dieses Programms in naher Zukunft eingestellt wird.Es wird berichtet, daß auf manchen Systemen unterschiedliche Pegel für die verschiedenen verwendeten Töne an den Soundkarteneingang gelangen. Das muß gegebenenfalls durch Zwischenschalten von Filtern ausgeglichen werden.
Bei Stereo-Soundkarten sollte das empfangene Signal an beide Eingänge angelegt werden, ist das nicht möglich oder erwünscht, sollte der unbenutzte Eingang kurzgeschlossen und geerdet werden.
Leider findet man smdiag nicht mehr in den aktuellen AX.25-
Softwarepaketen; ältere Versionen funktionieren nicht mit den
aktuellen Treibern. Man benötigt also eine Alternative. Leider
ist mir momentan keine passende Software zur Lösung dieses
Problems bekannt.
Der SoundModem-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar.
Zunächst gibt man dem SoundModem-Device ein Rufzeichen:
/sbin/ifconfig sm0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig sm0 up
axparms -setcall sm0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
SoundModem hinzugefügt. Die Verbindung des Eintrags zum entsprechenden
Netzwerk-Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
Sound1 VK2KTJ 1200 255 1 Sound Modem Port
Verwendet ein Programm den Eintrag »Sound1« mit dem für SoundModem vergebenen
Rufzeichen, so wird damit das SoundModem-Device angesprochen. Ein einfacher
Test wäre der Aufbau einer Verbindung zu einer anderen Station mit
dem Programm call:
call Sound1 VK2SUTDas neue AX.25-Device kann nun ganz normal verwendet werden, es läßt sich für TCP/IP einrichten, man kann es der
ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Erscheinen Fehlermeldungen beim Aufruf von ifconfig sm0... wie
"no such device"
oder
"permission denied",
sollte man die Konfigurationsoptionen (I/O-Adresse, IRQ, DMA) nochmals
überprüfen und nachsehen, ob kein störender Treiber (sound,
lp) geladen ist.
David Perry (dp@hydra.carleton.edu) schrieb den Linux-Treiber für
PI/PI2-Karten. Diese Karten stellen ein Hochgeschwindigkeits-Interface als PC-
Einsteckkarte zur Verfügung. Weitere Informationen dazu findet man
beispielsweise auf
http://www.cnunix.com/tpk/wa4dsy/pi2.html
Folgende Optionen sind bei der Kernel-Compilierung wichtig:
General Setup
[*] Networking support
Network Device Support
...
[*] Radio network interfaces
...
[*] Ottawa PI and PI/2 support for AX.25
Der Treiber erzeugt Netzwerk-Devices mit den Namen pi0, pi1,
pi2 usw., wobei die erste PI-Karte als pi0 angesprochen wird, die
zweite als pi1 etc. Wurde der Treiber in den Kernel compiliert und hat
er die Karte korrekt erkannt, läßt er sich einrichten.
Der PI-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar.
Zunächst gibt man dem PI-Device ein Rufzeichen:
/sbin/ifconfig pi0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig pi0 up
axparms -setcall pi0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
PI-Karten hinzugefügt. Die Verbindung des Eintrags zum entsprechenden
Netzwerk-Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
Pi_card1 VK2KTJ 1200 255 1 PI-Karte 1
Verwendet ein Programm den Eintrag »Pi_card1« mit dem für PI vergebenen
Rufzeichen, so wird das PI-Device angesprochen. Ein einfacher Test wäre der
Aufbau einer Verbindung zu einer anderen Station mit dem Programm
call:
call Pi_card1 VK2SUTDas neue AX.25-Device kann nun ganz normal verwendet werden, es läßt sich für TCP/IP einrichten, man kann es der
ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Der PacketTwin-Treiber wurde von Craig Small
(csmall@triode.apana.org.au, csmall@debian.org,
csmall@scooter.eye-net.com.au, csmall@eye-net.com.au,
csmall@ieee.org) geschrieben.
Folgende Optionen sind beim Kernelcompilieren wichtig:
General Setup
[*] Networking support
Network Device Support
...
[*] Radio network interfaces
...
[*] Gracilis PacketTwin support for AX.25
Der Treiber erzeugt Netzwerk-Devices mit den Namen pt0, pt1,
pt2 usw., wobei die erste PacketTwin-Karte als pt0 angesprochen
wird, die zweite als pt1 etc.
Wurde der Treiber in den Kernel compiliert und hat er die Karte korrekt erkannt, läßt er sich einrichten.
Der PacketTwin-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar.
Zunächst gibt man dem PacketTwin-Device ein Rufzeichen:
/sbin/ifconfig pt0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig pt0 up
axparms -setcall pt0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
PacketTwin-Karten hinzugefügt. Die Verbindung des Eintrags zum entsprechenden
Netzwerk-Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
PTwin_card1 VK2KTJ 1200 255 1 PacketTwin-Karte 1
Verwendet ein Programm den Eintrag »PTwin_card1« mit dem für PacketTwin
vergebenen Rufzeichen, so wird das PacketTwin-Device angesprochen. Ein
einfacher Test wäre der Aufbau einer Verbindung zu einer anderen Station mit
dem Programm call:
call PTwin_card1 VK2SUTDas neue AX.25-Device kann nun ganz normal verwendet werden, es läßt sich für TCP/IP einrichten, man kann es der
ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Joerg Reuter, DL1BKE (jreuter@poboxes.com, lykos@gmx.net)
entwickelte die allgemeine Unterstützung für SCC-Karten. Sein Treiber ist für
eine Vielzahl Karten konfigurierbar und stellt ein Netzwerk-Device zur
Verfügung, so daß man die SCC-Karte wie eine Netzwerkkarte ansprechen kann.
Ältere Versionen des Treibers (bis 2.x) unterstützen sowohl die im folgenden bei den Kompilier-Optionen erwähnte KISS-Emulation (»/dev/scc*«) als auch die moderneren Netzwerkdevices.
Wichtige Optionen beim Kernel-Compilieren:
General Setup
[*] Networking support
Network Device Support
...
[*] Radio network interfaces
...
[*] Z8530 SCC KISS emulation driver for AX.25
Die KISS-Emulation der älteren Treiber sollte man nur noch in Ausnahmefällen
nutzen, da sie unvollständig und teilweise fehlerbehaftet ist.
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 auf
http://ftp.ccac.rwth-aachen.de/pub/jr/
Es gibt verschiedene Versionen, man muß sich die für seinen Kernel passende heraussuchen.
z8530drv-2.4c.dl1bke.tar.gz
z8530drv-utils-3.0.tar.gz (bzw. .rpm)
z8530drv-utils-3.0-2.tar.gz
Mit folgenden Befehlen läßt sich das Paket installieren:
cd /usr/src
gzip -dc /tmp/z8530drv-2.4c.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 eincompiliert werden soll)
make install
Nach dem erfolgreichen Compilieren sollten sich drei neue Programme im
Verzeichnis /sbin finden: gencfg, sccinit und sccstat.
Diese Programme dienen zur Einrichtung des Treibers für die SCC-Karte.
Der Treiber erzeugt Netzwerkdevices mit den Namen scc0 - scc7.
Hat man vorhin make for_kernel eingegeben, so muß der Kernel neu
compiliert werden. Die Option
[*] Z8530 SCC KISS emulation driver for AX.25
beim »Network Device Support« muß angegeben sein. Hat man sich entschieden,
den Treiber als Modul zu compilieren (»make module«), so wurde ein Modul
namens scc.o in das entsprechende Verzeichnis
/lib/modules/`uname -r`/net kopiert, welches mit
insmod geladen werden kann.
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 doc/scc_eng.doc bzw. doc/scc_ger.doc bieten
detailliertere Informationen, die nicht in diesem HOWTO enthalten sind.
Der aktuellste Stand ist auf Joerg Reuters Seite
Linux und Amateurfunk nachzulesen.
Das Programm sccinit liest die Datei /etc/z8530drv.conf 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 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.
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 scc.c die Zeile
#define MAXSCC 4
entsprechend anpassen. Erlaubte Schlüsselworte und Argumente:
wird verwendet, um die einzelnen Abschnitte voneinander zu trennen. Beliebige Argumente sind erlaubt, sie werden nicht verwendet.
Wird zur Angabe der Adresse des Datenports für den SCC-Kanal »A« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x300.
Wird zur Angabe der Adresse des Steuerports für den SCC-Kanal »A« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x304.
Wird zur Angabe der Adresse des Datenports für den SCC-Kanal »B« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x301.
Wird zur Angabe der Adresse des Steuerports für den SCC-Kanal »B« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x305.
Gibt den IRQ an, den der in diesem Abschnitt einzustellende Chip verwendet. Argument ist eine Integerzahl, wie 5.
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.
Der Typ der 8530-SCC-Karte. Folgende Werte sind erlaubt:
- die PA0HZP-SCC-Karte
- die EAGLE-SCC-Karte
- die PRIMUS-PC (DG9BL-)Karte
- die BayCom-(U)SCC-Karte
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«.
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 .
optional, gibt die Adresse eines speziellen Funktions- registers für manche Karten an. Voreinstellung: 0 .
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
Bei wem die Karte bereits unter NOS funktioniert, der kann die Treiber-Befehle
des PE1CHL-NOS-Treibers mit dem Befehl gencfg in eine für die
Konfigurationsdatei des Z8530-Treibers nutzbare Form bringen. gencfg wird
genau so wie für den PE1CHL-Treiber von NOS aufgerufen: Zum Beispiel erstellt
gencfg 2 0x150 4 2 0 1 0x168 9 4915200
eine Grundkonfiguration für die OptoSCC-Karte.
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 /etc/z8530drv.conf immer 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:
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. scc0.
Gibt die Übertragungsrate in Bits pro Sekunde an, muß ganzzahlig sein, z.B. 1200.
Gibt an, aus welcher Quelle der Datentakt stammt.
Erlaubte Werte sind:
normaler Halbduplexbetrieb
Das Modem hat einen eigenen Sende-/Empfangstakt
verwendet den Fullduplex-Teiler, wenn installiert
Gibt die zu verwendende Datenkodierung an. Mögliche Werte
sind nrz und nrzi.
Gibt die Anzahl der im Speicher zu reservierenden Empfangs- puffer vor. Der Wert ist ganzzahlig, z.B. 8.
Gibt die Anzahl der im Speicher zu reservierenden Sende- puffer vor. Der Wert ist ganzzahlig, z.B. 8.
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.
Das von KISS bekannte TXDelay, der Wert ist ganzzahlig und wird in Millisekunden angegeben.
Der Wert für die Persistence, ganzzahlig.
KISS-Slottime, ganzzahlig, in Millisekunden.
Der TXTail-Wert bei KISS, ganzzahlig, in Millisekunden.
Das bei KISS verwendete Fullduplex-Flag, Wert ist entweder 1 für Vollduplex oder 0 für Halbduplex.
Der Wait-Wert bei KISS, ganzzahlig, in Millisekunden.
Der Min-Wert bei KISS, ganzzahlig, in Sekunden.
Die maximale Sendezeit bei KISS ganzzahlig, in Sekunden.
Der Idle-Timer-Wert, ganzzahlig, in Sekunden.
Der Maxdef-Wert bei Kiss, ganzzahlig.
Der group-Wert bei KISS, ganzzahlig.
Der txoff-Wert bei Kiss, ganzzahlig, in Millisekunden.
Der Wert für SoftDCD (Software-Rauschsperre), ganzzahlig.
Das Slip-Flag bei KISS, ganzzahlig.
Bei der Fehlersuche kann das Programm sccstat helfen, indem
man damit die aktuelle Konfiguration eines SCC-Device anzeigen lassen kann.
Aufruf zum Beispiel mit:
sccstat scc0
Es werden viele Informationen zur Einstellung und Funktion des SCC-Ports scc0 angezeigt.
Mit dem Programm 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:
sccparam scc0 txtail 0x8
Der SCC-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar.
Zunächst gibt man dem SCC-Device ein Rufzeichen:
/sbin/ifconfig scc0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig scc0 up
axparms -setcall scc0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
SCC hinzugefügt. Die Verbindung des Eintrags zum entsprechenden
Netzwerk-Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
Scc-Karte1 VK2KTJ 1200 255 1 erste SCC-Karte
Verwendet ein Programm den Eintrag »Scc-Karte1« mit dem für SCC vergebenen
Rufzeichen, so wird das SCC-Device angesprochen. Ein einfacher Test wäre der
Aufbau einer Verbindung zu einer anderen Station mit dem Programm
call:
call Scc-Karte1 VK2SUT
Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt
sich für TCP/IP einrichten, man kann es der ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
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.
Folgende Optionen sind bei der Kernel-Compilierung wichtig:
General Setup
[*] Networking support
Network Device Support
...
[*] Radio network interfaces
...
[*] BPQ Ethernet driver for AX.25
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 bpq1 bis bpq9. Das
Device bpq0 gehört zu eth0, bpq1 zu eth1 usw..
Die Konfiguration ist sehr offen.
Zunächst muß das Ethernet-Device (die Netzwerkkarte) eingerichtet sein.
Das heißt, der Kernel muß mit Ethernet-Unterstützung kompiliert sein und diese muß auch funktionieren. Im Ethernet HOWTO findet man dazu weiterführende Informationen.
Um die BPQ-Unterstützung einzurichten, muß das BPQ-Ethernet-Device mit einem Rufzeichen versehen werden:
/sbin/ifconfig bpq hw ax25 VK2KTJ up
Beachte, daß das Rufzeichen mit dem Rufzeichen in der Datei
/etc/ax25/axports übereinstimmt, das für diesem Port gelten soll.
BPQ verwendet normalerweise sogenannte Multicast-Adressen. Die Linux-
Implementation macht das nicht, sie verwendet stattdessen die normale Ethernet
Broadcast Address. Deshalb sollte die Datei NET.CFG für den
BPQ-ODI-Treiber wie folgt geändert werden:
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
Eine noch recht neue, interessante Entwicklung stellt das YAM (Yet Another Modem) dar, das auf der Basis des Bausteins Xc5202 von Xilinx arbeitet. Das wie ein BayCom-Modem einfach an die serielle Schnittstelle anzuschließende und auch von dieser gespeiste Modem unterstützt die Betriebsarten AFSK 1200 bps, Manchester FSK 2400 bps und FSK 9600 bps nach G3RUH-Standard. Weitere Informationen gibt es auf
http://jupiter.web-hosting.com/~nicopal/yam/
oder
http://www.microlet.com/yam/
Jean-Paul Robelat, F6FBB und Frederic Rible, F1OAT, entwickelten den aktuellen Linux-Treiber, der sich sowohl für Kernels ab 2.0.36 als auch für 2.2.x einsetzen läßt und von
http://www.teaser.fr/~frible/yam.html
bezogen werden kann. Er wird in das System in Form eines Kernel-Patches einbezogen.
Der Kernel-Patch wird so installiert:
cd /usr/src
tar -zxvf /{pfad}/yamdrv-0.8.tar.gz
make all
Für Kernel 2.0.35 bis 2.0.38:
cat /usr/src/yamdrv/yam08-2.0.36-patch.diff | patch -p0
Für Kernel 2.2.x:
cat /usr/src/yamdrv/yam08-2.2.1-patch.diff | patch -p0
Anschließend ruft man im Verzeichnis /usr/src/linux
make menuconfig
auf und konfiguriert das YAM, dessen Einstellmöglichkeiten unter
Network Device Support
[*] Network Device Support
...
[*] Radio network interfaces
liegen sollten.
Zur Konfiguration des Treibers wurden die Programme yamcfg und
mcs2h entwickelt, die nach Auspacken des Treiberarchivs und
make all
im Verzeichnis /usr/src/yamdrv liegen und nach
/sbin kopiert werden sollten. Im Treiberarchiv sind Beispielskripts
start und stop enthalten, die nach Bedarf modifiziert werden
können.
yamcfg kennt folgende Optionen:
- I/O-Adresse der verwendeten seriellen Schnittstelle
- IRQ der verwendeten seriellen Schnittstelle
- Bit-Rate
- Transferrate (1200, 2400, 9600 Baud)
- Voll- oder Halbduplex
- Hold-Verzögerung
- TX-Delay (Zeit zwischen Auftasten des Senders (PTT) und Beginn der Datenaussendung)
- TX-Tail (Zeit zwischen Ende der Datenaussendung und Abschalten des Senders (PTT))
- Slot-Time (entspricht W bei TNC2)
- Persistenz, Sendewahrscheinlichkeit (entspricht P bei TNC2)
- Zu einer bestimmten Bitrate eine vorkonfigurierte MCS-Datei laden
Nicht alle Parameter müssen angegeben werden; für weggelassene Optionen werden die im Treiber enthaltenen Voreinstellungen verwendet.
insmod yam
./yamcfg yam0 io 0x2f8 irq 3 pers 127
richtet beispielsweise ein YAM an /dev/ttyS1 (»COM2«) mit einer
Persistence von 127 ein.
Der Treiber unterstützt bis zu vier YAMs, die als Netzwerkdevices
yam0 bis yam3 im System erscheinen.
Der YAM-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar.
Zunächst gibt man dem YAM-Device ein Rufzeichen:
/sbin/ifconfig yam0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig yam0 up
axparms -setcall yam0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
YAM hinzugefügt. Die Verbindung des Eintrags zum entsprechenden
Netzwerk-Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
Yam_1 VK2KTJ 1200 255 1 YAM 9k6 Port
Verwendet ein Programm den Eintrag »Yam_1« mit dem für YAM vergebenen
Rufzeichen, so wird das YAM-Device angesprochen. Ein einfacher Test wäre der
Aufbau einer Verbindung zu einer anderen Station mit dem Programm
call:
call Yam_1 VK2SUT
Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt
sich für TCP/IP einrichten, man kann es der ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Ab der Kernel-Version 2.2.x unterstützt Linux auch das 6Pack-EPROM, wie es
für verschiedene TNCs als Image 6Pack.bin verfügbar ist.
Der Treiber stammt von Andreas Könsgen <ajk@ccac.rwth-aachen.de>.
Für die aktuellen Kernel 2.0.35 bis 2.0.38 ist leider keine passende Version verfügbar, es wurde jedoch berichtet, daß die ältere Version 0.2.0, wie sie beispielsweise auf
ftp://ftp.funet.fi/pub/ham/unix/Linux/packet/ax25/
bzw.
ftp://ftp.pspt.fi/pub/linux/ham/ax25/
als
6pack-0.2.0.tgz zu finden ist, problemlos funktioniert.
Leider wird zur Zeit nur ein TNC pro serieller Schnittstelle unterstützt, obwohl das 6Pack-EPROM bis zu 8 vorsieht.
Technische Informationen zum 6Pack-Protokoll sind auf
http://www.ife.ee.ethz.ch/~sailer/ham/ham.html#sixpack
nachzulesen.
Wer mehr als einen TNC an einer seriellen Schnittstelle mit 6Pack betreiben
will, ist auf externe Software wie TheNetNode von
Nord><Link
(
http://www.nordlink.org)
angewiesen oder muß die weiter unten beschriebene
Lösung probieren.
Benutzer eines Kernels der 2.2.x-Reihe finden die Option zur Einbindung des Treibers unter
Network Device Support
[*] Network Device Support
...
[*] Radio network interfaces
[*] 6Pack
Mittlerweile ist eine aktualisierte Version dieses Treibers auf
ftp://ftp.ccac.rwth-aachen.de/pub/ajk/
als 6pack-0.4.2.tgz verfügbar.
Für deren Einrichtung gelten im wesentlichen die für die Version 0.2.0
im folgenden gemachten Aussagen. In jedem Fall gibt die im Archiv enthaltene
Dokumentation weitere Auskünfte.
Wer einen Kernel 2.0.35 bis 2.0.38 einsetzt, ist auf die Version 0.2.0 des Treibers angewiesen.
Dieser wird folgendermaßen eingerichtet:
cd /usr/src tar -zxvf /tmp/6pack-0.2.0.tgz cd 6pack-0.2.0Nach Anpassung des Makefiles an den verwendeten CPU-Typ wird der Treiber mit
makekompiliert. Wichtig ist, daß die Quelltexte der AX.25-Utilities an üblicher Stelle installiert sind.
Benutzer libc6-basierter Systeme müssen vor dem Compilieren die Zeilen
#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <stdio.h> #include <unistd.h>aus der Datei 6pack.c entfernen.
Das Modul 6pack.o kann nun nach /lib/modules/`uname -r`/net kopiert
und bei Bedarf geladen werden.
Um den 6Pack-Treiber nutzen zu können, benötigt man eine modifizierte Version
des Programms kissattach, wie sie in der aktuellsten Fassung der
AX.25-Utilities 0.0.x bereits enthalten ist. Sie wird als spattach
aufgerufen. spattach ist in den aktuellsten AX.25-Utilities ein Link auf
kissattach, dieses Programm erkennt automatisch, unter welchem Namen es
aufgerufen wurde, und stellt die entsprechenden Funktionen bereit.
Benutzer älterer Versionen der AX.25-Utilities müssen die Datei
kissattach.c im Quelltextverzeichnis ihrer AX.25-Utilities editieren.
Die Zeilen
#ifndef N_6PACK #define N_6PACK 7 #endifmüssen an den Anfang der Datei geschrieben werden (nur für Benutzer von 2.0.x-Kerneln!), weiterhin ist die Zeile
int disc = N_AX25;in
int disc = N_6PACK;zu ändern (betrifft alle Systeme).
Anschließend muß kissattach mit einem Aufruf von make
ohne Optionen neu übersetzt werden. Die jetzt in dem Verzeichnis stehende
ausführbare Datei sollte nach spattach umbenannt werden, um Konflikte
zu vermeiden. Anschließend kann sie nach /sbin oder /bin
kopiert werden, um sie im Pfad zu haben.
Nochmaliger Hinweis: In den AX.25-Utilities ab Version 0.0.4 ist spattach
bereits enthalten!
Zuerst wird das 6Pack-Modul geladen:
insmod 6packDer Treiber schreibt eine Initialisierungsmeldung ins Syslog (z.B.
/var/log/messages). Sie gibt Auskunft darüber, ob er geladen
werden konnte.
Das neu kompilierte Programm spattach funktioniert für 6Pack wie
kissattach für KISS (siehe auch dort):
spattach /dev/ttyS0 radio kissparms -p radio -t 100 -s 100 -r 25Eine Meldung
6Pack: TNC found
sollte jetzt ausgegeben werden.
In diesem Falle wurde der Treiber erfolgreich eingerichtet; es steht jetzt ein
Netzwerkinterface sp0 zur Verfügung, das in der üblichen Weise
konfiguriert werden kann. Wird der Treiber für weitere 6Pack-TNCs
eingerichtet, werden Devices sp1, sp2 usw. erstellt.
Der 6PACK-Treiber erzeugt Standard-Netzwerk-Devices, die der Kernel-AX.25-Code nutzen kann. Damit ist die Konfiguration mit der einer Netzwerkkarte vergleichbar.
Zunächst gibt man dem 6PACK-Device ein Rufzeichen:
/sbin/ifconfig sp0 hw ax25 VK2KTJ up
oder (einige Versionen von ifconfig unterstützen den
eben angegebenen Weg nicht):
/sbin/ifconfig sp0 up
axparms -setcall sp0 VK2KTJ up
Als nächstes wird in der Datei /etc/ax25/axports ein Eintrag für
6PACK hinzugefügt. Die Verbindung des Eintrags zum entsprechenden
Netzwerk-Device geschieht über das eingestellte Rufzeichen.
Der Eintrag in /etc/ax25/axports sieht dann beispielsweise so aus:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
6Pack_1 VK2KTJ 1200 255 1 6PACK TNC
Verwendet ein Programm den Eintrag »6Pack_1« mit dem für 6PACK vergebenen
Rufzeichen, so wird das 6PACK-Device angesprochen. Ein einfacher Test wäre der
Aufbau einer Verbindung zu einer anderen Station mit
dem Programm call:
call 6Pack_1 VK2SUT
Das neue AX.25-Device kann nun ganz normal verwendet werden, es läßt
sich für TCP/IP einrichten, man kann es der ax25d-Konfiguration
hinzufügen und NetROM oder ROSE darüber laufen lassen.
Ignacio Arenaza, EB2EBU, (inaki.arenaza@jet.es) entwickelte eine
Software, die eine Benutzung mehrerer TNCs unter 6Pack gestattet. Man
findet sie auf
http://personales.jet.es/inaki.arenaza/hamradio/m6pack/files/m6pack.tgz
Diese Version ist für die Benutzung mit den AX.25-Utilities 2.1.42a ausgelegt, deren Quelltext installiert sein muß. Sie sollte sich jedoch mit einigen Anpassungen auch mit neueren Versionen der AX.25-Utilities verwenden lassen.
Die Installation ist recht einfach; nach Entpacken des Archivs mit
cd /usr/src tar -zxvf /tmp/m6pack.tgzführt man ein
make allaus, das die beiden Programme
m6pack und m6packattach
übersetzt und installiert.
Der Multiplexer besteht aus zwei Programmen, m6pack und
m6packattach.
Die Man-Pages zu diesen Programmen enthalten alle weiteren Details.
m6pack macht den 6Pack-TNC im System verfügbar und bindet ihn an eine
Pseudo-Schnittstelle (siehe als Beispiel auch mkiss und
Dual-Port-TNCs).
Beispiel:
m6pack /dev/ttyS0 /dev/ptya0
bindet den ersten an /dev/ttyS0 angeschlossenen 6Pack-TNC an das Master-Ende der Pipe (/dev/ptya0; /dev/ttya0).
Alle weiteren TNCs werden durch weitere Aufrufe von m6pack
eingebunden.
m6pack /dev/ttyS0 /dev/ptya1
verbindet den zweiten 6Pack-TNC mit /dev/ptya1.
Die Verbindung mit den in /etc/ax25/axports definierten Ports wird
dann folgendermaßen hergestellt:
m6packattach /dev/ttya0 6pack1
m6packattach /dev/ttya1 6pack2
Hierzu muß die Datei /etc/ax25/axports zwei Einträge enthalten, die
beispielsweise so aussehen könnten:
# /etc/ax25/axports
# Konfiguration der AX.25-Ports
#
# Format:
# Portname Rufzeichen Baudrate Paketlänge Maxframe Beschreibung
#
6Pack1 VK2KTJ 1200 255 1 6PACK TNC Nr. 1
6Pack2 VK2KTJ-1 1200 255 1 6PACK TNC Nr. 2
Anschließend sollten sich diese Ports bereits verwenden lassen, ein möglicher Test wäre z.B.:
call 6pack1 VK2SUT