<![CDATA[LK0NOD - Forum - Community - CB Funk 11m

<![CDATA[LK0NOD - Forum - Community - CB Funk 11m - TNC2 Tool Linux (Python) ]]> https://lk0nod.de/forum/ Tue, 27 Oct 2026 16:36:54 +0000 MyBB <![CDATA[Portables Packet- Betriebsystem]]> https://lk0nod.de/forum/thread-1368.html Fri, 11 Sep 2026 17:18:42 +0200 13LS194]]> https://lk0nod.de/forum/thread-1368.html Hallo zusammen,

beim Erweitern der Packet Radio Tools bin ich auf ein Problem gestoßen, dessen Lösung etwas weiter ausgeholt hat als ursprünglich geplant. Daraus ist inzwischen aber ein recht umfangreiches und vor allem praktisches Projekt entstanden.

Das Problem:
Das Terminal-Tool sollte so erweitert werden, dass es neben WA8DED/TF-Hostmode auch direkt auf Linux-eigene AX.25-Ports zugreifen kann. Mit KISS war das grundsätzlich problemlos möglich.
Schwieriger wurde es beim klassischen Baycom-Modem über die baycom_ser_fdx-/ baycom_ser_hdx -Treiber:
Unter einem aktuellen 7.0.x-Kernel kam es auf meiner Hardware zu kompletten System-Freezes, sobald der TRX am Modem auch nur im RX aktiv wurde. In der darauffolgenden Kernelgeneration steht der bisherige AX.25-Kernelstack zudem nicht mehr wie gewohnt zur Verfügung.

Einen älteren Kernel möchte man aber ungern in seinem normalen Arbeitssystem einsetzen.
Also entstand die Idee:

Ein komplettes, portables Linux-System ausschließlich für AX.25 und Packet Radio – bootfähig vom USB-Stick.

Und das funktioniert inzwischen erstaunlich gut.
Das System wurde zunächst vollständig in einer VM aufgebaut und anschließend als Image auf einen USB-Stick übertragen.

Aktueller Aufbau:

Debian 12
Kernel 6.1.0-53
APT als Paketmanager
Xorg
IceWM
PCManFM
Firefox
die gängigen AX.25-Tools
meine Packet-Radio-Tools
grafisches AX.25 Control Center (Konfiguration der Axports, Baycom Modem etc.)

newgui.png (Größe: 167,8 KB / Downloads: 2)
.png

ccnew.png (Größe: 255,71 KB / Downloads: 2)

Die AX.25-Konfiguration lässt sich vollständig grafisch einrichten. Gerade ein Baycom-Modem kann damit mit wenigen Klicks konfiguriert und gestartet werden.
Alle Anwendungen werden über einen eigenen Vollbild-Launcher gestartet.

Das Ziel ist:

USB-Stick einstecken → booten → Packet Radio.

Der Stick ist vollständig beschreibbar. Einstellungen, Downloads, Updates und nachinstallierte Pakete bleiben also erhalten. Er verhält sich im Prinzip wie ein normales installiertes Linux-System.
Das fertige Image kann anschließend einfach mit dd auf einen USB-Stick geschrieben werden. Nach dem ersten Start wird die Dateisystemmgröße auf den gesamten Stick erweitert.
Der Stick ist sowohl auf Legacy-BIOS- als auch auf UEFI-Systemen bootfähig. Secure Boot wird aber nicht unterstützt.
Das Projekt befindet sich aktuell noch in der Testphase.
Sobald die Tests abgeschlossen, die Dokumentation fertig und die Imagegröße auf einem vertretbaren Stand ist, stelle ich das System gern zum Testen zur Verfügung.

Bis dahin,

73 Marco]]> Hallo zusammen,

beim Erweitern der Packet Radio Tools bin ich auf ein Problem gestoßen, dessen Lösung etwas weiter ausgeholt hat als ursprünglich geplant. Daraus ist inzwischen aber ein recht umfangreiches und vor allem praktisches Projekt entstanden.

