PR-Digi mit Direwolf
Mit recht einfachen Software-Mitteln ist es möglich, eine 'Moderne' Variante eines Packet Radio Digipeaters zu betreiben, welche (abgesehen vom AF-Interface zum Funkgerät) ganz ohne Spezialhardware auskommt.
Im folgenden wird ein Aufbau beschrieben, welcher sowohl einen Multibaud RF-Zugang, als auch einen HAMNET-Zugang über das AXUDP-Protokoll bereitstellen kann.
Plattform
Als systemtechnische Plattform eignet sich im Grunde ein Mikro-PC ähnlich Raspberry PI, auf welchem ein Linux-Betriebssystem lauffähig ist.
Auf unserem Standort Gantkofel IR3UGM läuft das in diesem Artikel beschriebene Setup beispielsweise mit einem OrangePi Zero (ARM Cortex A7 CPU mit 512MB RAM), aber es sind natürlich auch andere ARM- oder x86-Basierte Systeme möglich.
Zu beachten ist jedoch, dass - vor allem beim Betrieb von MultiBaud oder generell bei mehreren parallelen Zugängen - die verschiedenen Direwolf-Modems zeitgleich laufen und somit CPU-Last erzeugen.
Etwas schnellere CPUs sind daher vorteilhaft.
(Soft)Modem
Wo früher Hardware-TNCs ihre Arbeit verrichtet haben, kommen bei moderneren Setups vermehrt Software-Implementierungen zum Einsatz, die sich mittlerweile durchaus mit ihren Hardware-Pendants messen können.
In unserem Setup wird als Software-Modem Direwolf verwendet, mit welchem das Basisband-Signal erzeugt bzw. decodiert werden kann.
Dabei werden mehrere verschiedene Modulationsverfahren/Baudraten unterstützt, unter Anderem:
- 1200baud AFSK (der Klassiker)
- 2400bps nach ITU-T V.26b
- Sollte mit "klassischen" 1k2 fähigen Funkgeräten (also nur über Lautsprecher/Mikrofon Anschlüsse, ohne Zugang auf den FM-Diskriminator/Modulator) noch machbar sein
- hier wird ebenfalls eine Symbolrate von 1200 Symbolen/Sekunde verwendet, jedoch mit 4 möglichen Zuständen
- Somit können log2(4) = 2 bit pro Symbol übertragen werden
- 1200 Symbole/Sekunde * 2bit/Symbol = 2400 bit/Sekunde
- 4800bps nach ITU-T V.27
- die Symbolrate beträgt hier 1600 Symbole/Sekunde
- Das Modulationsschema benutzt 8 mögliche Zustände
- Somit log2(8) = 3 bit pro Symbol
- bei 1600Symbolen/Sekunde ergibt das 4800 bit/Sekunde
Für den Multibaud-Betrieb ist eine weitere Eigenheit zu beachten: Direwolf kann jeweils nur ein Modem pro Sound-Interface verwenden.
Man kann sich jedoch eines Tricks des Linux-Audio-Subsystems ALSA bedienen: ALSA unterstützt nämlich virtuelle Sound-Interfaces, welche schlussendlich "gemixt" und auf das gleiche physische Audiogerät ausgegeben werden.
Somit ist es möglich, in der Direwolf-Konfiguration beispielsweise die Modems für 1k2, 2k4 und 4k8 gleichzeitig auf dem gleichen Audio-Interface und somit schlussendlich auf der gleichen QRG zu verwenden.
Für die Anbindung an die PR-Node-Software gilt zu beachten, dass Direwolf nur ein einziges Pseudo-TTY-Gerät anlegen kann. In unserem Fall bräuchten wir nun aber für 3 Modems folglich 3 Stück.
Auch hier bedienen wir uns eines kleinen Tricks, um die vorher definierten Direwolf-Modems anzubinden:
Direwolf unterstützt zwar nur ein einziges Pseudo-TTY-Gerät, wohl aber mehrere TCP-KISS Verbindungen. Mit diesen kann aber unsere PR-Node-Software (X)Net nichts anfangen.
Als Bindeglied dient deshalb das Tool udpflex aus der dxlAPRS Toolchain, welches sich als Bridge dazwischenschalten lässt und von TCP-KISS ins AXUDP-Protokoll konvertiert, welches in (X)Net problemlos angesprochen werden kann.
Die Port-Konfiguration in unserer Direwolf.conf sieht nun folgendermaßen aus:
KISSPORT 8000 0 KISSPORT 8001 2 KISSPORT 8002 4
.. wobei der erste Wert den zu bindenden TCP-Port definiert, der Zweite steht für den CHANNEL (also das Modem).
Zu beachten: die Channels in Direwolf sind immer STEREO (also immer Paarweise) zu verstehen; somit muss das zweite Modem CHANNEL 2 (das dritte CHANNEL 4 usw.) sein.
Nun starten wir unsere udpflex-Instanzen, welche sich (option -T host:port) mit den verschiedenen TCP-KISS Ports am lokalen Host verbinden und ihrerseits UDP-Ports (option -U host:tx-port:rx-port) am lokalen Host öffnen, wo dann über AXUDP die AX.25 Pakete empfangen/gesendet werden:
# udpflex als TCP-KISS <> AXUDP Bridge fuers Anbinden der drei Direwolf-Modems an XNET ./udpflex -T 127.0.0.1:8000 -U 127.0.0.1:10001:10002 & ./udpflex -T 127.0.0.1:8001 -U 127.0.0.1:10003:10004 & ./udpflex -T 127.0.0.1:8002 -U 127.0.0.1:10005:10006 &
Eine sehr hilfreiche Dokumentation von udpflex und den anderen Hilfsmitteln aus der dxlAPRS-Toolchain findet sich bei dxlwiki.dl1nux.de
Packet-Router (X)Net
Als Packet Node Software bzw. Router ist (X)Net im Einsatz. Dieses ist auch auf neueren Plattformen noch Lauffähig.
Die Anbindung zwischen afskmodem und (X)NET erfolgt wie vorher beschrieben über AXUDP, wobei pro Modem (=Baudrate) ein Port konfiguriert wid.
Somit kann von (X)NET aus durch Auswahl des Ports gewählt werden, in welcher Baudrate eine Station via RF kontaktiert werden soll. Auch MHeard usw. wird dann entsprechend pro Port/Baudrate angezeigt.
Die Attach-Befehle sehen in unserem Fall beispielsweise folgendermaßen aus:
att ip0 axudp 1 1 l10001 d10002 127.0.0.1 att ip1 axudp 2 1 l10003 d10004 127.0.0.1 att ip2 axudp 3 1 l10005 d10006 127.0.0.1
Die TX- und RX-Ports müssen hier natürlich genau invertiert zur udpflex-Konfiguration angegeben werden
AXUDP für Userzugang
Wenn neben dem Zugang via RF auch ein AXUDP-Zugang angeboten werden soll, braucht es dazu noch einmal einen kleinen Trick:
(X)Net hat einen AXIP/AXUDP Treiber integriert, mit welchem AXUDP Verbindungen zu anderen Nodes gemacht werden können.
Dabei nimmt (X)Net laut Doku aber aus Sicherheitsgründen nur AXUDP Frames an, die explizit vom konfigurierten Linkpartner kommen.
Wildcards o.Ä. können keine angegeben werden.
Als Workaround ist nach österreichischem Vorbild udphub aus der dxlAPRS Toolchain vorgeschaltet.
Konfigurationstechnisch stellt (X)Net eine AXUDP-Verbindung mit 127.0.0.1 her (bei uns beispielsweise über die Ports 9007 und 9008), dort lauscht udphub.
Da für (X)Net nun alle Verbindungen "vom konfigurierten AXUDP-Partner 127.0.0.1 kommen", ist (X)Net zufrieden.
Diese Lösung hat außerdem noch einen weiteren Vorteil: udphub merkt sich die IP-Adressen der anrufenden Stationen für eine via Konfigurationsparameter definierbare Zeit und kann somit auch ausgehende Connects machen.
Die Verwendung ist also gleich, wie bei Usern die via RF ankommen würden.
Für Troubleshooting-Zwecke kann udphub mit der option -w angewiesen werden, einen Log der letzten bekannten AXUDP-Verbindungen (sozusagen den "Switching-Table") in eine Datei (z.B. /tmp/udphub.log) zu schreiben.
# Port fuer AXUDP User-Zugang USERPORT=10093 # udphub als AXUDP-Switch - Workaround damit XNET AXUDP Calls von Usern entgegennimmt # udphub merkt sich intern fuer die angegebene Zeitdauer (option -l in Sekunden) # die IP-Adressen/Ports der AXUDP-User. # Somit koennen ueber diesen Port auch Stationen connected werden ./udphub -u 127.0.0.1:9007:9008 -l 1440 -p $USERPORT -w /tmp/udphub.log &
Bei einem ausgehenden Connect ist natürlich zu beachten, dass es durchaus passieren könnte, dass der remote Node nach einiger Zeit auf demselben Port nicht mehr antwortet.
Das passiert beispielsweise, wenn zwischen dem PR-Node und dem zu verbindenden User ein NAT dazwischen ist - beispielsweise weil das Packet-Gerät im LAN des OMs läuft und bei der Verbindung ins HAMNET mit der 44er IP der HAMNET-Antenne geNATted wird. In diesem Fall wird die NAT-Session irgendwann in Timeout gehen und folglich ein Connect von außen nicht mehr funktionieren.
In solchen Fällen gilt also: Soll der eigene PR-Node im QTH auch von außen via AXUDP verbindbar sein, dann ist darauf zu achten, dass dieser im idealfall selbst eine 44er IP aus dem HAMNET zugewiesen bekommt.
In diesen Fällen ist es am besten, sich mit einem HAMNET-Sysop zu besprechen.
