Linux AX25 HOWTO: Einen AX.25-Port einrichten

6. Einen AX.25-Port einrichten

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 /etc/ax25/axports. Sie muß für jeden auf dem System verwendeten AX.25-Port einen Eintrag erhalten.

6.1 Das AX.25-Netzwerk-Device erstellen

Das Netzwerk-Device ist das, was aufgelistet wird, wenn man 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 ifconfig {Devicename} {IP-Adresse}:


 
ifconfig bcsf_0 44.136.8.5 netmask 255.255.255.0 up

KISS

Optionen bei der Kernel-Kompilierung:


General Setup

[*] Networking support

Network Device Support

[*] Network Device Support
...
[*] Radio network interfaces
...
[*] Serial port KISS driver for AX.25

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 kissattach verwendet: (Annahmen: TNC hängt an /dev/ttyS0 (COM1) und der vorgesehene Port in /etc/ax25/axports heißt radio)


/usr/sbin/kissattach /dev/ttyS0 radio
kissparms -p radio -t 100 -s 100 -r 25

Damit wird ein KISS-Netzwerk-Device erzeugt. Diese Devices erhalten die Namen ax0 - ax9. Beim ersten Aufruf erzeugt kissattach ax0, beim zweiten ax1 usw..

Jedes Kiss-Device hat eine zugehörige serielle Schnittstelle. Mit 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 /etc/ax25/axports 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


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 einkompiliert werden (CONFIG_MKISS=y in /usr/src/linux/config) wenn die AX-25-Unterstützung (siehe Abschnitt 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 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ß vor der AX.25-Konfiguration 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.

Hat man z.B. 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. Auf die serielle Schnittstelle selbst kann kein kissattach angewendet werden, da mkiss diese ja bereits nutzt. Der Befehl mkiss kennt einige Optionen:

-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.

-s

<Baudrate> stellt die Baudrate der seriellen Schnittstelle ein.

-h

schaltet den Hardware-Handshake ein (Voreinstellung: Aus). Wird von den meisten KISS-Implementationen nicht unterstützt.

-l

schaltet eine Mitschrift (logging) in die syslog-Logdatei ein.

BayCom

Folgende Optionen zur Kernel-Kompilierung 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

Für erste Tests sollte der Treiber mit »m« als Modul kompiliert werden. Thomas Sailer (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:

http://www.baycom.de

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 bc0, bc1, 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:


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.

Das sieht dann z.B. so aus:


insmod baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
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 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:


 
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ö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 rmmod entfernt werden kann:


rmmod lp

Das komplette Skript sieht dann etwa so aus:


#!/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

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 hdlcdrv 
insmod baycom mode="par96" iobase=0x378 irq=7 options=0

Dies ist aber nicht unbedingt der beste Weg. sethdlc arbeitet genau so gut mit einem Modem wie mit mehreren. 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 einkompiliert. Man kann das Netzwerk-Device bc0 nun einrichten:

als Parallelport-Modem an LPT1 mit Software-DCD:
sethdlc -p -i bc0 mode par96 io 0x378 irq 7

als serielles Modem an COM1:


sethdlc -p -i bc0 mode "ser12*" io 0x3f8 irq 4

AX.25-Kanalzugriffsparameter

Die AX.25-Kanalzugriffsparameter entsprechen den Parametern ppersist, txdelay und slottime. Wiederum wird dazu 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:


sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half

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:


/sbin/ifconfig bc0 hw ax25 VK2KTJ up

Einige Versionen von ifconfig unterstützen den eben angegebenen Weg nicht. Man kann dann so vorgehen:


 
/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.

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 ax25d hinzufügen und NetROM oder ROSE darüber laufen lassen.

SoundModem

Folgende Optionen bei der Kernel-Kompilierung 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 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

Thomas Sailer (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 nicht unterstützt.

Die Soundkarten benötigen eine kleine Zusatzschaltung zur Ansteuerung der PTT, Informationen dazu findet man auf Thomas Soundmodem-PTT-Seite:


 
<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">

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.

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 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) 
insmod sound (evtl. Optionen)
rmmod sound 
insmod hdlcdrv 
insmod soundmodem (evtl. Optionen, dazu später)

Die Soundkarte einrichten

Der SoundModem-Treiber initialisiert die Soundkarte nicht. In den AX.25-Utilities ist zu diesem Zweck das Programm 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 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.

Den SoundModem-Treiber konfigurieren

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 1200 bps-Modem emuliert:


insmod hdlcdrv
insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1

Aber es geht auch genau so gut mit sethdlc, das sowohl mit einer Karte als auch mit mehreren funktioniert: Zunächst muß auch hier das Modul geladen


insmod hdlcdrv 
insmod soundmodem

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 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 in Punkt 6.1.3.1. 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.

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.

Die Audiopegel einstellen und den Treiber feinabstimmen

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 Sende- und Empfangspegel abgleichen.

Um smdiag im »Augen-Modus« für das SoundModem-Device sm0 zu 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:

(bei von Linux unterstützten Karten): Man besorge sich ein Mixerprogramm - es finden sich einige auf
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.
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 Sound HOWTO.

Die AX.25-Unterstützung des Kernels für die Nutzung des SoundModem-Device einrichten

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:


/sbin/ifconfig sm0 hw ax25 VK2KTJ up

Einige Versionen von ifconfig unterstützen den eben angegebenen Weg nicht. Dann kann man so vorgehen:


 
/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. 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 ax25d hinzufügen und NetROM oder ROSE darüber laufen lassen.

Erscheinen Fehlermeldungen beim Aufruf von ifconfig wie diese


no such device
permission denied

sollte man die Konfigurationsoptionen (I/O-Adresse, IRQ, DMA) nochmals überprüfen.

PI-Karte

Folgende Optionen sind bei der Kernel-Kompilierung 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 kompiliert und hat er die Karte korrekt erkannt, läßt er sich einrichten:


/sbin/ifconfig pi0a hw ax25 VK2KTJ up

Damit wird die erste PI-Karte mit dem Rufzeichen VK2KTJ konfiguriert und aktiviert. Nun muß noch der entsprechende Eintrag in /etc/ax25/axports erfolgen, und es kann losgehen. Der PI-Karten-Treiber wurde von David Perry (dp@hydra.carleton.edu) geschrieben.

PacketTwin

Folgende Optionen beim Kernelkompilieren:


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 kompiliert und hat er die Karte korrekt erkannt, läßt er sich einrichten:


/sbin/ifconfig pt0a hw ax25 VK2KTJ up

Damit wird die erste PacketTwin-Karte mit dem Rufzeichen VK2KTJ konfiguriert und aktiviert. Nun muß noch der entsprechende Eintrag in /etc/ax25/axports erfolgen, und es kann losgehen. Der PacketTwin-Treiber wurde von Craig Small (csmall@triode.apana.org.au) geschrieben.

SCC, allgemein

Wichtige Kernel-Kompilier-Optionen:


General Setup 

[*] Networking support

Network Device Support 

...
[*] Radio network interfaces 
...
[*] Z8530 SCC KISS emulation driver for AX.25

Joerg Reuter, DL1BKE (jreuter@lykos.tng.oche.de) 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.

Die Konfigurations-Tools finden und installieren

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:

Es gibt verschiedene Versionen, man muß sich die für seinen Kernel passende heraussuchen.

Kernel 2.0.x:

z8530drv-2.4a.dl1bke.tar.gz

Kernel 2.1.6 oder neuer:

z8530drv-utils-3.0.tar.gz

Mit folgenden Befehlen läßt sich das Paket installieren:


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

Nach dem erfolgreichen Kompilieren 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 Namenn scc0 - scc7. Hat man vorhin make for_kernel eingegeben, so muß der Kernel neu kompiliert 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 kompilieren (make module), so wurde ein Modul namens scc.o in das entsprechende Verzeichnis /lib/modules/{kernelversion}/net kopiert, welches mit insmod geladen werden kann.

Den Treiber für die verwendete Karte einrichten

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. 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.

Konfiguration der Hardware-Parameter

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:

chip

Wird verwendet, um die einzelnen Abschnitte voneinander zu trennen. Beliebige Argumente sind erlaubt, sie werden nicht verwendet.

data_a

Wird zur Angabe der Adresse des Datenports für den SCC-Kanal »A« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x300.

ctrl_a

Wird zur Angabe der Adresse des Steuerports für den SCC-Kanal »A« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x304.

data_b

Wird zur Angabe der Adresse des Datenports für den SCC-Kanal »B« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x301.

ctrl_b

Wird zur Angabe der Adresse des Steuerports für den SCC-Kanal »B« verwendet. Argument ist eine Hexadezimalzahl, zum Beispiel 0x305.

irq

Gibt den IRQ an, den der in diesem Abschnitt einzustellende Chip verwendet. Argument ist eine Integerzahl, wie 5.

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.

board

Der Typ der 8530-SCC-Karte. Folgende Werte sind erlaubt:

PA0HZP

die PA0HZP-SCC-Karte

EAGLE

die EAGLE-SCC-Karte

PRIMUS

die PRIMUS-PC (DG9BL-)Karte

BAYCOM

die BayCom-(U)SCC-Karte

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.

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.

special

Optional, gibt die Adresse eines speziellen Funktionsregisters für manche Karten an. Voreinstellung: 0.

Einige Beispielkonfigurationen:


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.

Kanal-Konfiguration

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 hier:

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. scc0.

speed

Gibt die Übertragungsrate in Bits pro Sekunde an, muß ganzzahlig sein, z.B. 1200.

clock

Gibt an, aus welcher Quelle der Datentakt stammt.

Erlaubte Werte sind:

dpll

normaler Halbduplexbetrieb

external

Das Modem hat einen eigenen Sende-/Empfangstakt

divider

verwendet den Fullduplex-Teiler, wenn installiert

mode

Gibt die zu verwendende Datenkodierung an. Mögliche Werte sind nrz und nrzi.

rxbuffers

Gibt die Anzahl der im Speicher zu reservierenden Empfangs- puffer vor. Der Wert ist ganzzahlig, z.B. 8.

txbuffers

Gibt die Anzahl der im Speicher zu reservierenden Sende- puffer vor. Der Wert ist ganzzahlig, z.B. 8.

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.

txdelay

Das von KISS bekannte TXDelay, der Wert ist ganzzahlig und wird in Millisekunden angegeben.

persist

Der Wert für die Persistence, ganzzahlig.

slot

KISS-Slottime, ganzzahlig, in Millisekunden.

tail

Der TXTail-Wert bei KISS, ganzzahlig, in Millisekunden.

fulldup

Das bei KISS verwendete Fullduplex-Flag, Wert ist entweder 1 für Vollduplex oder 0 für Halbduplex.

wait

Der Wait-Wert bei KISS, ganzzahlig, in Millisekunden.

min

Der Min-Wert bei KISS, ganzzahlig, in Sekunden.

maxkey

Die maximale Sendezeit bei KISS ganzzahlig, in Sekunden.

idle

Der Idle-Timer-Wert, ganzzahlig, in Sekunden.

maxdef

Der Maxdef-Wert bei Kiss, ganzzahlig.

group

Der group-Wert bei KISS, ganzzahlig.

txoff

Der txoff-Wert bei Kiss, ganzzahlig, in Millisekunden.

softdcd

Der Wert für SoftDCD (Software-Rauschsperre), ganzzahlig.

slip

Das Slip-Flag bei KISS, ganzzahlig.

Den Treiber verwenden

Man verwendet die scc*-Geräte wie andere Netzwerk-Devices auch. Beispiel:


/sbin/ifconfig scc0 44.136.8.5 netmask 255.255.255.0
/sbin/ifconfig scc0 up 
axparms -setcall scc0 VK2KTJ up

Die Programme sccstat und sccparam

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

BPQ-Ethernet

Folgende Optionen sind bei der Kernel-Kompilierung 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 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 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-Node mit Linux-AX.25-Unterstützung verbinden

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

6.2 Die Datei /etc/ax25/axports

Diese Datei ist eine einfache Textdatei, die mit einem Texteditor erzeugt wird. Sie hat folgendes Format:


Portname    Rufzeichen    Baudrate  Paketlänge   Maxframe   Beschreibung

wobei gilt:

Portname

Bezeichner für den Port

Rufzeichen

Rufzeichen, welches dem Port zugeordnet werden soll

Baudrate

Baudrate zum TNC

Paketlänge

Länge des Datenfeldes eines Paketes in Bytes

Maxframe

maximale Anzahl unbestätigter Pakete (AX.25-Window)

Beschreibung

kurzer beschreibender Text

Beispieldatei von Terry Dawson:


radio  VK2KTJ-15       4800   256   2    4800 bps auf 144.800 MHz
ether  VK2KTJ-14   10000000   256   2    BPQ Ethernet-Device

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.

6.3 Das AX.25-Routing einrichten

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 axparms verwenden:


/usr/sbin/axparms -route add radio VK2XLZ VK2SUT

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 axparms zu finden.

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:56