+- LK0NOD - Forum - Community - CB Funk 11m (https://lk0nod.de/forum)
+-- Forum: PACKET RADIO (https://lk0nod.de/forum/forum-193.html)
+--- Forum: TNC2 Tool Linux (Python) (https://lk0nod.de/forum/forum-284.html)
+--- Thema: TNC2 Tool Linux (Python) (/thread-1099.html)
TNC2 Tool Linux (Python) - 13LS194 - 12.08.2026
Hallo liebe Packet Freunde,
habe mal aus Interesse ein kleines, Hostmodefähiges Tool in Python erstellt.
Da ich selbst kein Programmierer bin, ist es größtenteils unter Zuhilfenahme von KI entstanden.
Kurze Eckdaten:
Basis ist das Programm "TNT" (open Source, GPL2.0) unter Linux.
Das wurde insbesondere in Sachen TNC Steuerung auf Python portiert.
Man kann damit klassische TNC2 Hardware (Nordlink TF) ansteuern. (direkt Seriell oder über USB Adapter)
Die TNC Konfiguration, Administration oder der Terminalbetrieb kann bequem in der GUI vorgenommen werden.
Praktisch getestet wurde in Feldtests mit GPv1.61b. (DOS) und einer gleichen Programmversion des Terminaltools sowie des Nodetools als Gegenstelle.
Meiner Meinung nach eine gute Möglichkeit, alte TNCs schnell und User friendly unter Linux (im original Hostmode, ohne KISS) zum laufen zu bekommen. (Inklusive kleiner Spielereien ;))
Genaue Beschreibung weiter unten, probierts aber gerne selbst aus.
Es wurde mittlerweile eine kleine Softwarefamilie daraus, mit neuen Ideen und Möglichkeiten.
Es gibt z.B. ein Tool für einen Node (ist aktuell als v2.5 mit dabei), sowie Experimente für eine interaktive Shell, ein xterm/VT100 Terminaltool sowie ein Mail Gateway Tool.
Die Tools sind alle portabel aufgebaut, das normale Terminaltool sollte sogar unter Windows laufen.
Alles basierend auf dem portierten TNT Kern des ursprünglichen Tools.
Über Rückmeldungen, insbesondere Bugreporte, würde ich mich sehr freuen.
Die Tools stehen hier als Quellcode zum Download zur Verfügung.
Zum ausführen reicht eine Python Installation mit Tkinter und Pyserial.
73
Marco
RE: TNC2 Tool Linux (Python) - 13LS194 - 22.08.2026
Klassisches Packet Radio mit moderner Software – Terminal, Node und neue interaktive Möglichkeiten
In den letzten Wochen sind mehrere Werkzeuge entstanden, die klassische Packet-Radio-Technik mit den Möglichkeiten eines modernen Rechners verbinden.
Im Mittelpunkt stehen dabei aktuell zwei Programme: das Terminal Tool für den direkten Betrieb einer Packet-Radio-Station und das Node Tool für den Betrieb eines zentralen Packet-Radio-Nodes mit mehreren Benutzern und zusätzlichen Diensten.
Die Grundidee hinter beiden ist bewusst klassisch:
Der TNC bleibt der TNC.
Ein TNC2 beziehungsweise dessen Derivate mit TheFirmware übernehmen weiterhin die eigentliche AX.25- und Funkkommunikation. Verbindungsaufbau, Frames, Wiederholungen, Quittungen und der Zugriff auf den Funkkanal bleiben damit in der klassischen Hardware.
Der Rechner kommuniziert über den WA8DED-/TheFirmware-Hostmode mit dem TNC und übernimmt die Aufgaben, die sich auf einem heutigen System wesentlich komfortabler und flexibler realisieren lassen.
Historische Wurzeln: TNT in einer modernen Python-Umgebung
Die technische Basis entstand dabei nicht völlig auf der grünen Wiese.
Ein wichtiger Ausgangspunkt ist das historische TNT Packet-Radio-Terminal von Mark Wahl, DL4YBG. TNT war ein unter Linux entwickeltes Hostmode-Terminal für WA8DED-/TheFirmware-TNCs und wurde ursprünglich in C geschrieben.
Teile dieser bewährten Codebasis und der dahinterliegenden Hostmode-Logik wurden für die heutigen Werkzeuge nach Python portiert und übernommen.
Darauf aufbauend wurde die Software zunehmend neu strukturiert, erweitert und an heutige Anforderungen angepasst. Aus der ursprünglich monolithischeren Terminalwelt entstand so nach und nach eine Python-basierte Architektur mit klar getrennten Komponenten für TNC-Kommunikation, Benutzeroberfläche und Anwendungen.
Die Verbindung zum historischen TNT ist damit durchaus gewollt:
Bewährte Packet-Radio-Technik wurde nicht neu erfunden, sondern in eine moderne Codebasis übertragen und von dort aus weiterentwickelt.
Gerade bei Dingen wie WA8DED-Hostmode, Mehrkanalbetrieb, Terminalkommunikation und AutoBIN steckt damit auch ein gutes Stück historisch erprobter Packet-Radio-Technik in den heutigen Werkzeugen.
Das Terminal Tool
Das Terminal Tool ist für den direkten Packet-Radio-Betrieb einer Station gedacht.
Es kommuniziert mit einem klassischen TNC2-kompatiblen Gerät im WA8DED-/TheFirmware-Hostmode und verwaltet mehrere logische AX.25-Kanäle.
Neben normalen Connects und QSOs gehören unter anderem kanalbezogene Ein- und Ausgabe, Linkstatus, Monitorinformationen und die laufende Kommunikation mit dem TNC dazu.
Dabei sind grafische Oberfläche, TNC-Kommunikation und die darüberliegenden Anwendungen bewusst voneinander getrennt.
Das Terminal Tool besitzt außerdem kontrollierte Remote-Funktionen. Eine verbundene Gegenstation kann darüber auf bestimmte freigegebene Funktionen und einen dafür vorgesehenen Dateibereich zugreifen, ohne dadurch beliebigen Zugriff auf das lokale Dateisystem zu erhalten.
Ein weiterer wichtiger Bestandteil ist AutoBIN.
Dateien können mit klassischem AutoBIN einschließlich Dateigröße, Dateiname und CRC übertragen werden. Dabei wird auch der verfügbare Pufferspeicher des TNC berücksichtigt.
Auf der Empfangsseite wird eine Datei erst nach vollständiger Übertragung und erfolgreicher CRC-Prüfung als reguläre Datei übernommen.
Gerade bei langsamen realen Funkverbindungen spielen Details wie Puffersteuerung, lokale TNC-Bestätigungen, Retries, Disconnects und ein sauberer Umgang mit abgebrochenen Transfers eine wichtige Rolle.
Spiele über Packet Radio
Zusätzlich besitzt das Terminal Tool inzwischen ein modulares grafisches Spielesystem.
Aktuell sind unter anderem Schach und Schiffe versenken integriert.
Die eigentlichen Spiele sind dabei vom Funktransport getrennt. Ein gemeinsamer Unterbau kümmert sich um Dinge wie Einladung, Sessionverwaltung, Game-ID, ACKs, Retries, Disconnect, Aufgabe und Abbruch.
Beim Schach kennen beide Stationen den gemeinsamen Brettzustand und prüfen die empfangenen Züge jeweils selbst.
Bei Schiffe versenken bleiben dagegen die eigenen Schiffspositionen lokal geheim. Über Funk werden lediglich Schüsse, Ergebnisse und die dafür notwendigen Bestätigungen ausgetauscht.
Während einer laufenden Partie erhält der Spielverkehr global Vorrang. Normale Programmaussendungen und AutoBIN-Starts werden in dieser Zeit zurückgestellt, während die für TNC und Verbindung notwendige interne Kommunikation weiterlaufen kann.
Terminalbetrieb, AutoBIN und die Spiele wurden nicht nur simuliert, sondern bereits mit echten TNC2-Geräten und über reale Funkstrecken getestet.
Das Node Tool
Das Node Tool verwendet dieselbe klassische TNC-Technik, hat jedoch eine andere Aufgabe.
Es stellt einen zentralen Packet-Radio-Node bereit, an dem mehrere Stationen gleichzeitig angemeldet sein können.
Nach dem Connect befindet sich eine Station zunächst im Kommandomodus des Nodes. Von dort stehen verschiedene Dienste und Connect-Möglichkeiten zur Verfügung.
Besonders interessant ist die Vermittlung zwischen Stationen.
Sind zwei Stationen bereits mit dem Node verbunden, müssen sie keinen neuen direkten Funkconnect untereinander aufbauen. Das Node Tool kann die beiden bestehenden Sessions intern miteinander verbinden.
Aus
Station A <-> Node
und
Station B <-> Node
wird logisch
Station A <-> Node <-> Station B
Beide Funkverbindungen zum Node bleiben dabei bestehen. Die Nutzdaten werden zwischen den beiden Sessions weitergereicht.
Ist die gewünschte Gegenstation noch nicht am Node angemeldet, kann das Node Tool einen freien Hostmode-Kanal des eigenen TNC verwenden und selbst einen echten AX.25-Connect zur Zielstation herstellen. Anschließend werden die beiden Sessions miteinander verbunden.
Die Weiterleitung ist dabei möglichst transparent aufgebaut. Sobald eine solche Verbindung besteht, sollen die übertragenen Nutzdaten nicht mehr als Node-Kommandos interpretiert werden.
Dadurch können grundsätzlich auch darüberliegende Anwendungen und Protokolle durch eine Node-Verbindung laufen.
BBS, Dateien und Nachrichten
Zum Node Tool gehört außerdem eine klassische textbasierte BBS.
Dort stehen unter anderem eine gemeinsame Filebase, AutoBIN-Transfers, persönliche Nachrichten und Bulletins zur Verfügung.
Uploads werden zunächst außerhalb der öffentlichen Filebase empfangen. Erst wenn eine Datei vollständig angekommen ist und ihre CRC-Prüfung bestanden hat, wird sie als fertige Datei freigegeben.
Die Benutzeridentität orientiert sich dabei klassisch am AX.25-Callsign.
Auch ältere Packet-Radio-Terminals wurden bei der Entwicklung berücksichtigt. Unterschiedliche Zeichendarstellungen zwischen modernen UTF-8-Systemen und historischen DOS-Terminals werden deshalb bewusst robust behandelt.
Der Betrieb wurde bereits zwischen sehr unterschiedlichen Terminalgenerationen praktisch getestet.
Ein wichtiger Punkt beim Node Tool ist die klare Trennung zwischen BBS und Betriebssystem.
Die BBS stellt ausschließlich ihre vorgesehenen Funktionen zur Verfügung.
Ein Benutzer erhält dort keine Betriebssystem-Shell und kann keine beliebigen Linux-Kommandos ausführen.
Das ist keine fehlende Funktion, sondern eine bewusste Architekturentscheidung.
Für echte interaktive Shell-Sitzungen entsteht derzeit ein
separates Shell-Programm.
Dieses Shell-Programm geht technisch einen deutlich anderen Weg als die BBS.
Nach einem AX.25-Connect werden die Terminaldaten transparent zwischen TNC und einem echten Linux-PTY transportiert.
Auf der Linux-Seite läuft anschließend die normale Login-Kette:
AX.25 -> TNC -> WA8DED -> PTY -> agetty -> login/PAM -> Benutzer-Shell
Damit handelt es sich tatsächlich um eine interaktive Linux-Login-Shell und nicht um einen Satz nachgebildeter Remote-Kommandos.
Benutzer melden sich mit einem echten Linux-Benutzerkonto an und erhalten anschließend dessen normale Shell-Umgebung.
Das Programm besitzt dafür unter anderem eine Callsign-Vorfilterung, eine getrennte Freigabe der Linux-Benutzer, Login- und Session-Timeouts sowie eine administrative ARM-/DISARM-Funktion.
Der Funkzugang startet bewusst immer deaktiviert und muss vom lokalen Administrator freigeschaltet werden. Eine laufende Sitzung kann außerdem unmittelbar getrennt werden.
Root-Login ist standardmäßig gesperrt.
Dabei muss allerdings eine grundsätzliche Eigenschaft klassischer Packet-Radio-Verbindungen berücksichtigt werden:
Das ist kein SSH.
Benutzername, Passwort, Befehle und Ausgaben werden unverschlüsselt über Funk übertragen. Für einen solchen Zugang sind daher ausschließlich dafür vorgesehene Benutzerkonten ohne unnötige Rechte oder sensible Daten sinnvoll.
Das Shell-Programm befindet sich weiterhin in Entwicklung.
VT100 und xterm über AX.25
Parallel dazu entsteht ein weiteres, separates VT100-/xterm-Terminalprogramm.
Dieses ist speziell für echte interaktive Terminalanwendungen vorgesehen.
Nach dem AX.25-Connect wird ein richtiger Terminalemulator auf dem lokalen Linux-System mit dem WA8DED-Datenstrom verbunden. Dadurch können Terminalsteuersequenzen übertragen werden, wie sie beispielsweise von interaktiven Linux-Programmen verwendet werden.
Damit werden Anwendungen wie
top
nano
vim
und andere VT100-/xterm- beziehungsweise curses-basierte Programme grundsätzlich möglich.
Das ist über eine langsame Packet-Radio-Verbindung allerdings eine interessante technische Herausforderung.
Bei 1200 Baud wäre es beispielsweise wenig sinnvoll, jeden einzelnen eingegebenen Buchstaben sofort als eigenen Funkvorgang zu behandeln.
Das VT100-/xterm-Terminalprogramm besitzt deshalb verschiedene Übertragungsarten.
Im normalen Zeilenmodus wird eine eingegebene Zeile zunächst lokal dargestellt und gepuffert. Erst mit Enter wird die komplette Zeile übertragen.
Für längere Texte gibt es zusätzlich einen Compose-Modus. Dabei können sogar mehrere Zeilen zunächst lokal vorbereitet und anschließend gemeinsam übertragen werden. Das ist besonders für Editoren interessant.
Ein Raw-Modus steht ebenfalls zur Verfügung und überträgt Tastatureingaben unmittelbar.
Längere Sendungen werden automatisch in für den WA8DED-Transport geeignete Blöcke zerlegt und anschließend über die normale TNC-Puffersteuerung abgearbeitet.
Auch Dinge wie Passwortprompts werden berücksichtigt, damit ein eingegebenes Passwort nicht versehentlich durch die lokale Eingabeanzeige sichtbar wird.
Für Mausunterstützung wird ebenfalls bewusst gefiltert: Klicks können übertragen werden, während kontinuierliche Mausbewegungen nicht unnötig den ohnehin begrenzten Funkkanal belasten sollen.
Auch dieses VT100-/xterm-Terminalprogramm befindet sich noch in Entwicklung.
Damit entstehen bewusst zwei verschiedene Ansätze.
Das Terminal Tool bleibt das klassische Packet-Radio-Terminal für QSOs, mehrere AX.25-Kanäle, AutoBIN, Remote-Funktionen und zusätzliche Packet-Radio-Anwendungen wie die Spiele.
Das neue VT100-/xterm-Terminalprogramm ist dagegen für echte interaktive Terminal-Sessions gedacht und bildet zusammen mit dem Shell-Programm die Gegenstelle für eine richtige Linux-Terminalsitzung über Packet Radio.
Ebenso bleibt beim Node Tool die klassische BBS klar von einer Betriebssystem-Shell getrennt.
So muss ein einzelnes Programm nicht gleichzeitig Packet-Terminal, Node, BBS, Linux-Shell und xterm sein.
Jedes Werkzeug kann sich auf seine eigentliche Aufgabe konzentrieren.
Der gemeinsame Gedanke hinter allen diesen Entwicklungen bleibt:
Alte Packet-Radio-Hardware soll nicht einfach durch moderne Software ersetzt werden.
Ein klassischer TNC2 kann weiterhin genau das tun, wofür er gebaut wurde.
Die moderne Software ergänzt ihn dort, wo ein heutiger Rechner neue Möglichkeiten eröffnet:
- komfortabler Terminalbetrieb,
- mehrere logische Verbindungen,
- Dateiübertragung,
- Spiele,
- Node- und Bridge-Funktionen,
- BBS und Nachrichten,
- Administration und Logging,
- sowie zukünftig echte VT100-/xterm-Sitzungen und interaktive Linux-Logins.
Terminal- und Node-Programm wieder im Feldtest – Downloads folgen in Kürze
Ein kurzes Update zum aktuellen Stand:
Sowohl das Terminal Tool als auch das Node Tool befinden sich momentan noch einmal im praktischen Feldtest.
Der Grund dafür sind nicht ausschließlich technische Änderungen. In den vergangenen Versionen gab es unter anderem auch Anpassungen beim Portabelbetrieb und der Namensgebung der internen Kennungen, wodurch noch einmal neue Paket- und Versionsstände entstanden sind.
Auch wenn sich dadurch an den grundlegenden Funkprotokollen und Datenformaten nichts Wesentliches geändert hat, sollen die aktuellen Fassungen vor der erneuten Veröffentlichung noch einmal mit realer Hardware und über echte Funkstrecken geprüft werden.
Die Tests laufen derzeit.
Wenn dabei keine neuen Probleme auftreten, sollen die aktuellen Quellcodes beziehungsweise Programmpakete in den nächsten Tagen wieder zum Download zur Verfügung stehen.
Linux bleibt die Hauptplattform – aber nicht zwingend die einzige
Die Tools wurden ursprünglich für Linux entwickelt und dort findet auch der überwiegende Teil der Entwicklung und der realen Tests statt.
Beim normalen Terminal Tool ist die Situation allerdings etwas offener.
Da das Programm auf Python basiert und für die Oberfläche Tkinter sowie für die serielle Kommunikation PySerial verwendet, ist es grundsätzlich auch unter Windows lauffähig.
Vorausgesetzt werden dort insbesondere:
- Python 3.12
- Tkinter
- PySerial
Dabei konnte das Terminal Tool erfolgreich mit einem real angeschlossenen TNC kommunizieren.
Auch ein Connect-Versuch wurde getestet. Bei diesem Versuch war bewusst kein Funkgerät am TNC angeschlossen. Entsprechend konnte natürlich keine Funkverbindung zustande kommen.
Interessant war aber das Verhalten der Hardware:
Der Connect-Befehl wurde vom Programm korrekt zum TNC übertragen und der TNC reagierte genau so, wie es in dieser Situation zu erwarten war. Die entsprechenden Status- beziehungsweise Sende-LEDs wurden geschaltet und der TNC versuchte, den Connect aufzubauen.
Damit ist zumindest in einem ersten praktischen Test bestätigt:
Die grundlegende Kommunikation zwischen Terminal Tool und TNC funktioniert auch unter Windows.
Das ist noch kein vollständiger Windows-Feldtest mit Funkgerät, Gegenstation, AutoBIN und allen weiteren Funktionen. Die Hauptentwicklung und vollständigen Feldtests bleiben derzeit weiterhin Linux-basiert.
Für Anwender, die das klassische Terminal Tool unter Windows ausprobieren möchten, sieht die technische Grundlage aber bereits vielversprechend aus.
Wie geht es weiter?
Aktuell stehen zunächst noch einmal reale Tests von Terminal Tool und Node Tool mit den aktuellen Versionsständen im Vordergrund.
Danach werden die Pakete wieder bereitgestellt.
Das Ziel bleibt unverändert:
klassische TNC2-/TheFirmware-Technik mit moderner Software weiter nutzbar machen – ohne den eigentlichen AX.25-Funkbetrieb aus dem TNC herauszureißen.
Weitere Informationen und die neuen Downloads folgen, sobald die laufenden Feldtests abgeschlossen sind.
Quellcode und Lizenz
Alle Programme werden vollständig als Quellcode unter GPL-2.0-only veröffentlicht. Diese Lizenzwahl ergibt sich insbesondere aus der historischen Herkunft von Teilen der Codebasis aus dem ursprünglichen TNT Packet-Radio-Terminal. Damit bleibt der Quellcode offen einsehbar, veränderbar und – im Rahmen der GPL-Bedingungen – weiterverteilbar.
Wer möchte, kann die Programme selbst anpassen, paketieren oder auch in eine eigene ausführbare Form kompilieren. Für die normale Nutzung ist eine Kompilierung jedoch nicht notwendig: Mit einer passenden Python-Installation und den jeweils benötigten Abhängigkeiten können die Programme direkt aus dem Quellcode gestartet werden.
RE: TNC2 Tool Linux (Python) - 13LS194 - 05.09.2026
Die Packet-Radio-Tools sind wieder im Downloadbereich verfügbar. 🙂
Hier könnt ihr sie runterladen.
Aktuell sind das:
- Packet Radio Terminal 7.5
- Packet Radio Node Server 2.5
In den letzten Runden gab es noch einige Aufräumarbeiten bei Namen, internen Kennungen und der Portabilität. Beide Tools speichern ihre eigenen Daten jetzt direkt im jeweiligen Programmverzeichnis und lassen sich damit deutlich unkomplizierter verschieben oder auf einen anderen Rechner übernehmen.
Kurz vor Schluss ist noch ein etwas fieser Fehler im Terminal aufgefallen:
Bei einer Remote-Anfrage mit
//H
wurden die in der Hilfe aufgeführten //-Befehle teilweise von der Gegenstation wieder als echte Befehle interpretiert.
Das war besonders mit GP gut zu sehen – dort wurde die komplette Liste praktisch direkt abgearbeitet. Auch zwischen zwei Terminal-Instanzen konnte das zu unerwünschten Aktionen führen.
Das ist jetzt behoben.
Die Hilfe und andere Remote-Antworttexte werden so ausgegeben, dass darin enthaltene //-Beispiele nicht mehr als neue Kommandos erkannt werden.
Echte Remote-Anfragen wie //read und die AutoBIN-Dateiübertragung bleiben davon natürlich unberührt.
Die aktuellen Stände wurden wieder durch Feldtests für normale Anwendungsfälle gejagt und sind jetzt bereit für weitere reale (tiefgehendere) Tests mit TNC und über Funk.
Falls euch beim Betrieb noch irgendetwas auffällt: Gerne melden. Gerade Bugreports aus dem echten Funkbetrieb sind sehr willkommen – auch wenn es nur Kleinigkeiten, merkwürdige Anzeigen oder schwer reproduzierbare Effekte sind. Solche Sachen findet man bei längerer Anwendung oft deutlich besser als bei normalen Tests.
Viel Spaß beim Testen
73 Marco