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.
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
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:
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.
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.deDer 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:
sethdlc -p -i bc0 mode par96 io 0x378 irq 7
sethdlc -p -i bc0 mode "ser12*" io 0x3f8 irq 4
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.
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)
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.
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.
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:
sunsite.unc.edu:/pub/Linux/apps/sound/mixerscmix, da sie in das Startskript eingebunden werden können
und so immer die gleichen Einstellungen gegeben sind.
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.
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.
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.
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.
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:
ftp.tu-dresden.de:/pub/soft/hamradio/packet/tcpip/linux/
ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linuxEs gibt verschiedene Versionen, man muß sich die für seinen Kernel passende heraussuchen.
z8530drv-2.4a.dl1bke.tar.gz
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.
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.
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 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.
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:
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.
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
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
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 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
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:
Bezeichner für den Port
Rufzeichen, welches dem Port zugeordnet werden soll
Baudrate zum TNC
Länge des Datenfeldes eines Paketes in Bytes
maximale Anzahl unbestätigter Pakete (AX.25-Window)
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.
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.