Das Problem:
Das Terminal-Tool sollte so erweitert werden, dass es neben WA8DED/TF-Hostmode auch direkt auf Linux-eigene AX.25-Ports zugreifen kann. Mit KISS war das grundsätzlich problemlos möglich.
Schwieriger wurde es beim klassischen Baycom-Modem über die baycom_ser_fdx-/ baycom_ser_hdx -Treiber:
Unter einem aktuellen 7.0.x-Kernel kam es auf meiner Hardware zu kompletten System-Freezes, sobald der TRX am Modem auch nur im RX aktiv wurde. In der darauffolgenden Kernelgeneration steht der bisherige AX.25-Kernelstack zudem nicht mehr wie gewohnt zur Verfügung.

Einen älteren Kernel möchte man aber ungern in seinem normalen Arbeitssystem einsetzen.
Also entstand die Idee:

Ein komplettes, portables Linux-System ausschließlich für AX.25 und Packet Radio – bootfähig vom USB-Stick.

Und das funktioniert inzwischen erstaunlich gut.
Das System wurde zunächst vollständig in einer VM aufgebaut und anschließend als Image auf einen USB-Stick übertragen.

Aktueller Aufbau:

Debian 12
Kernel 6.1.0-53
APT als Paketmanager
Xorg
IceWM
PCManFM
Firefox
die gängigen AX.25-Tools
meine Packet-Radio-Tools
grafisches AX.25 Control Center (Konfiguration der Axports, Baycom Modem etc.)

newgui.png (Größe: 167,8 KB / Downloads: 2)
.png

mailclient.png (Größe: 53,67 KB / Downloads: 7)
.png

mail2.png (Größe: 52,12 KB / Downloads: 2)

Der TNC arbeitet weiterhin im WA8DED-Hostmode, während die eigentliche Mail-Logik in Python läuft.

Mehrere Packet-Nutzer werden lokal über ihre Rufzeichen verwaltet.
Dafür reicht ein einziges echtes Internet-Mailkonto. Benutzer, Nachrichten und Einstellungen liegen in einer SQLite-Datenbank.
Ein Packet-Nutzer kann entweder direkt an einen anderen lokalen Benutzer schreiben oder an eine normale Internet-Mailadresse.

Eine Nachricht an z.B. 13TEST1 wird direkt lokal zugestellt, während eine Adresse wie user@beispiel.de über SMTP ins Internet geschickt wird.
Der Rückweg erfolgt über IMAP. Für neue Nachrichten aus dem Internet wird Plus-Addressing verwendet, zum Beispiel:

packetnode+13TEST1@beispiel.de

Das Gateway erkennt daraus automatisch das Ziel 13TEST1 und legt die Nachricht in dessen lokale Inbox.
Antworten auf bereits verschickte Internet-Mails werden zusätzlich über Message-ID und In-Reply-To eindeutig dem ursprünglichen Packet-Nutzer zugeordnet.

Die Bedienung auf Packet-Seite ist bewusst einfach gehalten. Über ein normales Terminal können Nachrichten aufgelistet, gelesen, beantwortet und neu erstellt werden.
Für die Administration gibt es eine Tkinter-Oberfläche. Dort werden unter anderem Benutzer, Mailkonto, TNC, Nachrichten und Einstellungen verwaltet.
Vorbereitet ist außerdem eine SMS-Zwei-Faktor-Anmeldung. Nach einem AX.25-Connect kann ein sechsstelliger Einmalcode über ein eigenes GSM/LTE-Modem an eine hinterlegte Telefonnummer gesendet werden.
Zum Testen ist derzeit noch keine echte Funkhardware notwendig. Ein lokaler WA8DED-Simulator kann direkt mit dem Packet-Terminal verbunden werden. Dadurch lässt sich die komplette Anwendung zunächst am Rechner testen.

Die ersten Prototypen konnten bereits folgende Wege erfolgreich durchspielen:

Packet zu Packet
Packet zu Internet
Internet zu Packet
Antwort aus Packet wieder zurück ins Internet

Das Ganze ist also noch klar im Experimentierstadium.
Interessant zu sehen finde ich ist, was mit über 30 jahre alter Hardware noch möglich ist.

Ganz neu ist die Grundidee dabei natürlich nicht. Solche Übergänge zwischen Packet und Internet-Mail wurden früher bereits auf verschiedene Arten umgesetzt, zum Beispiel über überwachte Verzeichnisse, Outlook-Makros oder einfache Singleuser-Lösungen.
Der aktuelle Ansatz versucht im Grunde, dieses Prinzip nur moderner und flexibler umzusetzen: Mehrere lokale Benutzer, zentrale SQLite-Verwaltung, direkte Zuordnung über Plus-Addressing und Message-IDs sowie eine klar getrennte IMAP-/SMTP-Logik statt Datei- und Makro-Workarounds.

