Looking to expand the device capability I stumbled across a really interesting little project that is still in the early stages of development but, is functional and worth trying out.
The TC²-BBS Meshtastic Version is a simple BBS system that runs on a RaspberryPi, Linux PC or virtual machine (VM) and can connect to a Meshtastic device via either serial, USB or TCP/IP. Having my M0AWS-1 Meshtastic node at home connected to Wifi I decided to use a TCP/IP connection to the device from a Linux VM running the Python based TC²-BBS Meshtastic BBS.
Following the instructions on how to deploy the BBS is pretty straight forward and it was up and running in no time at all. With a little editing of the code I soon had the Python based BBS software M0AWS branded and connected to my Meshtastic node-1.
M0AWS Meshtastic BBS Main Menu accessible on M0AWS-1 node.
The BBS system is very reminiscent of the old packet BBS systems of a bygone era but, it is ideal for the Meshtastic world as the simple menus and user interface are easily transmitted in seconds via the Mesh using minimal bandwidth.
The BBS is accessible by opening a Direct Message session with the M0AWS-1 node. Sending the letter H to the node will get you the initial help screen showing the menu above and then from there onwards it’s just a matter of selecting the menu item and following the BBS prompts to use the BBS.
The BBS also works across MQTT. I tested it with Dave, G4PPN and it worked perfectly via the Meshtastic MQTT server.
This simple but, effective BBS for the Meshtastic network will add a new message store/forward capability to the Mesh and could prove to be very important to the development of the Meshtastic mesh in the UK and the rest of the world.
We’ve recently added a new room to the Matrix HAM Radio Space for Digital Voice modes as this was an area of interest that didn’t really fit into any of the other rooms.
The new Digital Voice room has attracted a lot of attention from members, with a lot of the focus being on the AllStarLink system. Michael, DK1MI built an AllStarLink node in the cloud for us all to use for Matrix Nets and so I decided I had to get in on the fun.
Jumbospot SHARI SA818 Amateur Radio AllStarLink Radio Interface Front Panel ViewJumbospot SHARI SA818 Amateur Radio AllStarLink Radio Interface Rear ViewJumbospot SHARI SA818 Amateur Radio AllStarLink Radio Interface stripped down View
The two USB connectors on the SHARI device are position such that they plug into two of the available 4 USB ports on the RaspberryPi without the need for cables. This keeps the whole solution together in one neat package.
Before you start you will need to obtain a node number and secret (password) from the AllStarLink Portal. To get this you will need to provide proof to the AllStarLink administrators that you are a licensed Amateur Radio (HAM) operator. This is done by uploading a copy of the first page of your HAM licence to the website for the admin team to check. This can take 24hrs to be completed so make sure you get this all done before trying to build your node. You cannot build a node successfully without a node number and secret.
Of course you will also need a transceiver that can operate on the 438.800Mhz frequency or other frequency of your choice on the 2m or 70cm HAM band.
You will also need to open port 4569 on your internet router and setup port forwarding to the IP Address that you will be using on your RaspberryPi node. It’s important to use a static IP Address on your RaspberryPi.
There are quite a few different Linux based operating system (O/S) images that are available for the RaspberryPi devices that have been specifically tailored for the AllStarLink node and include all the necessary software and library packages out the box.
Once downloaded you need to burn the ISO image onto a suitable SD card for your RaspberryPi. I use BalenaEtcher as it’s extremely quick and reliable at burning ISO images to SD cards.
Of course if you are a hardline Linux command line junkie you can always use dd to create the SD card.
Once you’ve got your O/S onto your SD card, slot it into your RaspberryPi making sure your SHARI device is connected to the two USB ports and then power it up. Make sure you have a good PSU for the RaspberryPi as the two devices together draw around 3A of current during the transmit cycle. (I use a 3.6A PSU from Amazon).
The default login for the Raspbian O/S is shown below. Login via SSH and configure your RaspberryPi for your local network. It’s important to use a static IP Address configured either directly on the RaspberryPi or via DHCP in your router.
Next you need to change directory into the asterisk config file directory using the command shown below:
cd /etc/asterisk
In this directory you will find all the default config files that come as part of the distro. For this build we’re not going to use them and so we need to move them out of the way ready for a set of config files that have already been configured correctly.
Using the following commands create a new directory, move into that new directory and then move all the unwanted configuration files into it:
mkdir ORIGINAL-CONF-FILES
cd ./ORIGINAL-CONF-FILES
mv ../*.conf ./
ls -la
cd ../
You should now be back in the /etc/asterisk directory which will now be empty apart from the custom directory which we left in place.
You now need to copy the correctly configured configuration files into the /etc/asterisk directory. Start by downloading the zip file containing the new configuration files
Once downloaded, copy the .zip file into the repeater users home directory (/home/repeater) using either scp on the Linux command line or if using Windows you can use the FileZilla Client in SFTP mode using the login details above.
Once you have the .zip file in the repeater user’s home directory you need to copy the file into the /etc/asterisk directory as user root:
The gpioBASH script and configuration details were supplied by Mark, G1INU in the Digital Voice room on the Matrix. It adds the COS light functionality to the setup. The COS light will now light every time the SA818 hears RF on the input.
The next thing you need to do is configure the SA818 radio device in the SHARI. The script I used was originally from https://wiki.fm-funknetz.de/doku.php?id=fm-funknetz:technik:shari-sa818 all I’ve done is change the entries to switch off CTCSS and changed the frequency to 438.800Mhz. Configuring the SA818 is done by running the SA818-running.pyPython programme that you moved into the repeater user home directory. Making sure you are still user root, run the following commands:
cd /home/repeater
./SA818-running.py
At this point your SHARI SA818 device will be configured to operate on 438.800Mhz and CTCSS will be disabled.
If you want to change the frequency or enable and set a CTCSS tone to access the node you will need to edit the Python programme using your favourite text editor and change the entries accordingly. Once changed rerun the program as shown above and your SHARI will be reconfigured to your new settings.
Next you need to move the allmon.ini.php file into the correct directory so that it enables access to the Allstar Monitor web page on the device so that you can manage connecting/disconnecting nodes. Use the following commands as user root to achieve this:
The allmon.ini.php file needs to have your node name entered into it for it to work correctly. As user root, change directory and edit the file using your favourite editor.
cd /var/www/html
Using your text editor, search for the line starting [XXXXX] and change the XXXXX to your node number. Save the change and exit the file.
At this point you are almost complete, all that is left to do is add your node number and node secret into the appropriate configuration files in the /etc/asterisk directory.
Since I am a Linux command line junkie I use vi to edit all the configuration files on the command line as user root, but you can use any editor of your choice.
cd /etc/asterisk
Start with the extensions.conf file. Search for the line starting with NODE = and delete the XXXXX entry and insert your node number. Save the file and edit it.
Next you need to edit the iax.conf file. This time search for the line starting with register= and change the XXXXX for your node number and the YYYYYYYYYYYY for your node secret. Be careful not to accidentally delete any other characters in the lines otherwise it will corrupt the configuration file.
In the same file search for the two lines that start with secret = and change the YYYYYYYYYYYY for your node secret. Once you have changed both of the secret entries, save and exit the file.
The final file to edit is the rpt.conf file. Once again open the file using your favourite editor and search for the line starting with XXXXX = radio@127.0.0.1:4569/XXXXX, change the XXXXX entries for your node number making sure not to delete any other characters next to the XXXXX entries.
Further down in the same file there is a line that starts with [XXXXX], once again change the XXXXX for your node number making sure to keep the square brackets at each end of the node number as you edit it.
Finally move down to the very bottom of the file and find the two lines that start with /home/repeater/gpio, once again change the XXXXX entries for your node number.
Once this is done, save and exit the file. At this point your node should be fully configured and will only require a reboot to get it working.
As user root, reboot your raspi using the reboot command.
reboot
Once your raspi comes back online, login using SSH as user repeater and then become root user using the sudo command detailed above.
You now need to create the admin user password for the Allstar Monitor web page on the device. This is done using the following commands as user root:
cd /var/www/html/
htpasswd -c .htpasswd admin
You will be asked to enter a password twice for the admin user, make sure you make a note of this password as you will need it to login to the web page.
Once this is done your configuration is complete, logout from the terminal session by entering exit twice (once to logout as user root and another to logout as user repeater).
Using your favourite web browser enter the IP Address of your raspi into the URL bar as shown below:
http://<Your-Raspi-IP>/allmon2
Note: remove the <> from the URL once you have entered the required information.
Once this is done you should be presented with your node control panel as shown below.
First visit to the AllStar Monitor Web Page
Login using Admin and the password you set above and you are now ready to start using your node.
It’s a good idea to connect to node 55553 which is a parrot test node to check your audio levels. you can do this by entering the node into the field at the top left and pressing the connect button.
M0AWS AllStarLink Node 61928 connected to 55553 Parrot
Once connected, tune your radio to 438.800Mhz FM and transmit a test message using your callsign and test123, or something similar. The parrot will then play your recording back to you so that you can hear how you sound. It will also comment on your audio level as to whether it is OK or not.
You are now connected to AllStarLink network and have the world at your finger tips. Below is a small list of nodes in the UK, Australia and America to get you started chatting with other HAMs via your node.
55553 ASL Parrot for testing
41522 M0HOY HUBNet Manchester, UK
60349 VK6CIA 439.275 Perth, Western Australia
51077 VK6SEG South West Hub B Albany WA
2167 M0JKT FreeSTAR UK HUB 2 freestar.network
53573 NWAG NW AllStar Group Lancashire, UK
27339 East Coast Hub Wilmington NC USA
M0AWS AllStarLink Node 61928 sitting on the equipment rack
Thanks to Michael, DK1MI for building and hosting the Matrix HAM Radio Space AllStarLink Node (57881) and getting us all kicked off into the world of AllStarLink!
We hope to be having regular Matrix Net’s on the node soon for all Matrix members and visitors. We’ll organise days/times via the Digital Voice room.
Following on from my article about my QO-100 Satellite Ground Station Complete Build, this article goes into some detail on the Node-RED section of the build and how I put together my QO-100 Satellite Ground Station Dashboard web app.
The Node-RED project has grown organically as I used the QO-100 satellite over time. Initially this started out as a simple project to synchronise the transmit and receive VFO’s so that the SDR receiver always tracked the IC-705 transmitter.
Over time I added more and more functionality until the QO-100 Ground Station Dashboard became the beast it is today.
M0AWS QO-100 Ground Station Control Dashboard built using Node-RED.
Looking at the dashboard web app it looks relatively simple in that it reflects a lot of the functionality that the two radio devices already have in their own rights however, bringing this together is actually more complicated than it first appears.
Starting at the beginning I use FLRig to connect to the IC-705. The connection can be via USB or LAN/Wifi, it makes no difference. Node-RED gains CAT control of the IC-705 via XMLRPC on port 12345 to FLRig.
To control the SDR receiver I use GQRX SDR software and connect to it using RIGCTL on GQRX port 7356 from Node-RED. These two methods of connectivity work well and enables full control of the two radios.
M0AWS Node-RED QO-100 Ground Station Dashboard Flow as of 12/06/24
The complete flow above looks rather daunting initially however, breaking it down into its constituent parts makes it much easier to understand.
There are two sections to the flow, the GQRX control which is the more complex of the two flows and the comparatively simple IC-705 section of the flow. These two flows could be broken down further into smaller flows and spread across multiple projects using inter-flow links however, I found it much easier from a debug point of view to have the entire flow in one Node-RED project.
Breaking down the flow further the GQRX startup section (shown below) establishes communication with the GQRX SDR software via TCP/IP and gets the initial mode and filter settings from the SDR software. This information is then used to populate the dashboard web app.
M0AWS Node-RED QO-100 Ground Station Dashboard – GQRX Startup Flow
The startup triggers fire just once at initial startup of Node-RED so it’s important that the SDR device is plugged into the PC at boot time.
All the startup triggers feed information into the RIGCTL section of the GQRX flow. This section of the flow (shown below) passes all the commands onto the GQRX SDR software to control the SDR receiver.
M0AWS Node-RED QO-100 Ground Station Dashboard – GQRX RIGCTL Flow
The TCP RIGCTL -> GQRX node is a standard TCP Request node that is configured to talk to the GQRX software on the defined IP Address and Port as configured in the GQRX setup. The output from this node then goes into the Filter RIGCTL Response node that processes the corresponding reply from GQRX for each message sent to it. Errors are trapped in the green Debug node and can be used for debugging.
The receive S Meter is also driven from the the output of the Filter RIGCTL Response node and passed onto the S Meter function for formatting before being passed through to the actual gauge on the dashboard.
Continuing down the left hand side of the flow we move into the section where all the GQRX controls are defined.
M0AWS Node-RED QO-100 Ground Station Dashboard – GQRX Controls Flow
In this section we have the VFO step buttons that move the VFO up/down in steps of 10Hz to 10Khz. Each button press generates a value that is passed onto the Set DeltaFreq change node and then on to the Calc new VFO Freq function. From here the new VFO frequency is stored and passed onto the communications channel to send the new VFO frequency to the GQRX software.
The Mode and Filter nodes are simple drop down menus with predefined values that are used to change the mode and receive filter width of the SDR receiver.
Below are the HAM band selector buttons, each of these will use a similar process as detailed above to change the VFO frequency to a preset value on each of the HAM HF Bands.
The QO-100 button puts the transmit and receive VFO’s into synchro-mode so that the receive VFO follows the transmit VFO. It also sets the correct frequency in the 739Mhz band for the downlink from the LNB in GQRX SDR software and sets the IC-705 to the correct frequency in the 2m VHF HAM band to drive the 2.4Ghz up-converter.
The Split button allows the receive VFO to be moved away from the transmit VFO for split operation when in QO-100 mode. This allows for the receive VFO to be moved away so that you can RIT into slightly off frequency stations or to work split when working DXpedition stations.
The bottom two Memory buttons allow you to store the current receive frequency into a memory for later recall.
At the top right of this section of the flow there is a Display Band Plan Info function, this displays the band plan information for the QO-100 satellite in a small display field on the Dashboard as you tune across the transponder. Currently it only displays information for the satellite, at some point in the future I will add the necessary code to display band plan information for the HF bands too.
The final section of the GQRX flow (shown below) sets the initial button colours and starts the Powermate USB VFO knob flow. I’ve already written a detailed article on how this works here but, for completeness it is triggered a few seconds after startup (to allow the USB device to be found) and then starts the BASH script that is used to communicate with the USB device. The output of this is processed and passed back into the VFO control part of the flow so that the receive VFO can be manually altered when in split mode or in non-QO-100 mode.
M0AWS Node-RED QO-100 Ground Station Dashboard – Powermate VFO Flow
The bottom flows in the image above set some flow variables that are used throughout the flow and then calculates and sets the RIT value on the dashboard display.
The final section of the flow is the IC-705 control flow. This is a relatively simple flow that is used to both send and receive data to/from the IC-705, process it and pass it on to the other parts of the flow as required.
M0AWS Node-RED QO-100 Ground Station Dashboard – IC-705 Control Flow
The IC-705 flow is started via the timestamp trigger at the top left. This node is nothing more than a trigger that fires every 0.5 seconds so that the dashboard display is updated in near realtime. The flow is pretty self explanatory, in that it collects the current frequency, transmit power, SWR reading, PTT on/off status and S Meter reading each time it is triggered. This information is then processed and used to keep the dashboard display up to date and to provide VFO tracking information to the GQRX receive flow.
On the left are the buttons to change band on the IC-705 along with a button to tune to the VOLEMT on the 60m band. Once again there two memory buttons to save and recall the IC-705 VFO frequency.
The Startup PTT Colour trigger node sets the PTT button to green on startup. The PTT button changes to red during transmit and is controlled via the Toggle PTT function.
At the very bottom of the flow is the set transverter IF Freq function, this sets the IC-705 to a preselected frequency in the 2m HAM band when the dashboard is switched into QO-100 mode by pressing the QO-100 button.
On the right of the flow there is a standard file write node that writes the 2.4Ghz QO-100 uplink frequency each time it changes into a file that is used by my own logging software to add the uplink frequency into my log entries automatically. (Yes I wrote my own logging software!)
The RX Audio Mute Control filter node is used to reduce the receive volume during transmit when in QO-100 full duplex mode otherwise, the operator can get tongue tied hearing their own voice 250ms after they’ve spoken coming back from the satellite. This uses the pulse audio system found on the Linux platform. The audio is reduced to a level whereby it makes it much easier to talk but, you can still hear enough of your audio to ensure that you have a good, clean signal on the satellite.
As I said at the beginning of this article, this flow has grown organically over the last 12 months and has been a fun project to put together. I’ve had many people ask me how I have created the dashboard and whether they could do the same for their ground station. The simple answer is yes, you can use this flow with any kind of radio as long as it has the ability to be controlled via CAT/USB or TCP/IP using XMLRPC or RIGCTL.
To this end I include below an export of the complete flow that can be imported into your own Node-RED flow editor. You may need to make changes to it for it to work with your radio/SDR but, it shouldn’t take too much to complete. If like me you are using an IC-705 and any kind of SDR controlled by GQRX SDR software then it’s ready to go without any changes at all.
Beim Vernetzen von Computern via Funk kann sich die Anzahl und Auswahl der direkt erreichbaren Gegenstellen im Verlaufe der Zeit ändern: Neue Knoten können hinzukommen, bestehende entfallen oder vorübergehend unerreichbar sein. Zeitgemäße Netzwerk-Protokolle, z.B. das Internet-Protokoll (IP), in Verbindung mit geeigneten Routing-Protokollen, z.B. Babel, können die Erreichbarkeit aller Knotenpunkte eines vermaschten Funknetzes (und ggf. weiterer angeschlossener Teilnetze) ermöglichen.
Insbesondere für uns Funkamateure ist ein solcher Ansatz deshalb interessant, weil einige Stationen nicht dauerhaft zur Verfügung stehen (z.B. weil sie nur besetzt betrieben werden), sich die Anzahl von Knotenpunkten jederzeit ändern kann und Überreichweiten oder experimentelle Aufbauten bestimmte Teilnetze verbinden könnten, die ansonsten isoliert voneinander sind.
In diesem Artikel möchte ich einen Lösungsansatz zur IP-Adressvergabe und Vernetzung via IP-Routing vorstellen, der
die Eigenarten des Mediums „Funk“ berücksichtigt und
einfach einzurichten ist.
Die das Netz aufspannenden Stationen sind hierbei in einem vermaschten Netzwerk (Mesh-Netz) miteinander verbunden. Wie die dazu notwendigen Direktverbindungen aufgebaut werden können, soll nicht Teil dieses Artikels sein, wird jedoch z.B. von DL1PZ in einem anderen Beitrag behandelt. Stattdessen beschäftige ich mich hier mit der Einrichtung des Routings, so dass eine Funkstation A, die Kontakt mit einer Funkstation B hat, auch die Funkstation C erreichen kann, falls die Stationen B und C eine Verbindung haben. Auch eine Weiterleitung über mehr als eine Zwischenstation (genannt: „Hop“) ist so möglich.
Dezentrale IP-Adressvergabe
In einem IP-Netzwerk werden die Teilnehmer mittels sogenannter IP-Adressen angesprochen. Im Falle von IPv4, der älteren Version des Internet-Protokolls, sind dies vier Zahlen von 0 bis 255 getrennt durch Punkte, also z.B. „10.169.145.125“. Bei IPv6 kommen längere Adressen zum Einsatz, die in hexadezimaler Schreibweise notiert werden, z.B. „fdb7:5c3c:1e90:e4c1:0000:0000:00d5:85ed“. Die Punkte bzw. Doppelpunkte dienen nur der Lesbarkeit bei Darstellung in Textform und werden bei einer binären Übertragung nicht mitgesendet. Zur Vereinfachung besteht bei IPv6 die Möglichkeit, mittels eines doppelten Doppelpunktes „::“ die Auslassung mehrerer 0000-Blöcke zu kennzeichnen. Außerdem ist es möglich, führende Nullen innerhalb eines Vier-Zeichen-Blockes wegzulassen, so dass vorstehende Adresse auch verkürzt als „fdb7:5c3c:1e90:e4c1::d5:85ed“ geschrieben werden könnte.
Um eine zentrale Adressvergabe zu vermeiden, aber gleichzeitig jedem Teilnetz (einschließlich vorübergehend isolierter Netze) permanente Adressen zuweisen zu können, die dennoch mit hoher Wahrscheinlichkeit im Rahmen des Einsatzzweckes eindeutig sind, wird IPv6 genutzt. IPv6 ermöglicht es aufgrund der vergleichsweise langen Adressen, einfach einen zufälligen Adressbereich zu wählen, der dann mit großer Wahrscheinlichkeit eindeutig ist. Genau dies ist bei IPv6 im Rahmen der sogenannten „Unique Local Addresses“ (ULA) auch vorgesehen: Jede Person oder Organisation, die einen Adressbereich benötigt, erzeugt einfach eine 40 Bit lange Zufallsfolge. Wird dieser noch die Bitfolge 11111101 (hexadezimal „fd“) vorangestellt, ergeben sich 48 Bit, die den sogenannten „Präfix“ für den Adressbereich bilden. Die Person bzw. Organisation, die sich diesen Adressbereich zufällig ausgesucht hat, kann nun alle damit beginnenden Adressen beliebig verwenden, ohne große Gefahr zu laufen, mit den Adressen zu kollidieren, die andere Personen oder Organisationen verwenden. Ein solcher Präfix wird z.B. als fd4a:eeb2:7cea::/48 notiert, wobei 48 die Präfixlänge in Bits in dezimaler Schreibweise darstellt.
Die Wahrscheinlichkeit einer Kollision, d.h. die Wahrscheinlichkeit, dass in einem Netzwerk der gleiche Präfix zweimal vergeben wird, steigt zwar vergleichsweise schnell mit der Anzahl der vergebenen Präfixe (vgl. Geburtstagsparadoxon), allerdings beträgt z.B. bei 10.000 solcher miteinander vernetzten Präfixe die Kollisionswahrscheinlichkeit aufgrund der vielen Möglichkeiten (2 hoch 40 = 1.099.511.627.776) immer noch weniger als 0,05 Promille, also etwa 1:20.000. Verglichen mit anderen potentiellen Störungsursachen scheint dies vernachlässigbar klein zu sein. Die Berechnungsformeln für die Kollisionswahrscheinlichkeit sind identisch mit denen der sogenannten Geburtstagsangriffe, wobei wir hier vom wohlwollenden Verhalten aller Teilnehmer ausgehen.
Sobald ein 48-Bit langer IPv6-Adress-Präfix per Zufall ermittelt wurde, können, wie zuvor erwähnt, aus dem sich ergebenden Bereich beliebige IP-Adressen gewählt werden, z.B. die Adresse
fd4a:eeb2:7cea:0000:0000:0000:0000:0001
welche in verkürzter Schreibweise als fd4a:eeb2:7cea::1 geschrieben werden kann. Auch ist es möglich ganze Netzbereiche unterzuverteilen.
Unter Linux lässt sich dann beispielsweise diese Adresse einem Funk-Interface (hier im Beispiel tun0) wie folgt zuweisen:
ip -6 addr add fd4a:eeb2:7cea::1/128 dev tun0
Die 128 steht hierbei für eine Präfixlänge von 128 Bit, d.h. wir teilen dem Betriebssystem mit, dass zunächst keine andere Adresse via Funk erreichbar ist. Welche anderen Adressen wir tatsächlich erreichen können, wird dem Betriebssystem vom Routing-Dienst mitgeteilt, der im Folgenden beschrieben werden soll.
Der Routing-Dienst „babeld“
Sofern die Installation von „babeld“ in aktueller Version nicht durch das Paketmanagement des Betriebssystems erfolgen kann, finden sich Hinweise zum Download der Software auf der Homepage des Babel-Projektes.
Die folgenden Beschreibungen beziehen sich auf die zum Zeitpunkt der Veröffentlichung dieses Artikels aktuelle Version 1.9.2 der Software. Es gibt auch andere Routing-Software, z.B. BIRD, die das Babel-Protokoll ebenfalls umsetzen kann. Diese sollte ebenso eingesetzt werden können, ist aber anders zu konfigurieren.
Die Einrichtung von „babeld“ gestaltet sich sehr einfach. Wir legen dazu die Konfigurationsdatei /etc/babeld.conf an. Für den Fall, dass wir unseren Präfix wie im vorhergehenden Abschnitt als fd4a:eeb2:7cea::/48 festgelegt hätten (in der Praxis muss dies natürlich ein eigener, zufälliger Präfix sein), sähe die Datei wie folgt aus:
in ip fd00::/8 allow
in deny
out ip fd00::/8 allow
out deny
redistribute ip fd4a:eeb2:7cea::/48 local
redistribute ip fd4a:eeb2:7cea::/48 metric 256
redistribute local deny
redistribute deny
Den Routing-Dienst können wir dann z.B. mit folgendem Kommando starten:
babeld -c /etc/babeld.conf wl3sp0
Hierbei wäre wl3sp0 das Funk-Interface, mit dem die Vernetzung erfolgt. (Mit „ip link show“ lassen sich alle verfügbaren Interfaces anzeigen.) Wird, wie in diesem Beispiel, ein WLAN-Interface (wl3sp0) verwendet, kann babeld anhand der Hardwarekonfiguration selbst erkennen, dass eine Funkverbindung vorliegt. Wird stattdessen eine Vernetzung mittels einer schmalbandigen Verbindung über ein herkömmliches Funkgerät vorgenommen, kommt oft ein generischer TUN-Gerätetreiber zum Einsatz, bei dem die automatische Erkennung nicht möglich ist. Hier sollten wir nachhelfen, z.B. mit:
So sagen wir dem Routing-Dienst, dass es sich bei der verwendeten Netzwerkschnittstelle um eine Funkverbindung handelt („type wireless“), die sich ggf. mit anderen Funkverbindungen einen Kanal teilt („channel interfering“) und das Kommunikationsintervall für eine schonendere Bandbelegung reduziert wird („hello-interval 60“). Anstelle der Option „-C“ lässt sich der auf diese Option folgende Text („interface tun0 […]“) auch als eigene Zeile in die Konfigurationsdatei schreiben. (Details hierzu in der Anleitung von babeld.)
Falls wir Pakete für andere Funkknoten weiterleiten wollen (was ja Sinn und Zweck eines Mesh-Netzes ist), müssen wir unserem Betriebssystem noch mitteilen, dass Packet-Forwarding (also Routing) aktiviert werden soll. Dies lässt sich z.B. für IPv6 unter Linux bis zum nächsten Neustart mit folgendem Kommando einschalten:
sysctl -w net.ipv6.conf.all.forwarding=1
Soll Packet-Forwarding dauerhaft aktiviert bleiben, so ist die Datei /etc/sysctl.conf entsprechend zu bearbeiten.
Sicherheitsbedenken
Sobald wir Routing auf unserem Computer aktivieren, wird dieser beliebige Pakete weiterleiten. Es wäre dann also auch möglich, via Amateurfunk auf ein ebenfalls angeschlossenes privates Heim- oder Firmennetz (oder das Internet) zuzugreifen, was in der Regel nicht erwünscht sein wird. In einem solchen Fall ist also unbedingt eine Firewall einzurichten, deren Konfiguration hier nicht weiter behandelt werden soll und vom konkreten Szenario abhängt.
Ebenso sollte verhindert werden, dass der Routing-Dienst über Funk Einträge für unser privates Netz akzeptiert. Liegt unser privates Netz außerhalb des ULA-Adressbereiches (beginnt also nicht mit hexadezimal „fd“), dann sorgt die oben vorgestellte Konfiguration bereits automatisch dafür, dass entsprechende Routing-Informationen abgelehnt werden. Verwenden wir bei unserem privaten Heim- oder Firmennetz jedoch ebenfalls ULAs, dann müssen wir dem Routing-Dienst noch mitteilen, dass für diese Adressen keine Informationen aus dem Funknetz angenommen werden sollen. Dies lässt sich, z.B. wenn fdf2:c215:20a4::/48 unser privates Netz sei, mit der Zeile
in ip fdf2:c215:20a4::/48 deny
an oberster Stelle in der /etc/babeld.conf erreichen.
Einen zusätzlichen Filter für die ausgehende Richtung benötigen wir nicht. Wir haben bereits vermerkt, für welche Netzwerke wir Routing-Informationen einspeisen wollen („redistribute ip fd4a:eeb2:7cea::/48 […]“). Für alle anderen Netzwerke haben wir festgelegt, dass diese von babeld nicht eingespeist werden („redistribute local deny“ und „redistribute deny“).
Anbindung von weiteren angeschlossenen Geräten über den selben Funkknoten
Der Zugriff auf bestimmte lokale IP-Adressbereiche kann aber durchaus auch erwünscht sein, denn vielleicht möchten wir nicht nur ein einzelnes Gerät an das Funknetz anbinden, sondern ein ganzes Netzwerk. Die bereits erwähnte Konfigurationszeile „redistribute ip […] metric 256“ (ohne die Option „local“) ermöglicht die Einspeisung von IP-Adressen, die nicht dem eigenen Endgerät, sondern anderen Endgeräten zugehörig sind.
Die Zahl 256 gibt hier die sogenannte Metrik an, die ein Maß für die Güte der Anbindung eines Netzwerks ist. Dieser Wert ist dann von Bedeutung, wenn ein Netzwerk auf verschiedenen Wegen erreichbar ist, z.B. weil es mit mehreren Funkknoten direkt verbunden wird. Dann kann bei jedem dieser Funkknoten ein unterschiedlicher Wert für dieses Netzwerk festgelegt werden, wobei ein niedrigerer Wert für eine höhere Güte der Anbindung steht. In einfachen Fällen, also bei Netzwerken ohne Mehrfachanbindung, können wir einfach 256 festlegen.
Für die lokale Vernetzung können wir nun einen Unterbereich des Adressraumes ausweisen, z.B. fd4a:eeb2:7cea:5555::/64. Unserem eigenen Netzwerk-Interface (also z.B. unserer Netzwerkkarte) weisen wir eine IP aus diesem Unteradressraum zu und geben mit der Präfixlänge /64 an, dass weitere Adressen aus dem gleichen Unteradressraum (beginnend mit den 64 Bits fd4a:eeb2:7cea:5555) direkt zu erreichen sind. Heißt unser Netzwerk-Interface für kabelgebundenes Ethernet z.B. „enp0s25“, so wäre das Kommando hierfür:
ip -6 addr add fd4a:eeb2:7cea:5555::1/64 dev enp0s25
Andere Geräte am gleichen Ethernet-Segment können dann z.B. die Adressen mit der 2, 3, 4 usw. am Ende zugewiesen bekommen, also z.B. die fd4a:eeb2:7cea:5555::4, und sind dann aus dem Funk-Mesh-Netz erreichbar. Diesen Geräten muss jetzt nur noch mitgeteilt werden, dass Pakete an fd00::/8 (also Adressen beginnend mit „fd“) über unseren Funkknoten mit der IP fd4a:eeb2:7cea:5555::1 geroutet werden müssen, sofern für diese keine andere Route existiert. Hierzu ist das Routing der Geräte entsprechend einzustellen oder ggf. eine Default-Route zu setzen. Wie dies funktioniert, hängt vom Betriebssystem des jeweiligen Endgerätes ab. Auch ließe sich ein DHCPv6-Server verwenden, dessen Konfiguration jedoch den Rahmen dieses Artikels sprengen würde.
IPv6 und die Paketgröße (MTU)
Leider sieht IPv6 vor, dass auf jeder Verbindung mindestens Pakete der Größe 1280 Byte übertragen werden können. Dies ist die minimal mögliche Einstellung der sogenannten „Maximum Transmission Unit“ (MTU). Eine Fragmentierung, d.h. Aufteilung in kleinere Pakete, ist durch Router auf dem Transportweg bei IPv6 im Gegensatz zu IPv4 nicht vorgesehen (siehe RFC 8200, Sektion 5). Das kann zu Schwierigkeiten z.B. bei bestimmten Hardware-TNCs führen, die Pakete dieser Größe nicht handhaben können. Umgehen ließe sich dieses Problem mit einer zusätzlichen Fragmentierungsschicht, die aus Sicht von IPv6 unsichtbar sein müsste. Die von DL1PZ vorgestellten Programme ermöglichen keine zusätzliche Fragmentierung, jedoch sind die dort vorgestellten Software-TNCs Dire Wolf und pktfec-tnc ohne Probleme in der Lage, größere Pakete auf’s Band zu senden.
Skalierbarkeit
Da jeder Knoten in regelmäßigen Abständen Informationen zu allen erreichbaren Adressbereichen mit allen direkten Nachbarknoten austauschen muss, skaliert das hier vorgestellte Verfahren nicht beliebig. Mit wachsender Knotenanzahl wird die Menge an zu übertragenden Informationen ebenfalls wachsen. Bei langsamen Packet-Radio-Verbindungen dürften bereits bei einer zweistelligen Anzahl von Netzknoten Probleme auftreten. Weniger problematisch wäre dies bei einer Vernetzung mit schnellerer Technik.
Um dieses Problem zu lösen bzw. zu umgehen, sehe ich verschiedene Alternativen:
Mesh-Netze bleiben lokal begrenzt und werden mit anderen Mesh-Netzen ausschließlich manuell verbunden. Routing-Informationen zu anderen Mesh-Netzen werden nur für das gesamte jeweils andere Mesh-Netz in das eigene Mesh-Netz eingespeist, so dass jedes andere Mesh-Netz nur mit einem einzigen Präfix in den Routing-Tabellen auftaucht, was die Routing-Tabellen kleiner hält. Damit dies funktioniert, müssten die einzelnen lokalen Mesh-Netze jedoch jeweils einen gemeinsamen Präfix verwenden und sich dann auf eine Vergabemethode von IP-Adressen innerhalb ihres jeweiligen Präfixes einigen.
Mesh-Netze bleiben lokal begrenzt und werden untereinander über sogenannte Border-Router und ein Backbone verbunden. Routing-Informationen zu anderen Mesh-Netzen werden gar nicht im eigenen Mesh-Netz verbreitet. Stattdessen werden die Border-Router als zuständig für den Bereich fd00::/8 angegeben.
Das Routing-Protokoll wird erweitert (bei Babel grundsätzlich vorgesehen), oder ein anderes, zukünftiges Routing-Protokoll wird benutzt, das solche Szenarien noch besser abbilden kann.
Fazit und Ausblick
Es macht Spaß, mit Ad-hoc-Vernetzung zu experimentieren. IPv6 ermöglicht es, ohne zentrale Koordinierung feste IP-Adressen zu verwenden. Mit dem Routing-Protokoll Babel bzw. der Software „babeld“ und IP-Packet-Forwarding können wir eine automatische Vernetzung vornehmen lassen. Inwieweit sich diese Verfahren im größeren Maßstab in der Praxis, insbesondere bei langsamen Packet-Radio-Verbindungen, einsetzen lassen, bleibt zu erforschen.
Wenn im Zusammenhang mit dem Amateurfunk von IP-Vernetzung die Rede ist, werden viele sicherlich zuerst an das HAMNET denken, ein Hochgeschwindigkeitsnetzwerk auf IP-Basis. Doch darum soll es in diesem Artikel gar nicht gehen. Denn obwohl die Möglichkeiten des HAMNET, insbesondere die verfügbaren Datenraten, überzeugend sind, gibt es doch einige praktische Einschränkungen. Die vermutlich größte Hürde in das HAMNET einzusteigen sind die Ausbreitungseigenschaften des hierfür verwendeten 2,4 GHz-Bandes. Ohne direkten Sichtkontakt geht da nicht viel. Das heißt in der Praxis: Eine flächendeckende Versorgung mit HAMNET steht in ländlichen genauso wie städtischen Gebieten noch in den Sternen, obwohl bereits ein erheblicher Aufwand getrieben wurde, um sogenannte Benutzereinstiege bereitzustellen. Auch der neuerdings zusätzlich verfolgte Ansatz mit Breitbanddatenübertragungen auf dem 70cm-Band mittels NPR70 findet seine Grenzen in dem knappen zur Verfügung stehenden Frequenzspektrum, das sich viele Anwendungen teilen müssen.
Deshalb haben Silvio DM9KS, Jan DL9JBE und Björn DL1PZ in den letzten zwei Jahren diverse Versuche zur IP-Vernetzung unternommen und dabei “normale” Funkkanäle verwendet. Es wurden FM-Verbindungen mit 7 bzw. 12,5 kHz Kanalbreite auf dem 10m-, dem 2m- und dem 70cm-Band genutzt. Die dort erreichbaren Datenraten kommen natürlich nicht an die Geschwindigkeiten des HAMNET heran. Dafür sind aber IP-Verbindungen auch unter wesentlich widrigeren Funkbedingungen überhaupt herstellbar. In diesem Artikel sollen die verschiedenen Hard- und Softwarekomponenten bzw. Protokolle vorgestellt werden, die im Rahmen der Versuche erprobt wurden.
Schematischer Versuchsaufbau
Versuchsaufbau
Der grundsätzliche technische Aufbau folgte stets dem gleichen Schema. Eine oder mehrere IP-fähige Anwendungen (z. B. IRC-Chatprogramme, Telnet, Schachprogramme, usw.) erzeugen IP-Datenpakete. Diese werden durch einen Einpacker um ein Rufzeichen und Protokollinformationen ergänzt an einen Terminal Node Controller (TNC) weitergegeben, der die Datenpakete für die Übertragung auf dem Band vorbereitet und dann über eine Audioschnittstelle an einen Transceiver übergibt. Empfangene Übertragungen werden andersherum durch den Transceiver über die Audioschnittstelle an den TNC zur Dekodierung übergeben. Dann werden Rufzeichen und Protokollinformationen durch den Auspacker entfernt und die empfangenen Nutzdaten als IP-Paket (über das Betriebssystem) an die IP-Anwendung weitergegeben.
In dem immer gleichen Schema war – neben der Verwendung von IP – die Konstante bei allen Versuchen das sogenannte KISS-Protokoll, auf das später noch eingegangen wird. Alle anderen Komponenten wurden in den Versuchen durch wechselnde Hard- bzw. Software implementiert.
AX.25
Der älteste Vertreter der Lösungen zur IP-Vernetzung über den Amateurfunk ist das AX.25-Protokoll. Dieses ursprünglich für Packet-Radio geschaffene Protokoll bringt auch die Möglichkeit des Transports von IP-Paketen mit. AX.25 ist ein umfassendes Netzwerkprotokoll, das selber auch ganz ohne IP-Netzwerk in der Lage ist, Computer und angebotene Dienste (wie Mailboxen) zu verbinden. Bis zum Ende des letzten Jahrtausends wurde es bei Funkamateuren rege genutzt und es bestand praktisch flächendeckender Zugang zum Packet-Radio-Netzwerk über Funk.
Das Protokoll enthält eine Vielzahl an Funktionen, z. B. zu Multiplexing, Flusskontrolle oder Routing, die für die IP-Vernetzung jedoch keine Rolle spielen. Diese Aspekte werden bereits von IP (bzw. genau genommen TCP/IP) selber gelöst. Daher beschränkt sich dieser Artikel auf die für den Anwendungsfall relevanten Teile von AX.25.
Im Folgenden wird nur der Sendeweg beschrieben. Der Empfangsweg verhält sich entsprechend genau andersherum. Das heißt die sendeseitig hinzugefügten Informationen werden in umgekehrter Reihenfolge wieder entfernt bzw. die vor der Aussendung vorgenommene Modulation wird entsprechend demoduliert.
AX.25 definiert gleich zwei der im schematischen Aufbau dargestellten Komponenten: Den Ein- und Auspacker für IP-Pakete sowie den TNC (aber nicht das Modem). Im AX.25-Protokoll ist diese Aufgabentrennung zwar überhaupt nicht vorgesehen, doch in der Praxis ist sie weit verbreitet. Auch das KISS-Protokoll ist nicht Teil von AX.25, doch dazu – wie schon versprochen – später mehr.
Bei den ersten Versuchen wurde die in Linux eingebaute AX.25-Unterstützung verwendet, um IP-Pakete ein- bzw. wieder auszupacken. Praktisch passiert dabei folgendes: Zu jedem IP-Paket, das auf die Funkschnittstelle gesendet werden soll, werden zunächst zusätzliche Informationen hinzugefügt, bevor das Paket an den TNC übergeben wird. Hierzu werden zwei der durch AX.25 spezifizierten Funktionalitäten genutzt, nämlich die Adressierung und die Protokollidentifikation.
Rufzeichen und Protokollidentifikation
AX.25 verwendet Amateurfunkrufzeichen, um den Absender und den oder die Empfänger einer Übertragung anzugeben. Zur Unterscheidung mehrerer Stationen des gleichen Rufzeicheninhabers ist es vorgesehen, optional eine Zahl von 1 bis 15 als sogenannten „Secondary Station Identifier“ („SSID”) anzuhängen, z. B. DL1PZ-14. Die Kodierung des Rufzeichens erfolgt als 7-Bit-ASCII-Zeichenkette, wobei das jeweils freibleibende 8. Bit anderweitig genutzt wird. Die Erzeugung und Verarbeitung gestaltet sich daher etwas komplizierter, zudem die sieben ASCII-Bits auch noch um ein Bit zur Seite verschoben werden. AX.25 beschränkt die Länge der Rufzeichen strikt auf 6 Zeichen, was die Verwendung von längeren Rufzeichen (z. B. Sonderrufzeichen) leider vollkommen unmöglich macht. AX.25 sieht als Adressangabe mindestens eine Absender- und eine Zieladresse vor.
In der AX.25-Konfiguration von Linux wurde jeweils das eigene Rufzeichen hinterlegt. Dieses wird dann automatisch zu jedem Paket hinzugefügt. Da AX.25 zwingend auch eine Empfängeradresse vorschreibt, welche jedoch für die IP-Vernetzung nicht nötig ist, wird das entsprechende Feld durch Linux automatisch mit dem Text “QST” belegt. Diese Q-Gruppe steht in CW für eine Sendung an alle Stationen.
Weiterhin setzt AX.25 noch einen sogenannten “Protocol identifier” (“PID”) vor die eigentlichen Nutzdaten. Im behandelten Falle, also der Übertragung von IP-Paketen, wird hier hexadezimal 0xCC für IPv4 vermerkt. Ein PID für IPv6 ist in der letzten Version 2.2 des AX.25-Standards nicht vorgesehen. Dementsprechend kann mit diesem Ansatz auch keine Vernetzung per IPv6 sondern nur per IPv4 vorgenommen werden.
PicoAPRS – TNC und Transceiver in einem Gerät
KISS-Protokoll
Nachdem nun diese beiden Informationen hinzugefügt wurden, wird das Datenpaket an den TNC weitergegeben. Dazu wird das schon erwähnte KISS-Protokoll verwendet, meist über eine serielle Schnittstelle. Dieses ist mit dem SLIP-Protokoll verwandt, bei dem bestimmte Steuerzeichen einen seriellen Datenstrom in einzelne Pakete unterteilen. Die Abkürzung KISS bezieht sich hier auf das sogenannte KISS-Prinzip, Dinge einfach zu halten (engl. “Keep it simple, stupid!”, zu Deutsch also “Halte es einfach, Dummerchen!” oder etwas sachlicher formuliert: “Mach’ eine Sache nicht komplizierter als nötig”). Entsprechend ist das Protokoll auch überschaubar definiert. Am Anfang und am Ende der Übertragung wird jeweils ein Byte mit dem hexadezimalen Wert 0xC0 als Begrenzung eines Datenpakets angefügt. Sofern in den Daten selber der Wert 0xC0 vorkommt, wird dieser durch die Bytefolge 0xDB 0xDC ersetzt. Wenn wiederum ein 0xDB vorkommt, wird dieses durch die Folge 0xDB 0xDD ersetzt.
TNC für AX.25
Die Aufgabe des TNC ist es nun, das Datenpaket für die Übertragung auf der Funkschnittstelle vorzubereiten. Ein für AX.25 ausgelegter TNC erledigt dabei zunächst die folgenden Aufgaben:
Bitstopfen (engl. “bit stuffing”): Das Einfügen von einem oder mehreren Füll-Bits in einen Datenstrom. Im Falle von AX.25 konkret das Einfügen eines zusätzlichen 0-Bits, falls fünf 1-Bits unmittelbar aufeinander folgen.
Rahmensynchronisation: Dient dem Erkennen von Anfang und Ende eines AX.25-Datenpakets (streng genommen gemäß OSI-Schichtmodell als “Datenframe” zu bezeichnen). Konkret beginnt und endet jedes AX.25-Datenframe mit der Bit-Folge 01111110 (hexadezimal 0x7E). Daher auch das vorgenannte Bitstopfen, das sicherstellt, dass diese Sequenz niemals innerhalb der tatsächlich übertragenen Nutzdaten vorkommt, sondern nur als Rahmensynchronisation.
Fehlererkennung: Das Erkennen von Übertragungsfehlern (z. B. aufgrund von Störungen auf dem Band) durch den Empfänger. Hierzu fügt der Sender im Falle des AX.25-Protokolls vor dem Ende eines jeden Datenframes (unmittelbar vor der Rahmensynchronisation) eine Prüfsumme ein, die vom Empfänger kontrolliert werden kann.
Als letzten Schritt der Vorbereitung führt das im TNC integrierte Modem nun die Modulation durch. Dieser Schritt ist nicht mehr Teil der AX.25-Spezifikation. Aus der langjährigen Praxis des Betriebs von Packet-Radio haben sich jedoch zwei Varianten der Modulation herauskristallisiert: Einerseits AFSK mit 1200 Baud entsprechend des Half-Duplex-Modus der Bell-202-Modem-Spezifikation und andererseits FSK mit 9600 Baud nach G3RUH. Praktisch alle Hardware-TNCs unterstützen eines dieser beiden Verfahren. Software-Lösungen bieten hingegen neben diesen beiden Verfahren auch noch eine Reihe weiterer Modulationsarten.
Anschluss an das Funkgerät
Für die Verbindung zwischen dem TNC und dem Funkgerät wird eine herkömmliche analoge Audioverbindung genutzt. Fast jedes Funkgerät verfügt über einen Anschluss für Mikrofon und externen Lautsprecher, welche mit dem TNC verbunden werden können. Im Falle von Software-TNCs ist entsprechend die Soundkarte des Computers mit dem Funkgerät zu koppeln.
Manche hochwertigere Funkgeräte verfügen auch über einen sogenannten 9600-Port. Dieser bietet einen Ein- und Ausgang für Audiosignale, bei denen das Signal jedoch an den üblichen NF-Filtern (Bandpass) vorbeigeführt wird und somit ein größeres Frequenzspektrum durchgelassen werden kann. Der Verzicht auf Filter vermeidet außerdem ein nichtlineares Verhalten hinsichtlich des Phasenganges und stellt damit eine einheitliche Verzögerung des gesamten Signals unabhängig von den übertragenen NF-Frequenzen sicher. Mit einem 9600-Port ist es einfacher, hohe Datenübertragungsraten zu erreichen. Dieser Anschluss ist die Voraussetzung für die Verwendung eines 9600-Baud-Modems nach G3RUH.
Ein Baofeng UV-5R mit Audio-Datenkabel
Audiopegel
Grundsätzlich gilt: Der Audioausgang des TNCs oder – im Falle eines Software-TNCs – des Computers ist mit dem Audioeingang des Funkgeräts und andersherum der Audioausgang des Funkgeräts wiederum mit dem Audioeingang von TNC bzw. Computer zu verbinden.
In der Praxis hat es sich als sehr wichtig herausgestellt, die Audio-Lautstärke in beide Richtungen korrekt einzupegeln. Sendeseitig sollte die in das Funkgerät eingegebene Audiolautstärke so gewählt sein, dass sie so laut wie möglich ist ohne das es zu Verzerrungen des Signals kommt. Bei Geräten mit eingebautem Audio Level Controller (ALC) kann dies leicht erreicht werden, indem die Lautstärke soweit angehoben wird, dass die ALC-Anzeige gerade so nicht ausschlägt. Empfangsseitig sollte die Lautstärke so eingestellt werden, dass die empfangenen Signale keinesfalls übersteuern.
Verbesserungspotential von AX.25-TNCs
Bei den Versuchen wurden unterschiedliche AX.25-TNCs verwendet. Eine Besonderheit war dabei der PicoAPRS, der TNC und Transceiver zu einem winzigen Gerät vereint. Als reine Software-Lösung kam immer wieder Dire Wolf zum Einsatz.
Leider sieht AX.25 für die Fehlererkennung lediglich eine 2 Byte lange CRC-Prüfsumme vor. Diese erlaubt es mit relativ hoher Wahrscheinlichkeit, eine fehlerhafte Übertragung als solche zu erkennen. Die Möglichkeit einer Fehlerkorrektur, weil z. B. der Kanal kurz gestört war, erlaubt dies aber nur sehr eingeschränkt. Der technische Stand dazu hat sich seit der Spezifikation von AX.25 aber deutlich weiterentwickelt.
So unterstützt der Software-TNC Dire Wolf schon seit einiger Zeit eine Fehlerkorrektur mittels Reed-Solomon-Codes. Diese Fehlerkorrektur kommt in einem zu AX.25 rückwärtskompatiblen Kodierungsverfahren mit der Bezeichnung FX.25 zum Einsatz. Dem aktuellen Stand der Technik entspricht dies jedoch auch noch nicht.
Ein heute übliches Verfahren zur Fehlererkennung und auch -korrektur sind sogenannte Low-Density-Parity-Check-Codes (LDPC), die z. B. bei DVB-S2 oder FT8 verwendet werden. Jan DL9JBE hat sich mit diesem Verfahren näher beschäftigt und dabei die experimentelle Software pktfec-tnc entwickelt. Das ist ein Software-TNC, der dieses Verfahren zur Fehlerkorrektur einsetzt. Da pktfec-tnc ebenfalls die KISS-Schnittstelle verwendet, kann es einfach anstelle eines AX.25-TNC verwendet werden. Als Modulation zur Übergabe per Audiokanal an das Funkgerät wird Quadraturamplitudenmodulation (QAM) verwendet, welche hinsichtlich Symbolrate (Baudrate) und Symbolanzahl (Bits je Symbol) relativ frei konfiguriert und somit an die Kanaleigenschaften angepasst werden kann. Die genauen technischen Hintergründe hat Jan im Artikel Schnellere Datenübertragung ohne Data-Port beschrieben. Praktisch gibt es also mehrere Methoden wie sich das AX.25-typische Ein- und Auspacken von IP-Paketen mit einem modernen TNC verbinden lässt.
Einschränkungen von AX.25
Aber auch bei der Verwendung von AX.25 für das Ein- und Auspacken von IP-Paketen stellten sich einige praktische aber auch theoretische Probleme. Wie bereits erwähnt unterstützt AX.25 ausschließlich IPv4 und ist nicht auf IPv6 vorbereitet. Das ist auch nicht verwundernswert, da das letzte Update des AX.25-Standards aus dem Jahre 1998 stammt, dem gleichen Jahr in dem IPv6 erstmals spezifiziert wurde. Leider scheint AX.25 IP-Datenpakete praktisch auch auf eine maximale Länge von 255 Bytes zu beschränken. Dies würde die Ergänzung einer IPv6-Unterstützung erschweren. Denn IPv6 verlangt, dass jeder Übertragungsweg darauf vorbereitet ist, Pakete mit 1280 Byte Länge zu unterstützen. Es wäre also nötig, einen neuen Mechanismus zur Aufteilung größerer Datenpakete in mehrere Teilpakete zu implementieren.
Bei der Adressierung ist AX.25 für den vorgesehenen Anwendungsfall nur eingeschränkt geeignet bzw. ineffizient. Eigentlich wird nur eine Angabe das Rufzeichens der Sendestation benötigt. AX.25 verlangt jedoch zusätzlich auch zwingend die Angabe eines Zielrufzeichens. Neben der erwähnten unpraktischen um ein Bit verschobenen Kodierung kommt erschwerend noch hinzu, dass AX.25 für das Absender- wie Empfängerrufzeichen jeweils eine feste Breite von 6 Zeichen zuzüglich SSID vorsieht und dafür jeweils 7 Byte benötigt. Das führt einerseits dazu, dass auch bei kurzen Rufzeichen stets 14 Byte für die Adressierung verbraucht werden. Anderseits macht es die Nutzung von Sonderrufzeichen unmöglich, die länger als 6 Zeichen sind.
Abschließend sei noch erwähnt, dass keine Umsetzung von AX.25-IP-Vernetzung für andere Betriebssysteme als Linux gefunden werden konnte. Damit war dann z. B. das von DL9JBE benutzte FreeBSD außen vor. Eine Portierung erschien aufgrund der Mängel hinsichtlich IPv6 und der Adressierung sowie der Gesamtkomplexität des Standards nicht vielversprechend.
Debugging von IP-Verbindungen mit dem Netzwerkanalyse-Werkzeug Wireshark
Alternativen zum Verpacken von IP-Paketen
Eine weitere Möglichkeit zum Ein- und Auspacken der IP-Pakete ist tncattach, welches auf einfache Art und Weise die beiden Aufgaben der Rufzeichennennung und Protokollidentifikation übernimmt und die Daten per KISS-Protokoll an einen TNC weiterreicht. Um IPv4 bzw. IPv6-Pakete zu kennzeichnen, stellt tncattach die zwei Byte lange Markierung gemäß dem Ethernet-Standard IEEE 802.3 vor jedes Paket, also hexadezimal 0x08 0x00 für ein IPv4- und 0x86 0xDD für ein IPv6-Paket. Es werden vorab noch 2 weitere Bytes hinzugefügt, die Linux-spezifisch definiert sind, deren genauer Zweck sich im Rahmen der Versuche nicht erschlossen hat. Die Rufzeichennennung erfolgt bei tncattach nicht in jedem Paket. Stattdessen werden von Zeit zu Zeit separate Datenpakete erzeugt, die nur das Rufzeichen erhalten. Das bietet den Vorteil, dass bei jeder Übertragung einige Byte eingespart werden können.
Die Software tncattach ist für die reine IP-Vernetzung gegenüber AX.25 als Fortschritt anzusehen. Die Funktionalität beschränkt sich weitgehend auf die IP-Vernetzung (zusätzlich ist auch die Vernetzung auf Ethernet-Ebene möglich) und IPv6 wird unterstützt. Rufzeichen werden ohne Bitverschiebung kodiert, also im Klartext. Es ist nur das Rufzeichen der Sendestation anzugeben und lange Sonderrufzeichen stellen auch kein Problem dar.
Nicht so gut gefallen hat, dass das Rufzeichen nicht in jedes Paket einkodiert wird. Rein formal wird das die Verpflichtung zur Rufzeichennennung im Amateurfunk möglicherweise erfüllen. Zumindest praktisch ist es so aber nicht ohne weiteres möglich, jede Sendung klar zuzuordnen. Es ist nicht erkennbar, welches IP-Datenpaket zu welchem Rufzeichen-Paket gehört. Eine Zuordnung wie im Sprechfunk anhand der Stimme ist ja nicht möglich.
Als größter Nachteil wurde allerdings festgestellt, dass tncattach ausschließlich für Linux entwickelt wird. Nach einer kurzen Betrachtung des Quellcodes ist der Eindruck entstanden, dass eine Portierung auf andere Betriebssysteme bisher leider nicht vorgesehen ist.
hamtunnel
Eine weitere Alternative zum Verpacken von IP-Paketen hat Jan DL9JBE als Ergänzung zu pktfec-tnc implementiert und dabei folgende Design-Kriterien zugrunde gelegt:
Unterstützung für Linux und FreeBSD
Kompatibilität zum KISS-Protokoll, um bestehende TNCs nutzen zu können
Einfaches Protokoll, das leicht für den Menschen lesbar ist
Rufzeichennennung in jedem Paket im Klartext
Unterstützung beliebig langer Rufzeichen (auch z. B. Rufzeichen aus dem CB-Funk oder anderen Funkdiensten)
Die Software heißt hamtunnel und ist kann zusammen mit pktfec-tnc heruntergeladen werden. Genauso wie AX.25 und tncattach übernimmt hamtunnel die Anreicherung von IP-Paketen um eine Protokollinformation und das Rufzeichen. Dazu wird vor jedes Datenpaket als erstes das Rufzeichen in beliebiger Länge im ASCII-Klartext vorangestellt und mit einem Null-Byte (also hexadezimal 0x00) abgeschlossen. Es folgt dann die Markierung des IP-Protokolls im Klartext. Konkret wird die Zeichenfolge “IP4” bzw “IP6” verwendet, die sich von selber erklären dürften. Auch diese Sequenz wird mit einem Null-Byte abgeschlossen. Im Anschluss folgt unverändert das eigentliche IP-Paket.
Lesbarkeit von Daten für den Menschen
Die Lesbarkeit von Daten für den Menschen ist dabei ein interessanter Punkt, der hier noch etwas weiter ausgeführt werden soll. Viele Datenformate machen es leider schwer, Rohdaten ohne Spezialsoftware zu betrachten und zu verstehen. Das soll hier an einem Vergleich üblicher Datenpakete von AX.25 und hamtunnel dargestellt werden. Dazu wird jeweils der Anfang eines typischen Datenpaket wiedergegeben, wie es von einem TNC empfangen wurde. Es handelt sich dabei jeweils um ein IPv4-Paket, gesendet von der Station DL1PZ. Dabei werden druckbare ASCII-Zeichen als Text dargestellt und nicht-druckbare Zeichen als Hexadezimalzahl nach dem Muster <00>. In Fettschrift wird das Rufzeichen und die Protokollinformation hervorgehoben.
Im Falle von AX.25 ist praktisch überhaupt nicht zu erkennen, was für Daten vorliegen. Die Sequenz <88><98>b<a0><b4> ist übrigens DL1PZ in ASCII-Kodierung um ein Bit nach links verschoben und das Byte <cc> steht für IPv4. Die Kodierung von hamtunnel hingegen lässt das Rufzeichen leicht erkennen und gibt mit “IP4” einen klaren Hinweis darauf, welche Art von Daten anschließend zu erwarten sind. Zumindest für alle mit Programmiererfahrung ist das Null-Byte <00> leicht als Trennzeichen zu identifizieren. Die anschließend folgenden IPv4-Daten sind (genauso wie IPv6) leider nicht für den Menschen lesbar, da bei IP die Kopfdaten stets binär kodiert werden.
Die Früchte der Arbeit: IP-basierter IRC-Chat auf 144,850 MHz im Channel #2m-talk
Fazit
Viele Wege führen zum Ziel. Zum Vorbehandeln der IP-Pakete mit Rufzeichen und Protokollinformationen können AX.25, tncattach oder hamtunnel genutzt werden. TNCs gibt es in Hardware, wie der PicoAPRS, und in Software, wie Dire Wolf oder pktfec-tnc, teils mit klassischer AX.25-Kodierung, teils mit moderneren Verfahren. Bei der Modulation ermöglichen die TNCs neben Klassikern wie 1200-Baud-AFSK gemäß Bell-202 oder 9600-Baud nach G3RUH viele weitere Verfahren. Dank KISS-Protokoll lassen sich die Komponenten beliebig kombinieren.
Eines darf dabei aber nicht vergessen werden: Nur wenn alle beteiligten Stationen exakt die selbe Art verwenden um IP-Pakete einzupacken, für die Übertragung vorzubereiten und zu modulieren ist ein erfolgreicher Datenaustausch möglich. Denn die Verfahren sind nicht untereinander kompatibel. Das ist leider ein Dilemma. Denn entweder verwenden wir möglichst etablierte (“gut abgehangene”) Verfahren wie AX.25 mit 1200-Baud-AFSK-Übertragung und bleiben auch mit alten Hardware-TNCs kompatibel – oder wir verzichten auf die Abwärtskompatibilität und setzen auf neuere Verfahren mit eleganteren Protokollen und moderner Fehlerkorrektur.
Login
