PR-Digi mit Direwolf - Versionsgeschichte

IN3FQQ: AXUDP Troubleshooting mit Wireshark

2025-10-25T07:10:52Z

AXUDP Troubleshooting mit Wireshark

@@ Zeile 120: / Zeile 120: @@
 In diesen Fällen ist es am besten, sich mit einem HAMNET-Sysop zu besprechen.
 [[Kategorie:HAMNET]]
 [[Kategorie:Digitaltechnik]]

IN3FQQ: /* Packet-Router (X)Net */

2025-08-26T13:13:59Z

Packet-Router (X)Net

← Nächstältere Version		Version vom 26. August 2025, 13:13 Uhr
Zeile 69:		Zeile 69:
	Als Packet Node Software bzw. Router ist (X)Net im Einsatz. Dieses ist auch auf neueren Plattformen noch Lauffähig.		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.		Die Anbindung zwischen Direwolf 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.		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.

IN3FQQ am 26. August 2025 um 13:06 Uhr

2025-08-26T13:06:18Z

← Nächstältere Version		Version vom 26. August 2025, 13:06 Uhr
Zeile 88:		Zeile 88:

	Wildcards o.Ä. können keine angegeben werden.		Wildcards o.Ä. können keine angegeben werden.



Zeile 95:		Zeile 96:

	Da für (X)Net nun alle Verbindungen "''vom konfigurierten AXUDP-Partner 127.0.0.1 kommen''", ist (X)Net zufrieden.		Da für (X)Net nun alle Verbindungen "''vom konfigurierten AXUDP-Partner 127.0.0.1 kommen''", ist (X)Net zufrieden.



Zeile 100:		Zeile 102:

	Die Verwendung ist also gleich, wie bei Usern die via RF ankommen würden.		Die Verwendung ist also gleich, wie bei Usern die via RF ankommen würden.

			Für Troubleshooting-Zwecke kann ''udphub'' mit der option <code>-w</code> angewiesen werden, einen Log der letzten bekannten AXUDP-Verbindungen (sozusagen den "Switching-Table") in eine Datei (z.B. <code>/tmp/udphub.log</code>) zu schreiben.

	# Port fuer AXUDP User-Zugang		# Port fuer AXUDP User-Zugang
Zeile 108:		Zeile 112:
	# Somit koennen ueber diesen Port auch Stationen connected werden		# 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 &		./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'''.		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'''.

IN3FQQ am 26. August 2025 um 13:03 Uhr

2025-08-26T13:03:23Z

← Nächstältere Version		Version vom 26. August 2025, 13:03 Uhr
Zeile 117:		Zeile 117:

	In diesen Fällen ist es am besten, sich mit einem HAMNET-Sysop zu besprechen.		In diesen Fällen ist es am besten, sich mit einem HAMNET-Sysop zu besprechen.
			[[Kategorie:HAMNET]]
			[[Kategorie:Digitaltechnik]]

IN3FQQ: Erste Beschreibung des Setups mit Multibaud + AXUDP Userzugang

2025-08-26T13:02:46Z

Erste Beschreibung des Setups mit Multibaud + AXUDP Userzugang

Neue Seite

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 [https://github.com/wb2osz/direwolf 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 <code>-T host:port</code>) mit den verschiedenen TCP-KISS Ports am lokalen Host verbinden und ihrerseits UDP-Ports (option <code>-U host:tx-port:rx-port</code>) 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 [https://dxlwiki.dl1nux.de/index.php?title=Udpflex 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.

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