Natürlich basiert auch hier die "TNC Grundsteuerung" wieder auf dem bekannten Programm TNT (GPL2.0).

73
Marco]]>
Als jüngste Idee in meiner Packet-Radio-Tool-Sammlung ist gerade ein Packet Internet Mail Gateway entstanden.
Das Projekt steckt aktuell noch ganz am Anfang.
Im Moment werden die ersten Prototypen getestet, aber die grundlegende Kommunikation funktioniert bereits in beide Richtungen.

.png

mailclient.png (Größe: 53,67 KB / Downloads: 7)
.png

mail2.png (Größe: 52,12 KB / Downloads: 2)

Der TNC arbeitet weiterhin im WA8DED-Hostmode, während die eigentliche Mail-Logik in Python läuft.

Mehrere Packet-Nutzer werden lokal über ihre Rufzeichen verwaltet.
Dafür reicht ein einziges echtes Internet-Mailkonto. Benutzer, Nachrichten und Einstellungen liegen in einer SQLite-Datenbank.
Ein Packet-Nutzer kann entweder direkt an einen anderen lokalen Benutzer schreiben oder an eine normale Internet-Mailadresse.

Eine Nachricht an z.B. 13TEST1 wird direkt lokal zugestellt, während eine Adresse wie user@beispiel.de über SMTP ins Internet geschickt wird.
Der Rückweg erfolgt über IMAP. Für neue Nachrichten aus dem Internet wird Plus-Addressing verwendet, zum Beispiel:

packetnode+13TEST1@beispiel.de

Das Gateway erkennt daraus automatisch das Ziel 13TEST1 und legt die Nachricht in dessen lokale Inbox.
Antworten auf bereits verschickte Internet-Mails werden zusätzlich über Message-ID und In-Reply-To eindeutig dem ursprünglichen Packet-Nutzer zugeordnet.

Die Bedienung auf Packet-Seite ist bewusst einfach gehalten. Über ein normales Terminal können Nachrichten aufgelistet, gelesen, beantwortet und neu erstellt werden.
Für die Administration gibt es eine Tkinter-Oberfläche. Dort werden unter anderem Benutzer, Mailkonto, TNC, Nachrichten und Einstellungen verwaltet.
Vorbereitet ist außerdem eine SMS-Zwei-Faktor-Anmeldung. Nach einem AX.25-Connect kann ein sechsstelliger Einmalcode über ein eigenes GSM/LTE-Modem an eine hinterlegte Telefonnummer gesendet werden.
Zum Testen ist derzeit noch keine echte Funkhardware notwendig. Ein lokaler WA8DED-Simulator kann direkt mit dem Packet-Terminal verbunden werden. Dadurch lässt sich die komplette Anwendung zunächst am Rechner testen.

Die ersten Prototypen konnten bereits folgende Wege erfolgreich durchspielen:

Packet zu Packet
Packet zu Internet
Internet zu Packet
Antwort aus Packet wieder zurück ins Internet

Das Ganze ist also noch klar im Experimentierstadium.
Interessant zu sehen finde ich ist, was mit über 30 jahre alter Hardware noch möglich ist.

Ganz neu ist die Grundidee dabei natürlich nicht. Solche Übergänge zwischen Packet und Internet-Mail wurden früher bereits auf verschiedene Arten umgesetzt, zum Beispiel über überwachte Verzeichnisse, Outlook-Makros oder einfache Singleuser-Lösungen.
Der aktuelle Ansatz versucht im Grunde, dieses Prinzip nur moderner und flexibler umzusetzen: Mehrere lokale Benutzer, zentrale SQLite-Verwaltung, direkte Zuordnung über Plus-Addressing und Message-IDs sowie eine klar getrennte IMAP-/SMTP-Logik statt Datei- und Makro-Workarounds.

Natürlich basiert auch hier die "TNC Grundsteuerung" wieder auf dem bekannten Programm TNT (GPL2.0).

73
Marco]]> <![CDATA[Shell und Xterm Terminaltools]]> https://lk0nod.de/forum/thread-1215.html Sat, 05 Sep 2026 13:41:06 +0200 13LS194]]> https://lk0nod.de/forum/thread-1215.html
Ich möchte mal wieder zwei zusammengehörige Programme vorstellen:

AX.25 Shell Serverprogramm
AX.25 Shell Terminalprogramm

.png

shell1.png (Größe: 59,99 KB / Downloads: 3)
.png

shell2.png (Größe: 41,72 KB / Downloads: 3)
.png

terminalshell1.png (Größe: 259,78 KB / Downloads: 4)

Das Serverprogramm läuft auf der entfernten Linux-Station und stellt über einen TNC im WA8DED/TheFirmware-Hostmode eine echte Linux-Login-Sitzung bereit.
Der Datenweg ist grob:

Terminalprogramm
→ TNC
→ AX.25
→ TNC
→ Shell Serverprogramm
→ PTY
→ agetty / login / PAM
→ Linux-Shell

Es handelt sich also nicht um eine nachgebaute Mini-Shell, sondern um eine normale Linux-Benutzershell. Der Server startet DISARMED und bietet über eine lokale GUI unter anderem ARM/DISARM, CUTOFF, TNC-Konfiguration und Benutzerverwaltung.
Das dazugehörige Terminalprogramm ist speziell für langsame Packet-Verbindungen gedacht.
Im normalen Shellbetrieb arbeitet es im LINE Mode. Man tippt eine komplette Zeile lokal und erst Enter überträgt sie.
Gerade bei 1200 Baud spart das gegenüber der Übertragung jedes einzelnen Tastendrucks einiges an Funkverkehr.

Interessant ist die automatische Terminal-Logik.
Wird remote zum Beispiel

nano test.txt

gestartet, erkennt das Terminalprogramm die üblichen VT/xterm-Alternate-Screen-Sequenzen.
Der Zustand wechselt damit intern von normaler Shell auf Vollbildanwendung.
Das Programm öffnet automatisch ein zweites echtes Linux-Terminal. Dort läuft die Anwendung direkt im VT/xterm-Betrieb, sodass zum Beispiel Pfeiltasten, Ctrl-Kombinationen und ESC unmittelbar übertragen werden können.
Das ursprüngliche Kommando-Terminal bleibt währenddessen als Kontrollterminal offen. Normale Remote-Eingaben sind dort gesperrt, lokale Befehle funktionieren aber weiterhin.

Zum Beispiel:
//compose

Damit öffnet sich ein eigener Compose-Editor. Dort kann man längere oder mehrzeilige Texte lokal vorbereiten, korrigieren oder per Copy/Paste einfügen und anschließend gesammelt an die aktuell aktive Remote-Sitzung senden.
Das funktioniert sowohl in einer normalen Shell, als auch während einer Vollbildanwendung.

Wird die Vollbildanwendung beendet, erkennt das Terminalprogramm das Ende des Alternate Screen automatisch, schließt das Application-Terminal und schaltet die Ein-/Ausgabe wieder auf das Kommando-Terminal zurück. Dabei wird der vorherige LINE- oder RAW-Modus wiederhergestellt.

Für Sonderfälle gibt es zusätzlich:
//raw

für direkte Eingabe und
//line

für den normalen zeilenorientierten Betrieb.
Größere Sendungen werden automatisch in WA8DED-Datenblöcke von maximal 256 Byte aufgeteilt.
Zum Testen gibt es auf beiden Seiten außerdem lokale Testmöglichkeiten ohne TNC und ohne Funk. Beim Terminalprogramm kann man damit zum Beispiel LINE, Compose, nano/vim, die automatische Vollbilderkennung und den Fensterwechsel komplett lokal ausprobieren.
Das Ganze ist ein Experiment, eine echte Linux-Shell möglichst sinnvoll über klassische Packet-Radio-Technik nutzbar zu machen.
Gerade bei 1200 Baud AFSK funktioniert die Kombination aus LINE Mode, Compose und automatischer Terminal-Umschaltung bisher erstaunlich angenehm.

Die Downloads brauchen noch etwas, bis alles zusammengestellt und dokumentiert ist.
Als technische Basis für die TNC-/WA8DED-Anbindung dient übrigens wieder die bekannte GPL-2.0-Software TNT.]]>
Ich möchte mal wieder zwei zusammengehörige Programme vorstellen:

AX.25 Shell Serverprogramm
AX.25 Shell Terminalprogramm

.png

shell1.png (Größe: 59,99 KB / Downloads: 3)
.png

shell2.png (Größe: 41,72 KB / Downloads: 3)
.png

terminalshell1.png (Größe: 259,78 KB / Downloads: 4)

Das Serverprogramm läuft auf der entfernten Linux-Station und stellt über einen TNC im WA8DED/TheFirmware-Hostmode eine echte Linux-Login-Sitzung bereit.
Der Datenweg ist grob:

Terminalprogramm
→ TNC
→ AX.25
→ TNC
→ Shell Serverprogramm
→ PTY
→ agetty / login / PAM
→ Linux-Shell

Es handelt sich also nicht um eine nachgebaute Mini-Shell, sondern um eine normale Linux-Benutzershell. Der Server startet DISARMED und bietet über eine lokale GUI unter anderem ARM/DISARM, CUTOFF, TNC-Konfiguration und Benutzerverwaltung.
Das dazugehörige Terminalprogramm ist speziell für langsame Packet-Verbindungen gedacht.
Im normalen Shellbetrieb arbeitet es im LINE Mode. Man tippt eine komplette Zeile lokal und erst Enter überträgt sie.
Gerade bei 1200 Baud spart das gegenüber der Übertragung jedes einzelnen Tastendrucks einiges an Funkverkehr.

Interessant ist die automatische Terminal-Logik.
Wird remote zum Beispiel

nano test.txt

gestartet, erkennt das Terminalprogramm die üblichen VT/xterm-Alternate-Screen-Sequenzen.
Der Zustand wechselt damit intern von normaler Shell auf Vollbildanwendung.
Das Programm öffnet automatisch ein zweites echtes Linux-Terminal. Dort läuft die Anwendung direkt im VT/xterm-Betrieb, sodass zum Beispiel Pfeiltasten, Ctrl-Kombinationen und ESC unmittelbar übertragen werden können.
Das ursprüngliche Kommando-Terminal bleibt währenddessen als Kontrollterminal offen. Normale Remote-Eingaben sind dort gesperrt, lokale Befehle funktionieren aber weiterhin.

Zum Beispiel:
//compose

Damit öffnet sich ein eigener Compose-Editor. Dort kann man längere oder mehrzeilige Texte lokal vorbereiten, korrigieren oder per Copy/Paste einfügen und anschließend gesammelt an die aktuell aktive Remote-Sitzung senden.
Das funktioniert sowohl in einer normalen Shell, als auch während einer Vollbildanwendung.

Wird die Vollbildanwendung beendet, erkennt das Terminalprogramm das Ende des Alternate Screen automatisch, schließt das Application-Terminal und schaltet die Ein-/Ausgabe wieder auf das Kommando-Terminal zurück. Dabei wird der vorherige LINE- oder RAW-Modus wiederhergestellt.

Für Sonderfälle gibt es zusätzlich:
//raw

für direkte Eingabe und
//line

für den normalen zeilenorientierten Betrieb.
Größere Sendungen werden automatisch in WA8DED-Datenblöcke von maximal 256 Byte aufgeteilt.
Zum Testen gibt es auf beiden Seiten außerdem lokale Testmöglichkeiten ohne TNC und ohne Funk. Beim Terminalprogramm kann man damit zum Beispiel LINE, Compose, nano/vim, die automatische Vollbilderkennung und den Fensterwechsel komplett lokal ausprobieren.
Das Ganze ist ein Experiment, eine echte Linux-Shell möglichst sinnvoll über klassische Packet-Radio-Technik nutzbar zu machen.
Gerade bei 1200 Baud AFSK funktioniert die Kombination aus LINE Mode, Compose und automatischer Terminal-Umschaltung bisher erstaunlich angenehm.

Die Downloads brauchen noch etwas, bis alles zusammengestellt und dokumentiert ist.
Als technische Basis für die TNC-/WA8DED-Anbindung dient übrigens wieder die bekannte GPL-2.0-Software TNT.]]> <![CDATA[TNC2 Tool Linux (Python)]]> https://lk0nod.de/forum/thread-1099.html Wed, 12 Aug 2026 22:58:48 +0200 13LS194]]> https://lk0nod.de/forum/thread-1099.html
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.

.png

terminal75.png (Größe: 85,74 KB / Downloads: 3)

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

.png