LK0NOD - Forum - Community - CB Funk 11m - Alle Foren

🚨 Packet Radio im Wandel? Neue Tests auf Kanal 24 (27.235 MHz USB) 🚨

Sun, 26 Apr 2026 16:30:39 +0200

🚨 Packet Radio im Wandel? Neue Tests auf Kanal 24 (27.235 MHz USB) 🚨

Aktuell zeichnet sich im Bereich Packet Radio auf dem 11-Meter-Band eine spannende Entwicklung ab: Immer mehr Node-Systeme verlagern ihre Aktivitäten auf Kanal 24 – 27.235 MHz von FM auf SSB (USB).

Der große Unterschied:

Während auf FM bisher meist mit 1200 Baud gearbeitet wurde, laufen die aktuellen Tests im USB-Betrieb mit 300 Baud – ähnlich dem bekannten Prinzip von JS8Call.

📡 Erste Ergebnisse sind vielversprechend:

Bereits in den ersten Testläufen konnten deutlich weitere und stabilere Verbindungen erreicht werden, als es über FM bislang ansatzweise möglich war. Gerade für Weitverbindungen und schwache Signale könnte das ein echter Fortschritt sein.

❓ Jetzt seid ihr gefragt:

Wie sind eure Erfahrungen mit Packet Radio auf USB bei 300 Baud?

Habt ihr bereits an den Tests teilgenommen?
Seid ihr gerade selbst am Umstellen?
Könnte sich dieser Wechsel von FM/1200 Baud zu USB/300 Baud langfristig durchsetzen?
Wie groß ist euer Interesse an Packet Radio über SSB?
Oder hört ihr gerade zum ersten Mal davon, dass aktuell viele Stationen testen?

💬 Schreibt eure Meinung, Erfahrungen und Einschätzungen gerne hier in die Kommentare oder direkt ins Forum von LK0NOD auf www.lk0nod.de

📢 Wir sind gespannt, ob hier gerade der nächste große Schritt im Packet Radio entsteht!

E88E5DA5-634E-418D-83FC-65B984DD75E7.png (Größe: 2,06 MB / Downloads: 3)

WinStop 1.05 mit Soundmodem

Sun, 26 Apr 2026 15:28:06 +0200

Moin zusammen,

hat jemand von Euch diese Kombination in Betrieb ?
Falls ja, könnte ich bitte die Einstellungen von WinStop und Soundmodem haben ?

73
Uwe

Internationale Space Station (ISS) als Digipeater

Fri, 24 Apr 2026 21:42:54 +0200

Mit Packer-Radio in den Weltraum?

Von einem C64 als Bodenstation!

Ein faszinierender Bericht:
Quelle: alickgardiner.com/c64-packet-radio/

Anmerkung:
Senden zur ISS ist legal nur mit einer entsprechenden Funkamateur-Lizenz.

LK0NOD News – Wartungsarbeiten & Antennen-Feintuning am Wochenende

Thu, 23 Apr 2026 19:14:21 +0200

LK0NOD News – Wartungsarbeiten & Antennen-Feintuning am Wochenende

Am kommenden Wochenende sind im Bereich des LK0NOD-Standorts umfangreiche Arbeiten an der Funk- und Antennenanlage geplant. Im Zuge des anstehenden Umbaus wird es voraussichtlich zu weiteren Feinanpassungen am Antennensystem kommen.

Während dieser Arbeiten kann es zeitweise zu Einschränkungen kommen: Das 11-Meter-Band sowie der SDR-Empfang könnten kurzfristig offline oder nicht erreichbar sein, da für bestimmte Schritte die Anlage vollständig abgeschaltet werden muss.

Parallel dazu wird das bestehende TNC3S testweise aus dem System entfernt. Stattdessen ist geplant, unser Notsystem auf Basis von BPQ über den Raspberry Pi 5 in Kombination mit Direwolf und einer Soundkarte anzubinden. Die Vorbereitungen hierfür laufen bereits auf Hochtouren.

Zusätzlich steht im Rahmen des Umbaus auch ein Antennentausch im Raum: Die JF K48 Super DX soll testweise gegen die derzeitige Mantova-Anlage getauscht werden. Je nach Zeitfenster könnten mehrere dieser Schritte am Wochenende umgesetzt werden.

Die Arbeiten sind bewusst umfangreich angesetzt, um das System langfristig stabiler und flexibler zu gestalten. Wir arbeiten daran, alles bestmöglich und in der verfügbaren Zeit umzusetzen, und sind gespannt auf die Ergebnisse nach Abschluss der Umstellung.

Weitere Informationen und Status-Updates gibt es wie gewohnt unter: www.lk0nod.de

Packet-Radio Simulator

Thu, 23 Apr 2026 07:50:12 +0200

Liebe Einsteiger,

der Packet-Radio Simulator ermöglicht Experimente mit Packet-Radio.

Auf der Webseite klier.us/bbs/ findet man den realitätsnah gemachten Packet-Radio Simulator.

Zum Starten auf "LET'S GET STARTED AT 1200BPS" klicken.

Unter "Tutorial" wird Packet-Radio erklärt (Geschichte und Bedienung des TNC).

Mit "I/O" startet man Funkgerät und Terminal Network Controller (TNC).

Im simulierten Terminal kann man mit Packet-Radio experimentieren.

Viel Spass damit ;-)

Zeitschriftenartikel zu Packet-Radio (1983-1993)

Wed, 22 Apr 2026 07:12:37 +0200

In der Zeitschrift "73 Amateur Radio Today" findet sich eine Übersicht zu Packet-Radio Artikeln aus den Jahren 1983-1993.

Erschienen ist das Heft im August 1993.

Terminal-Emulationsprogramme

Tue, 21 Apr 2026 22:12:59 +0200

Terminal-Emulationsprogramme

ermögliichen die initiale Konfiguration eines TNC über die serielle Schnittstelle.

Bekannte Vertreter unter Windows sind:

PuTTY
Tera Term

Auch das Programm C-Kermit wird nach vierzig Jahren noch gepflegt.
Aktuelle Bezugsquelle: davidrg.github.io/ckwin/

Für Liebhaber von Mailboxen:
SyncTERM

Unter DOS:
TERM von DL5FBD

MH Liste - 20.04.2026

Mon, 20 Apr 2026 19:04:39 +0200

LK0NRW:LK0NOD} Heard List for Port 1
LK2NOD     00:00:00:59
LK1NOD     00:00:09:37
LK2-1      00:00:18:23
LK1-1      00:01:12:03
LK2-2      00:01:50:02
DAC806     00:03:18:16
DCT645-11  00:14:37:07
LK2-3      00:22:41:49
DQB906-1   01:02:14:42
DQB906-15  01:02:24:03
DQB906     01:02:24:10
TEST11     01:02:29:01
TEST11-15  01:03:36:18
DCT645-10  01:04:55:30    via CT1NET,CT3NOD*,WIDE2-2
CT3NOD     01:05:12:25
STRELA-1   01:06:48:40
DCT645-13  01:07:49:41
LK1-7      01:08:11:50
STRELA-15  01:08:16:39
DCT645-2   01:08:23:00
STRELA-14  01:08:50:22
CT1PI      01:09:55:19
STRELA-7   01:10:05:25
CT1PI-7    01:10:09:13
STRELA-8   01:12:06:11
CT1NET     01:21:52:43
STRELA-9   02:00:09:08
DCT645     02:02:07:20
STRELA-5   02:02:18:25
DCT645-3   02:09:52:21

Packet Radio Neuling

Mon, 20 Apr 2026 11:37:54 +0200

Hallo an ALLE

Bin neu hier im Forum QTH Recklinghausen NRW.
Habe damals die Packet Radio Zeit mitgemacht und würde gerne
mit Packet Radio hier wieder auf Sendung gehen.
Habe eine Hochantenne, Albrecht 5890 sowie Macbook.
Fehlt nur ein Modem sowie die Software.
Vielleicht könnte Ihr, mit eurem Wissen HELFEN.
Damals war das alles ein bisschen anders.

Vielen Dank Gruss der Micha

Grundlagen zu seriellen Schnittstellen (RS232)

Sun, 19 Apr 2026 22:10:41 +0200

Grundlagen zu seriellen Schnittstellen (RS232)

Serielle Schnittstellen (RS232/RS422) ermöglichen Computern, Daten mit externen Geräten (e.g. TNC / Drucker / Modem) auszutauschen.

Im Kontext Packet-Radio geht es hier speziell um die 1:1 Verbindung eines Computer mit einem TNC (Terminal-Network-Controllers).
Also um die Digital-Schnittstelle eines TNC.

Computer       TNC
(DTE) (DCE)
+--------+
|
| COM1   |-------------------- Gerät 1 (meist Maus)
| |
| COM3   |-------------------- Gerät 2 (TNC-2)
|        | (ca. 15 Meter)      an DB25
+--------+
mit DB9

Als die Schnittstelle (ab 1962) normiert wurde, waren noch mechanische Schreibmaschinendrucker als Terminals üblich.
Diese wurden dann über Akustik-Koppler (später Modems) mit weit entfernten Systemen verbunden.
Aus dieser Zeit stammen noch Begriffe wie DTE/DCE und Mark und Space.

+-----+ +-----+       +-----+     +------+
| DTE | <-> | DCE |   .....    (Telefonleitung)   ....    | DCE | <-> | DTE |
+-----+ +-----+    nur Punkt-zu-Punkt     +-----+     +------+
Terminal    Modem X.25        Modem     Terminal

Früher:
DTE meinte meist Terminal (Data Terminal Equipment)
DCE meinte Data Communication Equipement, damals meist Akustik-Koppler (später: Modems)

Heute (für Packet-Radio) nutzen wir
einen Computer statt Terminal (DTE)
einen TNC statt Akkustik-Koppler (DCE)
ein Funkgerät (ermöglicht mehrere Funkstrecken / Konversationen gleichzeitig)

       CB 11m
                                         AFU 2m

      Y ... Y
              | |
     Digital     Analog            | AX.25 |    Analog    Digital
+-----+ RS +------+    +-----------+    +-----------+   +-----+ +------+
| DTE | <-> | DCE | <-> | Funkgerät | 1:n | Funkgerät | <-> | DCE | <-> | DTE |
+-----+ 232 +------+       +-----------+ +-----------+   +-----+    +------+
Computer    TNC       TNC    Computer
         mit       mit
   Modem(s)          Modem(s)

Die Vereinbarung der RS232 Signalnamen erfolgt immer aus Sicht des Terminals (DTE).
Das Aussenden von Daten geht immer nur von DTE (Computer) -> TX -> DCE über die Sendeleitung.
Der Empfang von Daten geht immer nur zum DTE (Computer) <- RX <- DCE über die Empfangsleitung.

Daten im Computer liegen Byteweise (8 Bit), also parallel, vor.
Diese Daten werden im Computer von einem UART-Chip in eine serielle Bitfolge konvertiert.

Der UART verträgt in der Regel nur die in einem Computer üblichen Spannungen (0-5V).
Die bei der RS232-Norm definierten Spannungspegel sind aber für heutige Computer nicht mehr geeignet.

Der direkte Anschluss des UART-Chips an das Partnersystem könnte den UART zerstören!
Daher schaltet man einen (Spannungs-)Pegelwandler dazwischen.

   +---+ zeitliche Reihenfolge der Bit    +---+
1 | U |                 MSB Bits    LSB    | U | 1
2 |(S)| STOP-> PARITY-> 8 7 6 5 4 3 2 1 -> START -> |(S)| 2
3 | A | +------------------+ +-------------------+ | A | 3
4 | R | | Pegel-Wandler    | ------> | Pegel-Wandler     | | R | 4
5 | T | +------------------+ +-------------------+ | T | 5
6 | | RS-232C |   | 6
7 | | Bipolare Spannung    |   | 7
8 | | +/-12V (aber nicht 0V)      | | 8
   +---+    NEGATIVE SPANNUNG für HIGH bei RS232!    +---+
TTL-Spannung     TTL-Spannung
Unipolar 0-5V        Unipolar 0-5V

Der TNC kommuniziert mit der digitalen Computerschnittstelle (RS-232/DB25-Stecker) in seriellen Bitfolgen.
Der zweite Anschluss am TNC ist eine analoge Funk-Schnittstelle zum Funkgerät.

Hardware RS232 Spannungspegel

RS232-Schnittstelle (elektrisch):
(s. auch europäische Norm V28)
Arbeitet spannungsbasiert. Bemerkenswert sind die bipolaren Spannungspegel.

SPACE
V+ ___________      ___________
Logisch "0"|    | + 25V
   |    |      (typisch: +12V)
   |    | + 3V [Mindestspannung am Empfänger!]
0V ///////////|      |////////// (unused/undefined)
       |      |     - 3V [Mindestspannung am Empfänger!]
Logisch "1"| MARK |    (typisch: -12V)
       |_______| - 25V
V-

Informationen bei der RS232-Schnittstelle werden über (heute) ungewöhnliche Spannungen
PLUS 12V (Zustand 0 / "Space")
und
MINUS 12V (Zustand 1 / "Mark") übertragen.

(Anmerkung: Spannung / (inverse) Logik)

Spannungswerte zwischen -3V und +3V sind UNGÜLTIG und werden absichtlich ignoriert, um den Signalabstand zu vergrößern.
Grund: Längere Übertragungsstrecken und weniger Anfälligkeit für externe Störsignale.

Vorsicht:
Das direkte Anschließen von RS232-Spannungspegeln an die I/O-Pins heutiger Computerchips zerstört diese.
CPUs und Mikrocontroller vertragen meist nur 1.8V bis 3.3V (bestenfalls noch 5V) am Eingang.

(Lösung für Bastler: Pegelwandler/Level-Shifter verwenden!)

Anmerkung:
Die hohen Spannungspegel der RS232-Schnittstelle können natürlich auch nützlich sein.
Beispielsweise haben die BayCom-Modems daraus früher via Spannungsregler die notwendige Betriebsspannung generiert.

Verdrahtungsschema

Verbindung Computer <-> TNC:

Technisch benötigt man:

Eine gemeinsame Signal-Masse (GND=Ground / SG=Signal Ground).

Da die Schnittstelle Daten in beide Richtungen transportiert (FULL-duplex), gibt es:
TX(D) = Transmit Data
RX(D) = Receive Data

Für die direkte 1:1 Kopplung (der Signale) Computer mit TNC benötigt man diese Verbindungen:

Computer Zubehör wie TNC
[TERMINAL]    [Telefon-Modem]
TX -----> TX
RX    <-----    RX
GND <---->   GND (Signal-Masse/Signal Ground=SG)

Die seit den 1960er-Jahren verwendeten Stecker waren 25-Polige D-Sub-Stecker.
Diese werden von der RS232-Norm empfohlen (aber nicht vorgeschrieben).

Fünfundzwanzig Adern in einem seriellen Kabel machte diese Kabel "unflexibel" und vor allem teuer in der Herstellung.
Diesen (empfohlenen) 25-Poligen Anschluss findet man meist an einem TNC für die digitale Schnittstelle zum Computer.

Praktisch reichen für die asynchrone Kommunikation jedoch zwischen drei und sieben Adern.

Um beim PC-AT sowohl eine serielle als auch eine parallele Schnittstelle auf das Slotblech einer ISA-Steckkarte zu bekommen, musste ein kleinerer Stecker her.
Daher verwendet man am PC meist 9-polige D-Sub-Stecker.
Das ist auch einfacher zum Löten und bei der Fehlersuche.
Die Nummerierung der "Pins" weicht bei beiden Steckervarianten (DB9 vs. DB25) leicht ab.

(Im Zuge weiterer Miniaturisierung werden ggf. auch 8-polige Mini-DIN-Stecker oder RJ45-Stecker genutzt.)
Das Prinzip bleibt das gleiche - man verbindet die benötigten Signale.

Tipp:
Überprüfen Sie mit einem Durchgangsprüfer/Multimeter die Verbindungen.

Das für den TNC geeignete 3-Draht Kabel (ohne HW-Handshake) würde beim Durchgangstest eine 1:1 Verbindung besitzen:
von TX(D) zu TX(D) hier sendet der Computer Daten an den TNC
von RX(D) zu RX(D) hier erwartet der Computer Daten von dem TNC
und GND zu GND finden.

Sonderfall: Crossover-Kabel

Nimmt man das o.g. 1:1 Kabel (DTE <-> DCE) zur Verbindung von zwei Computern, wird die Kommunikation nicht funktionieren.
Beide Computer würden Ihre Daten über die gleiche Leitung absenden, aber keine Seite würde den Pin der Empfangsleitung prüfen.

Für den Sonderfall gibt es spezielle Crossover-Kabel.
Diese sind nur für eine Kommunikation zwischen Computer (DTE) <-> Computer (DTE) gedacht!

Computer    Computer
TX -------->   RX
RX             <-------    TX
GND          <-------> GND (Signal-Masse/Signal Ground=SG)

Die Verwendung eines solchen (Crossover-)Kabels für die Kommunikation von Computer zu TNC wird daher nicht erfolgreich sein.
Leider kann man die interne Drahtanordnung innerhalb eines Kabels von außen nicht direkt erkennen.

Sonderfall: Hardware-Handshake-Kabel
Die Verarbeitung von Daten durch ein Gerät benötigt immer Zeit.

Ist der Sender zu schnell für den Empfänger, dann können Daten verloren gehen.
Viele Chips (UARTS) haben nur sehr kleine Puffer, um Informationen zwischenzuspeichern (e.g. acht Bytes).

Wenn der Puffer voll wird, muss man die Datenaussendung der Gegenseite anhalten.

Das geht in einigen Fällen nur über Steuerzeichen (XON/XOFF).
Konkret, wenn keine Signalleitung verfügbar ist (Stichwort: Modemverbindung über das Telefon-Netz).

Andernfalls kann man das auch gleich schaltungstechnisch (in Hardware) realisieren.
Dies wird dann Hardware-Handshake genannt.
Und Überraschung: Es gibt da wieder mehrere Varianten.

Beispiele:
RTS/CTS   (RTS=Ready-to-send/CTS=Clear-to-send)
DSR/DTR (DSR=Data-Set-Ready/DTR=Data-Terminal-Ready)

Achtung:
Nicht jede Hardware unterstützt ein Hardware-Handshake.
Aber es gibt auch Hardware die das zwingend haben möchte.

Auch zu beachten:
Die Terminal-Software muss ggf. auch erst auf ein Hardware-Handshake konfiguriert werden.

Die Herausforderung für eine erfolgreiche Kommunikation:

Serielle Daten werden bitweise nacheinander übertragen.
Die zwei Geräte tauschen einzelne(!) Zeichen asynchron (d.h. ohne gemeinsamen Takt) aus.
D.h. die Uhren der Geräte müssen nicht synchron laufen.

Herausforderungen auf Seite des Empfangsgerätes:

Es kann zwar den Spannungsabstand der Empfangsleitung (RxD) zur Signalmasse (SG oder GND) feststellen, schwieriger ist es festzustellen, wann zeitlich die einzelnen Bits vorliegen.

Signalisieren die Spannungen wirklich Daten? Ist es "zufällig" eine Störspannung?
Welche Spannung stellt die binäre "0" dar? Welche die binäre "1"?
Aus wie vielen Bit besteht ein Zeichen (5-8)?
Kommt der größte Bitwert zuerst (MSB-Bit) oder der kleinste (LSB-Bit).
Wie erkennt man Übertragungsfehler?
Weitere Herausforderungen:
Aussendungen der Gegenseite anhalten/ganz stoppen?
Daten von Steuerzeichen unterscheiden?
Zeichen werden mit welchem Bitmuster dargestellt?

Beide Geräte müssen ein gemeinsames Verständnis für das verwendete Kommunikations-PROTOKOLL haben.
Ggf. auch noch über die Darstellung von Zeichen/Sonderzeichen.

ASYNC-PROTOKOLL (Logische Sicht)

Asynchrone (START/STOP-) Kommunikation wird benutzt, wenn man einzelne Zeichen übertragen möchte und die Zeitabstände zwischen den einzelnen Zeichen unterschiedlich sind. Eine separate Taktleitung bei Funkverbindungen ist darüber hinaus nicht realisierbar.

8N1     SPACE
_________     ................................__________________
   |     |        |    |
   |     |        | ^ |
IDLE    |     | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | S |        IDLE...
   |     |        | T
   |     |        | O
   |     |        | P
   |     |    |
   |     |<----------------------------->| 1
   |     | (8 Daten-Bits)    |
   |_____|    |
    MARK

7E1 SPACE
_________ ................................_______________
   |    |    | |   |
   |    |        | | ^ |
IDLE    |    | 0 | 1 | 2 | 3 | 4 | 5 | 6 | P | S |    IDLE...
   |    |    | A | T
   |     |    | R | O
   |    |    | I | P
   |    |    | T |
   |     |<------------------------->| Y | 1
   |     | (7 Daten-Bits)    |   |
   |_____| |   |
   MARK
       |<--------------------------------------->|
      (Frame enthält ein Zeichen)

Frame

Die Einheit der Bits vom

START-Bit (MARK)
gefolgt von den (n=5..9) Daten-Bits
einem optionalen Parity-Bit
und ein / anderthalb / zwei STOP-Bits (SPACE)

wird als Frame bezeichnet.

Der Start einer Datenübertragung wird zunächst per START-Bit angekündigt.
Der Ruhezustand ist definiert (z.B. +12V bei RS232).
Die Übertragung startet aus dem definieren Ruhezustand mit einem Flankenwechsel.
Wechselt also in den andern definierten Spannungspegel (z.B.von +12V nach -12V).

Dieser Spannungspegel wird jetzt für die Zeitdauer der Übertragung einer Signalinformation (also ein Bit) auf einen anderen Zustand gewechselt.

Nach erfolgter Ankündigung werden n Bit (Früher 7 Bit heute: 8 Bit) auf die Leitung geschickt.

Optional folgt genau ein Prüf-Bit (Parity)

Danach kommen noch eventuelle Zeiten zur Übertragung von STOP-Informationen ("STOP-Bits"), d.h. der Zustand wechselt für (mindestens) die Zeitdauer von 1-2 Bit auf SPACE.

Der SPACE-Zustand bleibt bestehen, bis das nächste START-Bit ("Mark") empfangen wird und der Vorgang wieder von Neuem startet.

Das Empfangsgerät überprüft (im UART) gemäß seiner Einstellungen, ob ein Fehler vorliegen könnte (hierzu wird das Parity-Bit ausgewertet).
Sofern ein "vermeintlicher" Fehler vermutet wird, wird das über einen FRAME-ERROR an die Software im Gerät signalisiert.
Was die Software damit macht, ist dann eine andere Sache.

Konkret heißt das:
Man muss sich (beiderseitig) vor der erfolgreichen Kommunikationsaufnahme auf eine gemeinsame Geschwindigkeit (z.B. 9600 Baud) für beide Geräte einigen.

Am TNC wird das meist von außen über Mäuseklaviere oder Jumper eingestellt.
Für die Kommunikation (Computer <-> TNC) ist die Geschwindigkeit auf der seriellen Leitung entscheidend.

(Vorsicht: Bitte nicht mit der Einstellung für die analoge Funk-Geschwindigkeit (1k2 im CB-Funk) verwechseln!)

Wie viele Bits werden zur Darstellung eines Zeichen benutzt? 2^7 oder 2^8. Das muss auf beiden Geräten gleich konfiguriert werden.
Möchte man nach der Übertragung des letzten Bits eine zeitliche Pause von einem , anderthalb oder zwei STOP-Bits?

Auch der Versand eines Kontroll-Bits (Parity) kann konfiguriert werden.
Keine Prüfsumme (N=No), Gerade Prüfsumme (E=Even), Ungerade Prüfsumme (O=Odd).

Achtung:
PC (Betriebssystem/Software) und TNC müssen mit den gleichen Einstellungen arbeiten.

Anhand der Skizze oben kann man sich das klar machen.
Wenn der Computer mit 8N1 Daten schickt, gibt das mit hoher Wahrscheinlichkeit ungültige Daten beim TNC, wenn der auf 7E1 interpretiert. (-> Frame error im TNC).
Wenn der TNC auf 7E1 konfiguriert ist und der Computer 8N1 erwartet, dann zeigt der Computer dagegen unsinnige Zeichen am Terminal (weil die Parity dann die Zeichen verfälscht).

Typische Terminal-Emulationseinstellungen

Schrittgeschwindigkeit in Baud: 9600 (PC-typisch), 19200 (das kann nicht jede Hardware bzw. Software)
Datenbits: 8 (typisch)
Prüfsumme: No (typisch)
Stop-Bits: 1 (typisch)

Die typische Einstellung am Terminal-Emulationsprogramm des Computers:
9600 Baud 8N1 bei TNC mit Host-Mode

oder falls man einen TNC noch mit der orginal TAPR-Firmaware im (native) Terminal-Mode betreibt:
9600 Baud 7E1

Anmerkung:
Die Geschwindigkeit muss für beide Geräte (Computer und TNC) identisch konfiguriert werden.
D.h. man könnte z.B. 1200 / 2400 / 4800 / 9600 verwenden.
(Tipp: Die gewählte Zahl durch 75 geteilt sollte eine Zweierpotenz liefern)
Die digitale Schnittstelle Computer <-> TNC darf dabei schneller konfiguriert werden, als die im TNC verbauten Funk-Modem(s) (1200 Baud / AFKSK).

Eine asychrone Übertragung erzeugt einen gewissen Zusatzaufwand.
D.h. um 8 Bit (Netto-Daten) zu übertragen, benötigt man

1 Start
8 Daten
(optional) ein Parity
mindestens ein STOP-Bit

(Brutto-Daten: 10-12 Bit)
Daumenregel: 10 Bit um ein Byte zu übertragen.

Zusätzlich kann man für sein Terminal konfigurieren, ob man bestimmte Zeichen zum Anhalten/Fortsetzen der Übertragung nutzen möchte.

Die Einstellung heißt meist XON/XOFF (oder Software-Handshake).

Die verwendeten Zeichen sind dabei extra so gewählt, dass sie in "normalen" Texten nicht vorkommen.
CTRL-S hält die Übertragung an
CTRL-Q setzt die Übertragung fort

Falle:
Bei der Übertragung binärer Daten oder Dateien können diese aber -unabsichtlich- die Übertragung zwischen Computer und TNC anhalten.

Es gäbe auch noch die Alternative einer Hardware-Handshake-Konfiguration (entsprechende Geräte und Kabel vorausgesetzt).

Eventuell kann man in der Terminal-Emulation auch noch weitere Dinge konfigurieren:
Auswahl zwischen mehreren vorhandenen Schnittstellen: COM1 ... COM4

Bei manchen Terminal-Emulationen (e.g. Tera Term) kann man Pausenzeiten zwischen der Übertragung von Zeichen oder Zeilen konfigurieren.
Das wird eher selten benötigt.

Bei Computern unter DOS
Adressregister serieller Schnittstellen, z.B. 2F8h/3F8h/2E8h/3E8h
Konfiguration Interrupt-Request (IRQ) Nummer.

IRQ können zu Konflikten führen. Praktisch sind daher beim PC nur zwei COM-Ports aktiv nutzbar!

COM1 / IRQ4 / Port 3F8h (e.g. für Maus) unter Linux: /dev/ttyS0 (s. man setserial)
COM2 / IRQ3 / Port 2f8h (e.g. für TNC) unter Linux: /dev/ttyS1
COM3 / IRQ4 / Port 3E8h unter Linux: /dev/ttyS2
COM4 / IRQ3 / Port 2E8h unter Linux: /dev/ttyS3

---------------------------------------------------------------------------------------------------
Zum Nachschlagen:

Begriffe / Erklärungen rund um serielle RS232-Schnittstellen

(typischerweise für asynchrone Kommunikation verwendet)

Eigenschaften RS232:

Exakt zwei Teilnehmer (Punkt-zu-Punkt)
FULL-Duplex
asymmetrische Spannungsübertragung mit Massebezug

logisch "1" der LOW-Pegel (MARK) ist <= - 3 V
logisch "0" der HIGH-Pegel (SPACE) ist >= + 3 V
maximal +/- ca. 25 Volt    (im PC-Bereich typisch: +/- 12V)

Kabellänge max. 15-20 Meter

Damit bekommt man ca. 20 Kilobits/s (19.200 Baud) hin (im Bereich der Norm).
Mit hochwertigen Kabeln ggf. auch bis 115 Kilobits/s
Letzteres wird aber von alten Rechnern nicht beherrscht.

Normen:
RS-232C              offiziell EIA-RS232C genannt. Der letzte Buchstabe kennzeichnet die Revision des Standards (aktuell "F" statt "C")
RS-422A              ähnlich RS-232C arbeitet aber mit differentiellen Signalen (symmetrische Spannungsübertragung)
RS-485                verbesserte Version von RS-422
V24                   Europäische Norm für RS-232C
V28                   Europäische Norm für Spannungspegel bzgl. V24/RS-232C
DIN66020/66021

UART/ACIA Chip für asynchrone Kommunikation (Universal Asynchronous Receiver)/(Asynchronous Communication Interface Adapters)
USART    Chip für synchrone oder asynchrone Kommunikation

Geschwindigkeit/Datenübertragungsrate:
Baud        : Anzahl der (maximalen) Signalwechsel zwischen Mark und Space pro Sekunde
          (1200 Baud entsprechen dabei einem Rechtecksignal von 600 Hz)
bps:        : Durchsatz (logischer) Bit pro Sekunde

Baud ist nicht unbedingt Bit/s (!)
Es gibt Modulationsarten die mehr als 1 Bit in einem Schritt übertragen.

cps          : Chars per Second
            Netto Übertragung von Zeichen pro Sekunde (meist bps/10 ... w.g. 8N1)

TTY    : Teletype ein 5 Bit-Code (für 32 Zeichen)
EBCD : Ein 6-Bit-Code mit dem man 64 unterschiedliche Zeichen darstellen kann
US-ASCII : Amerikanischer Standard um Zeichen zu kodieren. Die (amerikanische) ASCII-Norm verwendet nur 7 Bit und kann 128 Zeichen darstellen.
EBCDIC : Mainframe-Standard um Zeichen zu kodieren: Ein 8 Bit-Code

COM1-4 : Namen (im BIOS bzw. DOS) für serielle Schnittstellen in Personal-Computern älterer Bauart.
         Diese werden dort meistens über DB9-Anschlüsse bereitgestellt.

FRAME : Start/Daten/Parity/Stop-Bits (in Bezug auf serielle Schnittstellen).

Datenbits: 5-9 (heute meist 8, früher auch 7) pro Zeichen

Datenflusskontrolle
RTS/CTS

Signalnamen
(aus der Sicht des Computers!)
RxD              Received data     DATEN
TxD           Transmitted data DATEN
SG                Signal-Ground                  Betriebserde

RTS     Request to send    FLOW-Control
CTS     Clear to send       FLOW-Control

DTR    Data terminal ready
DSR    Data set ready
DCD    Data carrier detect
RI      Ring indicator

Chips für serielle Kommunikation

UART Chips in PCs

8250
16450
16550

Als Z80-SIO

Z8440

ACIA vielfach in Homecomputern

6551
6850

Level-Shifter / Pegelwandler

MAX232
MC1488
MC1489
SN75188
SN75189

Aus meinem Archiv: Routing im PR Box-Netz

Sun, 19 Apr 2026 13:41:38 +0200

Inhalt
======
1. Einleitung

2. Was ist Routing ?
2.1 Bulletins
2.2 P-Mails

3. Konfigurieren des Routings
3.1. Die eigene H-Route

3.2. S&F Konfiguration bei FBB
3.2.1 BBS.SYS
3.2.2 FORWARD.SYS
3.2.3 Die S&F Files in /FBB/SYSTEM/FWD
3.2.4 Einrichten des S&F

3.3. S&F Konfiguration bei WinBox/DP-Box
3.3.1 Die .SF Files

3.4. S&F Konfiguration bei Baycombox
3.4.1 Die S&F Datei FWD.BCM
3.4.2 Einrichten des S&F

4. Autorouter
4.1 Autorouting Programme bei FBB
4.1.1 Forwardmaker
4.1.2 Forwardroute

4.2 WinBox (DP-Box) Autorouter
4.3 Baycom Box Autorouter

5. Danksagungen
6. Quellenangaben

1. Einleitung
=============

Hallo liebe Sysops und PR'ler !

Mit diesem Hilfetext moechte ich all jenen helfen die Probleme damit haben
ihr S&F richtig zu konfigurieren. Sie setzt da an wo die Installation des
Boxsystems beendet ist und die Funkverbindung steht. Ich hoffe das ich es
einigermassen verstaendlich hin bekomme. Fuer Kritik bin ich sehr dankbar.
Und Leuten die etwas hinzufuegen moechten stehe ich offen gegenueber. Falls
sich das Konzept durchsetzen sollte waere es schoen, wenn man getrennte How-
To's fuer jedes einzelne Boxsystem entwickeln koennte. Diese sollten dann
von der Installation ueber die Konfiguration bis zu Insider-Tipps reichen.

2. Was ist Routing ?
====================

Unter Routing versteht man die Wegsuche zu einem Ziel. Dieses kann auf
verschiedene Arten geschehen. Um beim Mailboxnetz zu bleiben muessen wir
erst einmal definieren welche Arten von Mails es in unserem Netz gibt. Zum
einem gibt es die oeffentlichen Mails (Bulletins) die jeder lesen kann und
die privaten Mails (P-Mails) die nur an eine bestimmte Rufzeichen gehen.

2.1 Bulletins
~~~~~~~~~~~~~

Geroutet werden streng genommen wirklich nur die P-Mails, denn die Bulletins
werden in unserem Netz "verteilt". Eine Bulletin Mail hat als Beispiel
folgendes Adressfeld:

ALLE @ DEU
I I
I +--- Dieses Feld ist der Verteiler der Mail
+---------- Das ist die Rubrik in der die Mail eingespielt worden ist

Das erste Feld sollte keine Fragen aufwerfen, denn man sucht sich eine
Rubrik aus, in der man seine Mail einspielen will. Das kann eine allgemeine
Rubrik sein wie in diesem Beispiel die Rubrik ALLE, aber auch
themenspezifisch wie PCSOFT oder CBFUNK.

Das zweite Feld, der Verteiler, bestimmt in welchem Gebiet oder Zugehoerig-
keitsbereich die Mail zu lesen sein soll. Laesst man diese Feld leer, so
bleibt die Mail nur in der Box liegen wo die Mail eingespielt worden ist,
falls der Sysop nicht bei leerem Verteilerfeld ein @ DEU konfiguriert hat.
Eine Unart die es immer noch haeufig zu finden gibt.
Sinn und Zweck des ganzen soll sein, das der Inhalt einer solchen Mail
vielleicht nur einem kleinen Kreis zukommen soll. Ankuendigungen zu einem
PR-Treffen sind nur in der Region wichtig, wo es statt findet. Es waere
Bloedsinn wenn die Mail 500 KM weiter in einer entfernten Box auch noch zu
lesen ist, die mit diesem regionalem Treffen nichts zu tun hat.

Es haben sich einige standart Verteiler herraus kristallisiert, deren
Anwendung ich mal kurz umreissen will. Es hat sich eingebuergert die Kuerzel
der Kontinente, Laender, Bundeslaender und Landkreise zu benutzen um das
Gebiet festzulegen bis wohin eine Mail verteilt werden soll. Hier ein paar
Beispiele:

@ WW = Weltweit an jede Box
@ EU = An jede Box in Europa
@ DEU = Zu jeder Box in Deutschland
@ NDS = Fuer alle Boxen in Niedersachsen

Wichtig ist hierbei zu nennen das es nicht moeglich ist eine Mail an @ BAY
aus einer Box in Niedersachsen zu verschicken. Da eine solche Box den
Verteiler @ BAY nicht Forwarden sollte. Es muesste eine Meldung wie z.B.
"Keine Route zum Ziel bekannt!" kommen.

Neben diesen standart Verteilern kann man als Sysop auch eigene definieren.
Das ist zum Beispiel guenstig wenn man Vereins oder PRIG Nachrichten
verteilen will. Nachrichten die an diesen Verteiler geschrieben werden,
landen nur in den Boxen die Mitglied in der genannten PRIG sind.

2.2. P-Mails
~~~~~~~~~~~~

Ab hier wirds kompliziert ! Eine P-Mail geht nicht an alle Boxen im Netz,
sondern soll nur zu einer ganz bestimmten geroutet werden. Am einfachsten
waere es wenn die Absenderbox die Zielbox direkt connecten, und die Mails
dort abliefern koennte. Dieses nennt man "Simplen Mailtransfer" und wird bei
E-Mails im Internet angewand. Dieses ist im CB PR-Netz nicht moeglich da es
schlecht einen direkten Link geben wird der Hamburg und Muenchen verbindet,
damit die Mails ausgeliefert werden koennten.

Man ist also darauf angewiesen eine Mail durch mehrere Mailboxen, die ein
Netz bilden, zum Ziel zu schicken. Auch fuer dieses Verfahren das sich
eigentlich nur "Store & Forward" nennt gibt es mehrere Moeglichkeiten. Ich
nenne hier nur die beiden wichtigsten, die auch weiter unten in die Forward-
files unserer Boxen wieder zu finden sind.

Smart-Host Routing
******************

Das erste ist das Smart-Host Routing, und das wird folgendermassen
definiert. Jede Box im PR-Netz ist ein Smart-Host. Er verfuegt ueber
Informationen die angeben an welche Box eine Mail geleitet wird in
Abhaengigkeit des Empfaengers. Nicht ganz verstanden ? Also hier mal
Bildlich:

BOX01 hat die Forwardpartner BOX02 und BOX03. BOX03 hat als Forwardpartner
BOX04. BOX01 bekommt jetzt eine P-Mail rein die fuer einen User von BOX04
bestimmt ist. Damit BOX01 jetzt weiss welche Box die Mail an BOX04 weiter-
leiten kann, an BOX02 oder BOX03, muss der Sysop von BOX01 das ins Forwardfile
eingetragen haben. Dort muss sinngemaess dann stehen "Mails fuer BOX04 muessen
an BOX03 weitergeleitet werden".

Das sieht zwar sehr einfach aus, doch haben wir in unseren PR-Netz weit
ueber 300 Boxen. Alle diese Boxen muessten in den Forwardfiles drinne
stehen, damit das weiterleiten von P-Mails sicher funktionieren kann. Das
waere ne Menge Text die ein Sysop jeder Box im Netz in seine S&F Files
tippen muesste. Auch Aenderungen muessten vorgenommen werden, sowie eine
neue Box im S&F Netz hinzukommt oder sich abmeldet. Das ist nicht immer
einfach, da ja fast taeglich neue Boxen hinzukommen oder QRT machen.

Dieses Smart-Host Routing ist also nur fuer kleine Netze sinnvoll
einsetzbar. Im CB-PR kann man es verwenden um das Routing auf Stadt- oder
Landkreisebene zu Konfigurieren. Alles was darueber hinaus geht, sollte vom
Domain- oder H-Routing erledigt werden.

Hierachial-Routing
******************

Unter Domain-Routing, im PR H-Routing genannt, wird eine Gruppe von Zielen
unter einem Ziel zusammen gefasst. Na verstanden ? Nicht ? Also dann ans
eingemachte. Eine Mailadresse im PR-Netz setzt sich so zusammen:

DMA284 @ DBO284.#GF.NDS.DEU.EU

In diesem bischen Text stecken einige Informationen. Da waeren einmal das
Call des Users und der Zielbox, sowie deren ungefaehrer Standort. Es ist die
vollstaendige Adresse einer Box die vergleichbar ist mit einer Adresse auf
einem Brief. Wenn ich eine Briefadresse in diese Format bringe, wuerde das
z.B. so aussehen:

DMA284 @ DBO284.16.Hauptstrasse.Musterhausen.12345.Deutschland.Europa

Wenn ich diese Adresse von Rechts nach Links lese, kann ich einen Weg
erkennen die der Brief gehen muss um beim Empfaenger anzukommen.

Durch diese Schreibweise, habe ich einen nicht zu verachtenden Vorteil. Denn
ich kann dadurch ganz einfach alle Adressen die sich hinter Europa (.EU)
befinden in nur einer einzigen Zeile in meinem S&F File meiner Mailbox
definieren. Eine Mailbox in Amerika die direkten S&F mit einer europaeischen
Box hat koennte also sagen: "Mailadressen die auf .EU enden werden an die
Mailbox EURO01 weiter geforwardet". Wenn diese Amerikanische Box aber keinen
direkten S&F hat, so kann sie aber eine Mail die nach Europa soll an die
naechst gelegenste Box die in Richtung Europa liegt weiterleiten. Hat diese
auch keinen direkten S&F nach Europa sendet sie ihrerseits die Mail an ihre
naechste Nachbarbox in Richtung Europa. Das geht dann solange bis die Mail in
einereuropaeischen Box landet.

Dort angekommen wird das gleiche Prinzip angewendet. Es wird versucht die
Mail nach Deutschland zu befoerdern. In Deutschland wiederum wird sie nach
Niedersachsen geforwardet. In Niedersachsen wird sie in den Landkreis
Gifhorn geschickt. Und im Landkreis Gifhorn "muss!" dann eine Box wissen wie
es zur DBO284 geht. Hier wendet sie dann das Smart-Host Routing an, das der
Sysop eingetragen haben muss. Da es in einem Landkreis nur wenige Boxen
gibt, ist das dann auch einfach zu bewerkstelligen.

Man kann das ganze in einem kleinen Spruch festhalten:

>>> Ich kenne jemanden, der jemand kennt, der weiss wo das Ziel ist <<<

In dieser Geschichte stecken aber auch so seine Fallen. Denn die Sysops
muessen sich einig werden wo was hin geroutet wird. Das Netz muss in Grund-
zuegen organisiert sein. Wenn der Sysop von der Deutschen BOX01 meint, das
der beste Weg nach Niedersachsen (NDS) ueber BOX02 geht. Der Sysop von BOX02
aber meint das es genau umgekehrt ist, haben wir schon ein Problem. Deswegen
muessen sich auch die Sysops untereinander absprechen wer was wo hin routet.

In groben Zuegen kann die Himmelsrichtungen schon das Routing vorgeben. Wenn
ich einen Forwardpartner habe der oestlich von mir steht, route ich da
eigentlich alles hin was oestlich von mir steht. Das es nicht immer so
gemacht werden kann versteht sich von selber. Deswegen ist ja auch eine
Absprache der Sysops wichtig, damit dieses System funktioniert.

3. Konfigurieren des Routings
=============================

Dieser Abschnitt befasst sich nun mit dem erstellen der Eintraege in den S&F
Files der jeweiligen Boxsyteme. Ich gehe davon aus, das diese Files schon
erstellt sind, bzw. die default Dateien vorliegen und je nach Art der S&F
via Funk oder Exportfiles schon funktioniert.

3.1 Die eigene H-Route
~~~~~~~~~~~~~~~~~~~~~~

Wichtig fuer das Betreiben einer Mailbox im S&F Netz ist, das die H-Route
der eigenen Box richtig definiert ist. Immer wieder sieht man unsinnige H-
Routen die dem Netz nur schaden anstatt wirklich zu nuetzen. Wie oben beim
H-Routing schon erwaehnt, wird die H-Route von Rechts nach Links gelesen und
ausgwertet. Das bedeutet fuer uns, das am Ende immer ein Kontinent steht !!!

Nicht wie vielfach in Netz vertreten ein .WW <-- Dieses gibt es nicht !!!

Auch sonstige Endungen hinter dem Kontinent gibt es nicht. Wenn ihr trotzdem
sowas verwendet, wundert euch nicht das in eurer Box ausser von den direkten
Forwardpartnern keine P-Mails in eurer Box landen. Hier mal eine Box die
sowas drinne stehen hat:

IT5TNT.LU.TSC.ITA.EU.SP/G <-- Diese Box steht in Sicilia, Italien

Wenn ich eine Mail an diese Box schreiben will, bekomme ich eine Fehler-
meldung von meiner Box: Routing Error, Unknown Route ! Ich koennte diese
Route als Sysop zwar per Hand nachtragen, aber spaetestens bei der naechsten
Box die vernuenftig konfiguriert ist wird die Mail haengen bleiben und als
"Undelivered" (Nicht ausgeliefert) zurueckkommen.

Die H-Route fuer eine Box in Deutschland sollte so aussehen:

DBO284.#GF.NDS.DEU.EU
I I I I I
I I I I Kontinent
I I I Land
I I Bundesland
I Landkreis
Boxcall

Man kann natuerlich, wenn erforderlich, diese H-Route noch erweitern. Diese
Box hat es getan:

NB0PAF.#PAF.OBB.BAY.DEU.EU <-- Diese Box steht in Pfaffenhofen JN58RM

Der Sysop der Box hat wohl noch einen Stadt Kenner mit eingefuegt. Wenn ich
die Adresse von Rechts nach Links lese wird sie nur etwas genauer, bringt
aber nicht mein Routing durcheinander. Da es fuer meine Box nur wichtig ist,
das sie in BAY.DEU.EU steht.

Es gab mal Zank im CB PR-Netz bezueglich der "#", auch Raute oder
Doppelkreuz genannt, ob diese in die H-Route reingehoehrt oder nicht. Dazu
kann ich nur sagen das es heutigen Boxsystemen total egal ist, ob das Ding
nun da ist oder nicht. Wenn man es jedoch benutzt, sollte es am Anfang des
ersten Kenners stehen, wie oben in den Beispielen. Nicht irgentwo mittdrin in
der H-Route.
Vergisst man das # bei der Eintragung einer H-Route in ein S&F File, kann es
sein das keine Mails geforwardet werden. Mehr passiert nicht. Ich verrate
nachher wie man diesen Fehler umgehen kann beim einrichten der S&F Files. Der
Grund warum dieses "#" jemals in die H-Routen reingekommen ist, war wohl mal
die Inkompatibilitaet zweier Boxsysteme. Anstatt die Boxsysteme zu aendern hat
man sich ne Kruecke gebaut und die # zum ersten Block der H-Route eingefuegt.

Die H-Route der Box wird bei FBB mit dem Tool FBBSETUP.EXE eingetragen oder
direkt in die Datei INIT.SRV. Bei WinBox mit dem beiliegenden Setup-Programm.

3.2 S&F Konfiguration bei FBB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kommen wir nun zum Konfigurieren einer FBB Mailbox. Diese Files sind wichtig
fuer die Einstellungen des S&F bei einer FBB Box:

BBS.SYS
FORWARD.SYS
und die S&F Files im Verzeichnis /FBB/SYSTEM/FWD

In der BBS.SYS werden die Calls der S&F Partnerboxen eingetragen. Diese File
hat 80 Zeilen die auch von 1-80 durchnumeriert sind. Dieses File darf nicht
gekuerzt werden oder sonst in irgenteiner weise veraendert werden ausser dem
eintragen der Forward Boxen.

In der FORWARD.SYS werden die Parameter eingetragen fuer jede Box mit der
man Forward macht. Wie diese genau gemacht wird erklaere ich weiter unten.

Die S&F Files in dem Verzeichnis /FBB/SYSTEM/FWD sind nur die ausgelagerten
Konfigurationen die eigentlich auch im FORWARD.SYS File stehen koennten. Der
Uebersichtlichkeit wegen, werden sie aber getrennt in diesem Verzeichnis
gespeichert.

3.2.1 BBS.SYS
~~~~~~~~~~~~~
Hier werden nun von der ersten Zeile an die Calls der Boxen eingetragen mit
denem man S&F machen moechte:

##########################
# BBS.SYS for FBB 7.00 #
# for LA6CU BBS by LA6CU #
##########################
#
# File containing all BBSs we forward to.
#
# Make sure that NO numbers are removed.
#
01 DBO217
02 DBX355
03 AL1BOX
04 PD2BOX
05
06
...
78
79
80

Es ist wichtig, das die Zeilen bis 01-80 unveraendert, bis auf die eingetra-
genen Boxen, erhalten bleiben muessen ! Die Boxcalls werden ohne SSID
eingetragen. Will man mit einer Box kein S&F mehr betreiben, so muss das
Call aus diesem File ausgetragen werden. Die FBB Doku gibt an das man an den
frei werdenen Stellen keine neue Box eintragen oder die nachfolgenden Boxen
aufruecken lassen soll. Es koennte zu Fehlern beim S&F fuehren. Diese ist
bei meiner Box allerdings nie passiert.

3.2.2 FORWARD.SYS
~~~~~~~~~~~~~~~~~
In diesem File werden normalerweise die Forward-Definitionen zu den
verschiedenen Boxen eingetragen. Wenn man viele Forwardpartner hat wird das
irgentwann unuebersichtlich. Deswegen werde ich hier nur beschreiben wie
dort die Pfade eingetragen werden, wo die eigentlichen S&F Files liegen.

FORWARD.SYS:

################
# Forward-file #
# for DBO284 #
################
#
# HF Kanal 24
#
< FWD\DBO217
#
# HF Kanal 52
#
< FWD\AL1BOX
< FWD\DBQ902
#
# EXPORT
#
< FWD\DBX355
< FWD\PD2BOX
#

Wie oben zu sehen werden die Pfade zu den S&F Files in dieser Datei gesetzt.
Spitze Klammer < gefolgt von dem Pfad und dem Namen des Forward Files. Die
Namen der Forward Files koennen beliebig benannt werden. Der Einfachheit
halber haben sie das Call der Forwardbox als Namen. Kommentare koennen
hinter einer Raute # eingetragen werden. Die Pfandangabe richtet sich nach
dem wo sich das FORWARD.SYS File befindet. In meinem Fall liegen die S&F
Files in C:\FBB\SYSTEM\FWD

3.2.3 Die S&F Files in \FBB\SYSTEM\FWD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Um den Forward zu definieren muss man im Verzeichnis /FBB/SYSTEM/FWD ein
File anlegen das im Namen mit dem uebereinstimmt was man im FORWARD.SYS File
eingetragen hat.

*****************************************************************************
Ich weise nochmal darauf hin das ich hier nur erklaeren moechte wie das
Routing bei FBB eingestellt wird. Die Teile die auch die Forwardzeiten und
den Connectaufbau zur Zielbox betreffen, werden hier nicht erklaert. Das ist
bitte der FBB Doku zu entnehmen !
*****************************************************************************

Die Zeilen die mit dem Routing von Mails zu tun haben beginnen in einem
Forward File mit den Buchstaben A, B, F, G und H. Diese haben folgende
Bedeutung:

A : Muss in der ersten Zeile eines S&F Files stehen. Es enthaelt das
Call des Forwardpartners ohne SSID.

B : Hiermit wird eine Zielbox mit angegeben zu der Persoenliche Mails
geforwardet werden sollen. Eine Zeile mit B des
Forwardpartners muss in jeden S&F File vorhanden sein. Weitere
Box Calls koennen in einem Forwardfile mit B angegeben werden
wenn der Forwardpartner auch zu diesen Mailboxen S&F hat. Jede
B Zeile darf nur ein Call besitzen.

F : Hiermit kann ein User-Call angegeben werden welches auch zu
diesem Forwardpartner geroutet werden soll. Es sollte mindestens
einmal das Boxcall des Forwardpartners mit angegeben werden. Es
koennte mit dieser Option auch das Call des nachbar Sysops einge-
tragen werden. Dann werden unabhaengig von WP-Eintragen, Mails
fuer dieses Call immer zu der Box geforwardet fuer welches das
Forwardfile gilt. Jede F Zeile darf nur ein Call besitzen.

G : Hiermit werden die Verteiler von Bulletins festgelegt welche
zur Nachbarbox geforwardet werden sollen. Jede G Zeile darf
nur einen Verteiler aufnehmen. Verteiler sollten die Laenge
von 6 Zeichen nicht ueberschreiten.

H : Hiermit kann man H-Routen Definitionen eintragen ins S&F File.

Es gibt noch weitere Zeichen, diese befassen sich aber mit dem Linkaufbau,
Forwardzeiten und aehnlichem. Bei allen Angaben koennen auch Platzhalter
angegeben werden. Die Platzhalter sind folgende:

* = Steht fuer beliebige Zeichen vor und nach einer Zeichenkette. Z.B.:
B DBO* wuerde bedeuten alle Mails an Boxen die mit DBO beginnen
Forwarden.

? = Steht fuer "ein" beliebiges Zeichen vor, nach oder in einer Zeichenkette.
Z.B.: F GF?ABC heist Mails fuer Calls wie GF1ABC, GF2ABC usw. Forwarden.

Beide Platzhalter koennen auch kombiniert werden.

! = Ein Ausrufezeichen vor einem der Buchstaben negiert die Angabe. So ist
es moeglich mit der Zeile !H *.#GF.NDS.DEU.EU zu sagen. Das H-Routen
die auf .#GF.NDS.DEU.EU enden nicht geforwardet werden duerfen.

Fuer Komentarzeilen im Forwarfile ist das Zeichen "#" Vorgesehen. Alles was
hinter einem # steht wird ignoriert. Das gilt nicht, wenn das # Teil einer
H-Route ist. Das # muss deswegen am Beginn einer Zeile stehen. Nicht inner-
halb von Zeilen verwenden ausser bei H-Routen !

3.2.4 Einrichten des S&F
~~~~~~~~~~~~~~~~~~~~~~~~

Ich versuche hier jetzt mit Beispielen aus meiner Box zu erklaeren wie eine
Konfiguration aussehen kann. Ich hoffe es kommt einigermassen verstaendlich
rueber. Fangen wir mal mit dem Einfachsten an. Dem Definieren der Verteiler
fuer die Nachbarbox.

Bulletins
*********

Es ist eigentlich ganz einfach. Man weiss ja wo seine Partnerboxen stehen.
Dem entsprechend richte ich die Verteiler der Bulletins ein. Einer meiner
S&F Partner (AL1BOX) ist im gleichem Landkreis. Sie bekommt folgende
Verteiler von mir:

G WW <- Alle Mails an @WW WeltWeit
G EU <- Alle Mails an @EU Europa
G DEU <- Alle Mails an @DEU Deutschland
G DL <- Alle Mails an @DL Deutschland (Wird bei STOP-Boxen verwendet)
G NDS <- Alle Mails an @NDS Niedersachsen
G NORD <- Alle Mails an @NORD Fuer die Nordeutschen Bundeslaender SLH,
NDS, HB, HH und MVP
G GF <- Alle Mails an @GF Landkreis Gifhorn
G THEBOX <- Systemmails an @THEBOX weiterleiten. Wichtig damit Boxsysteme
wie Win-, Baycom-, und DP-Box ihre System-Mails bekommen

Haette ich einen Forwardpartner in Bayern z.B. so wuerde ich nur folgende
Verteiler eintragen:

G WW
G EU
G EURO
G DEU
G DL
G THEBOX

Ein G BAY waere bloedsinn, da ein User in Niedersachsen keine Mails an @BAY
versenden sollte. Um das denoch zu koennen gibt es bei FBB und anderen
Boxsystemen bestimmte Server (REDIST). Deren Setup will ich aber hier nicht
naeher erklaeren.

Aus diesen obigen Beispielen sollte eigentlich klar geworden sein wie das
ganze einzutragen ist. Ein G * sollte auf keinen Fall eingetragen sein, denn
damit wuerde die Box alle Verteiler weiter forwarden die es gibt. Dieses wird
nicht gerne gesehen, denn dann waeren Verteiler sinnlos.

Persoenliche Mails
******************

Kommen wir zur Konfiguration des Forwards fuer die Persoenlichen Mails.
Eines der schwierigsten Themen ueberhaupt. Ich hoffe ihr habt noch meine
Ausfuehrungen von Abschnitt 2.2. im Kopf ! Wenn nicht, blaettert noch mal
kurz zurueck.

Um Persoenliche Mails mit FBB zu forwarden muessen mindesten schon mal die
Eintraege B und F vorhanden sein. Jeweils eine Zeile gefolgt mit dem Boxcall
des Forwardpartners:

B AL1BOX
F AL1BOX

Ihr koennt auch mehrere B und F Eintraege haben. Wenn man weiss mit welchen
anderen Boxen der Forwardpartner auch noch S&F macht, koennen die Calls mit
B eingetragen werden. Mit F sollten nur User der Nachbarbox
eingetragen werden, wie z.B. der Sysop. Dieses ist allerdings nicht noetig,
da es reicht wenn man nur mit B die Boxen eintraegt. Der Rest wird ueber die
Userdatenbank der Box (White Pages, WP) gemacht.

*****************************************************************************
Ueber die B-Zeilen muessen wir auch Boxen eintragen die sich in unserer
eigenen H-Route befinden. Ein Beispiel: DBO284, AL1BOX und GF1BOX befinden
sich im gleichen Landkreis und haben alle die H-Route .#GF.NDS.DEU.EU.
AL1BOX hat mit GF1BOX S&F. So muss ich bei mir ins Forwardfile fuer AL1BOX
auch B GF1BOX eintragen. Mit den B Zeilen wird der regionale Forward
konfiguriert!
*****************************************************************************

Um Mails nicht nur innerhalb unseres Landkreises zu Forwarden sondern in die
ganze Welt, muessen wir den S&F per H-Routen definieren. Dies geschieht mit
den "H" Eintraegen.

H *.EU Bedeutet das alle H-Routen die auf .EU enden
geforwardet werden sollen.
H *.BAY.DEU.EU Bedeutet das alle H-Route die auf .BAY.DEU.EU enden,
geforwardet werden sollen.

Wichtig ist jetzt das man sich klar wird welche H-Routen man zu welchen S&F
Partner schickt. Deswegen kann ich hier jetzt nur simple Beispiele nennen.
Man muss sich mit seinem S&F Partner absprechen wer was wo hin routet.

Mein Beispiel geht davon aus das meine Box 4 S&F Partner hat. Um das ganze
zu verstehen muss man mal in die Landkarte schauen wo sich meine Box
befindet. Ich stehe am Ostrand von Niedersachsen Klein Oesingen (JO52FP) und
meine S&F Partner sind PD2BOX (Hannover), AL1BOX (Wittingen, JO52IR), DBO355
(Uelzen, JO52GX) und DBO217 (Wolfsburg, JO52IK).

Ich habe zwar alle oben genannten Boxen auch als wirkliche S&F Partner, doch
die Routingeinstellungen wie sie unten zu sehen sind entprechen nicht mehr
dem aktuellem Stand.

Mein Routingkonzept in diesem Fall geht jetzt davon aus, das ich ueber die
AL1BOX alles schicke was an die Oestlichen Bundeslaender gehen soll. Zur
DBX355 geht alles fuer die Noerdlichen Bundeslaender. Und an die PD2BOX geht
der Rest von Deutschland, und der Welt ! DBO217 ist ne Endbox ohne weiteren
Forward Anschluss. Dementsprechen ist das Routingfile fuer die DBO217 sehr
einfach:

#
B DBO217
F DBO217
#
H *.#WOB.NDS.DEU.EU
#
# Bulletin mit diesen Verteilern senden
#
G WW
G EU
G DL
G DEU
G NORD
G NDS
#

Die H-Route waere in diesem Falle nicht wichtig, weil es ja keine weiteren
S&F Moeglichkeiten von der DBO217 gibt. Schaden tut sie aber auch nicht. Ein
G THEBOX habe ich jetzt nicht eingetragen, da DBO217 Endbox ist. Was soll
sie also mit M-Mails. Sie kann sie ja doch nicht weiter leiten.

Hier der Routing Teil des S&F Files fuer AL1BOX:
#
B AL1BOX
F AL1BOX
#
# Boxen an die AL1BOX Forwarden kann
#
B GF1BOX
#
# Oestliche Bundeslaender Routen
#
H *.BRB.DEU.EU
H *.MVP.DEU.EU
H *.BLN.DEU.EU
H *.SAA.DEU.EU
H *.SAX.DEU.EU
H *.THR.DEU.EU
#
# Bulletins mit diesen Verteilern senden
#
G WW
G EU
G DL
G DEU
G NORD
G NDS
G GF
G THEBOX
G PRIGHH
#

Hiermit sind jetzt alle moeglichen Routen der Oestlichen Bundeslaender
abgedeckt. Dieses S&F File ist noch eine von den einfachen Konfigurationen.
Die GF1BOX ist hier mit in meinem Landkreis und hat zu AL1BOX Forward.
Deswegen habe ich sie mit B GF1BOX eingetragen, da ich hier nicht nach der
H-Route Routen kann, da GF1BOX die gleiche H-Route hat wie meine Box. AL1BOX
bekommt die zusaetzlichen Verteiler GF, THEBOX und PRIGHH. GF weil sie in
meinem Landkreis steht. THEBOX damit die Ostdeutschen Win und Baycom Boxen
auch zu ihren M-Mails kommen und PRIGHH weil der Sysop Mitglied in dieser
ist.

Hier der Routing Teil des S&F Files fuer DBX355:
#
B DBX355
F DBX355
#
# H-Routen der Noerdlichen Bundeslaender
#
H *.SLH.DEU.EU
H *HH.DEU.EU
H *HB.DEU.EU
#
# H-Routen Niedersaechsischer Landkreise
#
H *LG.NDS.DEU.EU
H *UE.NDS.DEU.EU
H *LD.NDS.DEU.EU
#
# Bulletins mit diesen Verteilern senden
#
G WW
G EU
G EURO
G DEU
G DL
G NDS
G NORD
G THEBOX
G PRIGHH
#

Auch dieses ist noch relativ einfach. Ich habe aber schon begonnen bis auf
Landkreis ebene zu Routen. So sind neben alle Noerdlichen Bundeslaender auch
alle Boxen in den Landkreisen Lueneburg, Uelzen und Luechow-Dannenberg
abgedeckt. Bei den Landkreis Eintraegen, kann man erkennen das ich das *
direkt an den Landkreiskenner gesetzt habe. Somit habe ich das Problem mit
der # in der H-Route umgangen. Mit *LG.NDS.DEU.EU werden Boxen angesprochen
die .#LG.NDS.DEU.EU oder .LG.NDS.DEU.EU haben. DBX355 ist eine WinBOX und
benoetigt die M-Mails (G THEBOX). PRIGHH ist fuer den Verein (G PRIGHH).

Jetzt kommt das Routing zur PD2BOX. Hier mache ich dann auch Gebrauch von
der Moeglichkeit H-Routen auszuschliessen.

Hier der Routing Teil des S&F Files fuer PD2BOX:
#
B PD2BOX
F PD2BOX
#
# H-Routen der Kontinente Europa, Sued- und Nordamerika, Afrika, Asien und
# Australien !
#
H *.EU
H *.SA
H *.NA
H *.AF
H *.AS
H *.AU
H *.OC
#
# H-Routen die nicht geforwardet werden sollen !
#
# Bundeslaender
#
! H *.THR.DEU.EU
! H *.BRB.DEU.EU
! H *.MVP.DEU.EU
! H *.BLN.DEU.EU
! H *.SAA.DEU.EU
! H *.SAX.DEU.EU
! H *.SLH.DEU.EU
! H *HH.DEU.EU
! H *HB.DEU.EU
#
# Landkreise Niedersachsens
#
! H *.#WOB.NDS.DEU.EU
! H *LG.NDS.DEU.EU
! H *UE.NDS.DEU.EU
! H *LD.NDS.DEU.EU
! H *GF.NDS.DEU.EU
#
# Bulletins mit diesen Verteilern senden
#
G WW
G EU
G DL
G DEU
G NORD
G NDS
G THEBOX
#

Hier habe ich jetzt die H-Routen ausgeschlossen, die ich schon zu anderen
Boxen route, inklusiver meiner eingenen. Der Grund ist der, das ich im
oberen Teil ja gesagt habe, alles was auf *.EU endet zur PD2BOX routen.

Zur Erklaerung: Es muss verhindert werden, das eine P-Mail an zwei oder
mehreren Boxen gleichzeitig verschickt wird. FBB sortiert sie zwar bei jeder
Box ins Forward ein, loescht sie aber wieder sobald sie an eine der Boxen
erfolgreich weitergeleitet worden ist. Das kann unter umstaenden die falsche
Box sein, und die meldet dann ein "Undelivered Mail". Denn eine P-Mail kann
nie zurueck geroutet werden ! Das liegt daran, das die Mail eine MID Nummer
hat die sie klar identifiziert. Eine Box wo so eine Mail durchgelaufen ist
merkt sich diese Nummer. Bekommt diese Box im S&F wieder diese Mail zum
Forward angeboten, lehnt sie diese ab weil sie die schon mal hatte.

Durch das negierte Eintragen der Routen, die ich schon in den anderen S&F
Files drinne habe, wird das doppelte Routen verhindert. Wichtig ist wenn man
irgentwo *..DEU.EU , *.DEU.EU oder *.EU eintraegt, das man
auch seine eigene H-Route austraegt. Sonst wuerde die eigene Box, Mails die
fuer ihren Einzugsbereich sind wieder wegschicken !

Ich hoffe das dieses Beispiele und die Erklaerungen ausreichend sind.

3.3 S&F Konfiguration bei WinBOX und DP-BOX
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Im grunde ist es bei WinBox und DP-Box genau das gleiche wie bei FBB. Nur
die Dateien und die Eintragungsweise sind anders. Alle Erklaerungen zum
Routing bitte dem FBB Teil entnehmen, weil ich hier jetzt nicht mehr so
genau drauf eingehen werde. Ich rate jedem WinBox Sysop auch die Doku zu
lesen, da sie in Deutsch ist und dem Programm beiliegt. Den DP-Box Leuten
sei ebenfalls ihre Doku ans Herz gelegt, auch wenn diese Englisch ist.

*****************************************************************************
Ich weise nochmal darauf hin das ich hier nur erklaeren moechte wie das
Routing bei WinBOX/DP-Box eingestellt wird. Die Teile die auch die
Forwardzeiten und den Connectaufbau zur Zielbox betreffen, werden hier nicht
erklaert. Das ist bitte der jeweiligen Doku zu entnehmen !
*****************************************************************************

3.3.1 Die .SF Files
~~~~~~~~~~~~~~~~~~~
Mit diesen Files wird der Forward zu den Partnerboxen konfiguriert. Die
Dateien werden nach den Boxcalls benannt z.B. AL1BOX.SF. Es gibt fuer das
S&F File nur wenige Konfigurationsbefehle die da lauten:

FOR
NOT
RUBRIK
NOTFROM
NOTRUBRIK

Mit FOR wird alles das eingetragen was zur besagten Box geforwardet werden
soll. Hinter FOR koennen Calls, sowie die Verteiler als auch die Routen in
hierachischer Notation (H-Routen) angegeben werden.

NOT schliesst Calls oder H-Routen von Forward aus. Vergleichbar mit ! B oder
! H bei FBB.

Mit RUBRIK kann man Rubriken eintragen die man zur Partner Box Forwarden
moechte. Diese Funktion sollte nur angewannt werden wenn man S&F mit einem
User hat (User S&F). Denn hierbei werden die Verteiler nicht beachtet. Alles
was in die definierten Rubriken der Box reinkommt, wird auch weiter
geforwardet.

NOTFROM ermoeglicht es dem Sysop, Mails die von der angegbenen BBS
gekommen sind nicht an den anderen S&F Partner weiter zu leiten. Das macht
Sinn wenn der Forwardpartner auch mit dem in NOTFROM eingetragenen Call S&F
hat. WinBox (DP-Box) bietet dann solche Mails im Funkforward garnicht erst
an.

Mit NOTRUBRIK kann man Rubriken angeben deren Mails nicht zum S&F Partner
geschickt werden sollen.

Bei allen Angaben koennen die Platzhalter * und ? mit eingetragen werden.
Deren bedeutung ist genauso wie beim FBB S&F File. Bitte dort nachlesen.
Kommentare koennen auch eingetragen werden hinter einem # das am Anfang
einer Zeile steht.

Um es Transparent zu machen habe ich die S&F Files wie ich sie oben bei FBB
verwendet habe einfach ins WinBOX/DP-Box Format gebracht.
Hier die DBO217:

# P-Mails
#
FOR DBO217
FOR *.#WOB.NDS.DEU.EU
#
# Verteiler von Bulletins
#
FOR WW EU DL DEU NORD NDS
#

Bei WinBOX/DP-Box koennen mehrere Definitionen hintereinander geschrieben
werden. Ein Leerzeichen als Trenner reicht aus.

AL1BOX:

# P-Mails
#
FOR AL1BOX GF1BOX
#
# H-Routen der oestlichen Bundeslaender
#
FOR *.BRB.DEU.EU *.MVP.DEU.EU *.BLN.DEU.EU *.SAA.DEU.EU *.SAX.DEU.EU
FOR *.THR.DEU.EU
#
# Verteiler von Bulletins
#
FOR WW EU EURO DL DEU NORD NDS GF THEBOX PRIGHH
#

DBX355:

# P-Mails
#
FOR DBX355
#
# H-Routen der Noerdlichen Bundeslaender
#
FOR *.SLH.DEU.EU *HH.DEU.EU *HB.DEU.EU
#
# H-Routen Niedersaechsicher Landkreise
#
FOR *LG.NDS.DEU.EU *UE.NDS.DEU.EU *LD.NDS.DEU.EU
#
# Verteiler der Bulletins
#
FOR WW EU EURO DEU DL NDS NORD THEBOX PRIGHH
#

PD2BOX:

# P-Mails
#
FOR PD2BOX
#
# H-Routen der Kontinente Europa, Sued- und Nordamerika, Afrika, Asien und
# Australien !
#
FOR *.EU *.SA *.NA *.AF *.AS *.AU *.OC
#
# H-Routen die nicht geforwardet werden sollen !
#
NOT *.BRB.DEU.EU *.MVP.DEU.EU *.BLN.DEU.EU *.SAA.DEU.EU *.SAX.DEU.EU
NOT *.SLH.DEU.EU *HH.DEU.EU *HB.DEU.EU *.#WOB.NDS.DEU.EU *LG.NDS.DEU.EU
NOT *UE.NDS.DEU.EU *LD.NDS.DEU.EU *GF.NDS.DEU.EU *.THR.DEU.EU
#
# Verteiler von Bulletins
#
FOR WW EU EURO DL DEU NORD NDS THEBOX
#

Hier habe ich mit NOT die Routen ausgetragen die in den vorrangegangenen
Forwardfiles mit FOR eingetragen habe.

Damit ist das Setup, was den Forward von Mails betrifft, abgeschlossen. Mit
meinen Ausfuehrungen sollte es jedem Sysop moeglich sein seine Box ent-
sprechend einzurichten.

3.4. S&F Konfiguration bei Baycombox
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dieses Boxsystem habe ich selber nicht im Betrieb gehabt. Ich versuche
anhand der Deutschen Dokumentation hier das Konfigurieren des S&F mit
meinen eigenen Worten zu beschreiben. Teilweise habe ich auch einfach
Textauszuege aus der BCM Doku hier uebernommen. Falls ein Baybox Sysop
hier einen Fehler entdeckt, bitte ich ihn mir das mitzuteilen.

3.4.1 Die S&F Datei FWD.BCM
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Die FWD.BCM ist die zentrale Forwarddatei der Baycombox.
In der Datei FWD.BCM wird fuer jede Nachbarbox festgelegt:

* Der Name der Nachbarbox (Rufzeichen ohne SSID)
* Die Zeiten, zu denen Forwardverbindungen aktiv aufgebaut werden
* Informationen zum Verbindungsaufbau zur Nachbarbox (Connect-Weg)
* Uebertragungsoptionen (Maximale Groesse einer Mail, etc.)
* Welche Mails zur Nachbarbox geschickt werden sollen

3.4.2 Einrichten des S&F
~~~~~~~~~~~~~~~~~~~~~~~~

Wie oben schon beim FBB und Winbox Teil, beschreibe ich hier nur wie die
Eintraege ausehen muessen, damit das Routing funktioniert. Bei allen anderen
Eintraegen, bitte die sehr gute Baycom Box Doku lesen.

Baycombox hat in meinen Augen einen entscheidenen Nachteil. Ich kann dort
nicht wie bei FBB und WinBox Routen eintragen, die nicht geforwardet werden
sollen. Das bedeutet, das ich wesentlich mehr Schreibarbeit habe.

In der gesamten Forward-Datei FWD.BCM muessen Eintraege existieren fuer:

* alle Kontinente, ausser dem eigenen Kontinent (also ausser z.B. .EU).
* alle Staaten im eigenen Kontinent, ausser dem eigenen Staat (also alle
europaeischen Staaten ausser z.B. .DEU).
* alle Bundeslaender im eigenen Staat, ausser dem eigenen Bundesland (also
alle Bundesllaender ausser z.B. .NDS).
* alle Regionen im eigenen Bundesland, ausser der eigenen Region (also alle
regionen, ausser z.M. .#GF)
* alle Mailboxen in der eigenen Region, ausser der eigenen Mailbox (also
z.B. alle Mailboxen in Bayern ausser der eigenen).

Diese Eintraege sind auf die Forward-Partner aufzuteilen. Es koennen gleiche
Eintraege auch fuer mehr als eine Box gemacht werden. Die Mail wird dann an
die Box geschickt, die als erstes erreicht wird. Jedoch koennen solche
Doppelbelegungen zu Problemem fuehren. Deswegen rate ich, keine gleichen
Eintraege bei den Boxen vorzunehmen

Hier das File FWD.BCM wie es bei meiner BaycomBox ausehen wuerde:

;---------------------------------------------------------------
; ANFANG
;---------------------------------------------------------------
; Forward-Datei von DBO284.#GF.NDS.DEU.EU
; 0 1 2
; 012345678901234567890123
;---------------------------------------------------------------
DBO217 AAAAAAAAAAA............. DBO217 DNX284
; Landkreise
.#WOB
; Verteiler (ohne Punkt davor)
WW EU DL DEU NDS NORD
; White Page Infos fuer ERASE und MYBBS
$WP
;---------------------------------------------------------------
AL1BOX AAAAAAAAAAA............. AL1BOX DNX284
; Boxen via AL1BOX
GF1BOX
; Ostdeutsche Bundeslaender
.MVP .BLN .SAA .BRB .SAX .THR
; Verteiler (ohne Punkt davor)
WW EU DL DEU NDS NORD GF THEBOX PRIGHH
; White Page Infos fuer ERASE und MYBBS
$WP
;---------------------------------------------------------------
DBX355 AAAAAAAAAAA............. DBX355 DNX284
; Landkreise
.#UE .#LG .#LD
; Norddeutsche Bundeslaender
.#HH .HH .SLH .#HB .HB
; Verteiler (ohne Punkt davor)
WW EU DL DEU NDS NORD THEBOX PRIGHH
; Infos fuer ERASE und MYBBS
$EM
;---------------------------------------------------------------
PD2BOX AAAAAAAAAAA............. PD2BOX DNX284
; Landkreise
.#AUR .#BRA .#BS .#CE .#CLP .#CUX .#DEL .#DH
.#EL .#EMD .#FRI .#GOE .#GS .#H .#HE .#HI .#HM
.#HOL .#LER .#NI .#NOH .#NOM .#OHA .#OHZ .#OL
.#OS .#PE .#ROW .#SFA .#SHG .#STD .#SZ .#VEC
.#VER .#WF .#WHV .#WL .#WST .#WTM
; Bundeslaender
.BAY .HES .RPL .NRW .BW .SAR
; Europaeische Laender
.AUT .BEL .BGR .BIH .CHE .CZE .DNK .ESP .EST .FIN .FRA .GBR .GIB
.GRC .HRV .HUN .IRL .ITA .LTU .LUX .LVA .MKD .MLT .NLD .NOR .POL
.PRT .ROM .RUS .SVK .SVN .SWE .TUR .UKR .YUG
; Kontinente
.SA .NA .AF .AS .AU .OC
; Verteiler (ohne Punkt davor)
WW EU DL DEU NDS NORD THEBOX
; White Page Infos fuer ERASE und MYBBS
$WP
;---------------------------------------------------------------
; ENDE
;---------------------------------------------------------------

Da steht nun viel Text, den ich ein wenig erklaeren moechte. Beginnen wir
mit DBO217. Die erste Zeile enthaelt das Boxcall zu der geforwardet werden
soll. Die Zeichenkennte mit A und Punkten legt die Forwardzeiten fest.
Dahinter kommt der Connect Pfad zur der Box wenn geforwardet werden soll.
Genauere Angaben darueber, bitte der BCM Doku zu entnehmen. Dann erfolgt die
Angabe der Regionalkenner. DBO217 ist fuer mich die Zielbox fuer die Region
.#WOB.NDS.DEU.EU. Also trage ich auch .#WOB bei ihr ein.
Bei der BCM erfolgt die Auswertung der H-Routen von Links nach Rechts. Nicht
wie bei den anderen Boxsystem von Rechts nach Links. Danach definiere
ich die Verteiler (ohne Punkt vorweg) die zu dieser Box geforwardet werden
sollen. Zum Schluss die Angabe in welchem Format die MyBBS Daten zur DBO217
gelangen sollen. $WP steht fuer White Pages nach FBB, oder wenn der
Forwardpartner auch eine BCM oder DP-Box ist, im W-PROT Format. Ob nun WP
oder W-PROT gesendet wird erkennt die BCM am W in der SID (Station
Identifier) der Mailbox.

Fuer DBO217 war wie bei FBB und WinBox relativ wenig einzutragen. Bei AL1BOX
ist jetzt ein Boxcall eigetragen, zu der diese Box direkten Forward hat. Es
gibt in diesem Fall fuer AL1BOX keine Regionalverteiler, weil AL1BOX in
meiner Region steht und ebenfalls wie meine Box die H-Route .#GF.NDS.DEU.EU
hat. Da GF1BOX zu AL1BOX S&F hat und auch die selbe H-Route besitzt muss ich
das Boxcall angeben. Desweiteren kann die AL1BOX Mails an die Ostdeutschen
Bundeslaender forwarden. Hier trage ich wiederum nur die Laenderkenner ein
und nicht wie bei FBB und WinBox die gesammte H-Route. Danach wieder die
Verteiler und die Form wie die Mybbs Daten gesendet werden sollen.

Zu DBX355 kann ich die Kenner der Landkreise Luechow-Dannenberg, Lueneburg
und Uelzen Forwarden. Zudem forwardet diese Box in Richtung SLH, HH und HB.
Da DBX355 eine WinBox ist, bekommt sie die MyBBS Daten als M-Mails. Dafuer
ist der Eintrag $EM zustaendig.

Bei PD2BOX muss ich nun sehr viel eintragen. Ich muss bei diesem S&F Partner
alle uebrigen Kenner definieren, die nicht bei einer meiner anderen S&F
Partner untergekommen sind. Da ich bei BCM keine pauschalen Eintraege wie
bei FBB und WinBox vornehmen kann (alles was auf *.EU endet dorthin
forwarden), und auch keine Routen ausschliessen kann (!H *.GF.NDS.DEU.EU bei
FBB oder NOT *.GF.NDS.DEU.EU bei WinBox). Das bedeutet jetzt im einzelnen,
das ich die Kenner der uebrigen Landkreise von Niedersachsen, die uebrigen
Kenner der Bundeslaender Deutschlands, sowie die Kenner aller Europaeischen
Laender und alle Kontinenten Kenner dort eintragen muss. Wie das dann
aussieht kann man oben sehen. Zum Schluss wieder das Format der MyBBS
Informationen.

Jetzt ist die BCM fuer das Forwarden von Persoenlichen und Bulletin Mails
gewappnet.

4. Autorouter
=============

Der Autorouter ist ein heikles Themas im PR-Bereich. Waehrend sie fuer AX25
Verbindungen schon sehr ausgereift sind (Flexnet und NetRom) haben diese
beim Mailversand immer noch so ihre Probleme. Das liegt daran, das die
bislang verwendeten Autorouter unterschiedlich arbeiten. Es kommt haeufig
zum Fehlrouting die sich dann als Ping-Pong Mails aeussern. Ping-Pong Mails
sind Mails die im Kreis laufen zwischen zwei oder mehreren Forwardboxen. Von
den in Deutschland gebraeuchlichen Box-Systemen hat nur FBB keinen
eingebauten Autorouter. Doch gibt es fuer FBB Zusatzprogramme die das
erledigen koennen.

Meine Meinung zu diesem Thema ist, das Autorouter grundsaetzlich nicht
verwendet werden sollten. Wenn eine Box gut konfiguriert ist, was nach den
obigen Beispielen ja eigentlich auch kein Problem mehr darstellen sollte,
kann man getrost auf Autorouter verzichten. Ein Sysop kann eine Route
schneller aendern als die Autorouter. Zum Beispiel wenn der Nachbar Sysop
mitteilt das ueber ihn keine P-Mails mehr geroutet werden koennen fuer das
Bundesland Niedersachsen. Bis ein Autorouter das mitbekommt, schickt er noch
viele Mails in die falsche Richtung. Fuer den Sysop sind es nur minimale
Aenderungen in den S&F Files. Diese Problem der "Dead Ends" also der toten
Enden tritt auch auf, wenn z.B. einige Boxen sich mit Forward von Webseiten
versorgen. Durch das Verarbeiten solcher Forwardfiles werden die Autorouter
getaeuscht. Denn sie wissen ja nicht, das solche Routen nur ne Einbahnstrasse
sind. Denn der Sysop der sich die Mails von so einer Webseite holt, schickt
in den wenigsten Faellen seine Mails ebenfalls dorthin zurueck.

Autorouter koennen aber auch Vorteile haben. Vergisst ein Sysop mal eine Route
in den S&F Files zu definieren, springt der Autorouter ein und leitet die
Mail an den S&F Partner weiter, von dem er glaubt das er der guenstigste Weg
ist. Ein Autorouter sollte,wenn man ihn denn benutzt,nur eine unterstuetzende
Funktion haben. Er sollte aber nicht fuer das gesammte Routing benutzt werden,
weil es dann zu Problemen kommen kann. Nicht nur im Routing kommt es zu
Problemen auch die Sysops untereinander haben sich schon wegen Pro und Kontra
Autorouter die Koepfe eingeschlagen.

4.1 Autorouting Programme bei FBB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mir sind 2 Programme bekannt die der FBB einen Autorouter bescheren. Das
eine ist der FWDMAKER von DR5EIN, und der zweite ist das Programm FWDROUTE
vom Pseudo-Data-Team. Ich selber habe mal das Programm FWDMAKER v1.2
eingesetzt.

4.1.1 Forwardmaker
~~~~~~~~~~~~~~~~~~
Zur Funktionsweise vom FWDMAKER habe ich mal den Abschnitt aus der Doku hier
eingefuegt der diese beschreibt:

----------------------------------------------------------------------------
Wie arbeitet FWDMAKER?

FWDMAKER aktualisiert bei jedem Lauf die Forwarddateien. Es scannt alle
seit dem letzten Lauf eingegangenen Mails und fuegt eine neue Route in die
entsprechende Forwarddatei ein. Die Mails werden auf die Routingzeilen (R
hin gescannt.

Die jeweils erste und letzte R:-Zeile einer Mail wird ausgewertet. Die
erste Zeile enthaelt die unmittelbare Nachbarbox von der die Mail kam und
die letzte Zeile enthaelt die Route wo die Mail ihren Ursprung hatte.

Jetzt wird die Route aus der letzten Zeile in den Forward der in der ersten
Zeile ermittelten Box eingetragen. Der Eintrag erfolgt nur dann wenn das
Routing kuerzer ist als in einem der andern Forwarddateien. Gleichzeitig
wird der Routingeintrag in einer anderen Forwarddatei entfernt.
Dies setzt natuerlich voraus, das auch zu den Boxen geforwardet wird von
denen die Mails kommen.

FWDMAKER merkt sich die Anzahl Zwischenstationen eines Routings und traegt
dies auch in den Forwarddateien ein.

So werden Mails einer bestimmten Route automatisch an die Box versand von
der diese Route kam.
----------------------------------------------------------------------------

Die Doku weisst daraufhin, das man in den Forwardfiles keine anderen H-Routen
Eintraege haben sollte. Das ist schlecht, weil man so den FWDMAKER nicht als
Unterstuetzung verwenden kann. Entweder Manuell, oder FWDMAKER. Dieses war
fuer mich damals nicht akzeptabel und habe den FWD-Maker nicht mehr benutzt.
Damit der FWDMAKER auch richtig routen kann, muss er natuerlich erstmal
mit Daten aus dem Forward gefuettert werden. Eine junge FBB Box mit bislang
wenig Mail Durchlauf hat also weniger Routeneintraege als eine FBB Box mit
FWDMAKER die schon wesentlich laenger am S&F teilnimmt. Kommt nun eine P-Mail
in die Box fuer eine Box die noch nicht erfasst worden ist, so bleibt die
Mail liegen und wird als "undelivered mail" zum Absender zureck geschickt.
Manuelle H-Routen eintrage koennten dieses Dilemma umgehen. Diese sollten
jedoch laut Doku zum FWDMAKER nicht eingetragen werden.
Auch weiss ich nicht ob FWDMAKER Jahr 2000 Kompatibel ist, da er mit Datums
Angaben zu tun hat. Die Eintraege die FWDMAKER in die S&F Files macht, sind
sehr umfangreich und blaehen die Datei sehr auf. Denn es wird jede Box die in
den R-Zeilen gefunden wird in eines der S&F Files eingetragen. Das enspricht
also dem Smart-Host Routing wie ich es oben schon erklaert habe.

4.1.2 Forwardroute
~~~~~~~~~~~~~~~~~~
Das Programm FWDROUTE wird nicht wie FWDMAKER taeglich ausgefuehrt. Es soll
eine Hilfe fuer den Sysop darstellen um das Routing korrekt einzustellen. Es
durchsucht auch alle Mails der Box und scannt deren R-Zeilen. Es sucht
daraus die kuerzesten Routen und schreibt es sie in ein File das man dann in
seine S&F Files einbinden kann. Auch hier werden alle gefundenen Boxen auf
die eigenen S&F Partner verteilt (Smart-Host Routing). Zusaetzlich gibt das
Programm aus, welche Verteiler man von dieser Box bekommen hat und schlaegt
vor diese auch so in die eigenen S&F Files einzutragen.

Die Arbeitsweise entspricht also weitgehend dem, wie es FWDMAKER auch tut.
Die oben beschriebenen Probleme treffen also auch auf diese Software zu.
Man kann das Programm waerend des taeglichen laufens des Housekeeping, oder
von der CRON.SYS aus automatisch starten und via einer *.BAT mit Copy Befehlen
seine S&F Files immer Updaten. Ich persoenlich schlage vor, das Programm
wirklich nur zur Unterstuetzung zu benutzen, und die S&F Files per Hand zu
Pflegen.

4.2 WinBox (DP-Box) Autorouter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Bei WinBox (DP-Box) ist der Autorouter fest integriert. Auch laesst sich der
Autorouter nicht komplett abschalten. Die Autorouter von DP- und WinBox
arbeiten nach dem gleichen Prinzip. Die Autorouter berechnen die Laufzeit
der Mail von der Ursprungsbox bis in unsere. Vorraussetzung ist natuerlich
das die Zeitangaben in den R-Zeilen stimmen. Uebrigens sollten die Zeiten
in den R-Zeilen in UTC angegeben sein. Damit das stimmt gibts bei jeder Box
einen Parameter der den Offset von der Localen zur UTC Zeit definiert. Mit
diesen Daten kann der Autorouter recht zuverlaessig seine Routen berechnen.
In einem Netz nur aus Win- und DP-Boxen soll es moeglich sein alleine nur mit
dem Autorouter auszukommen. Da wir aber verschiedene Box Systeme haben, ist
dieses nicht moeglich. Jedoch meine ich das es meinen Beobachtungen zur folge,
trotzdem recht zuverlaessig klappt.

Die Strategien wie der Autorouter in den beiden Boxsystemen integriert ist,
sind unterschiedlich. Bei WinBox ist es so, das erst die S&F Files nach
Routen abgesucht werden, wenn in der Box eine P-Mail liegt die weiter
geforwardet soll. Findet WinBox dort eine Route in den S&F Files, wird die
Mail entsprechend den Eintraegen weiter geleitet. Ist dort nichts zu finden,
durchsucht der Autorouter seine Datenbank und schickt die Mail auf den besten
errechneten Weg. Je nachdem wie gut der Sysop seine S&F Files pflegt,
arbeitet der Autorouter also mehr oder weniger. Traegt man im S&F File keine
Routen ein, so uebernimmt der Autorouter das Routing komplett.

Bei DP-Box kann man das auswaehlen, ob der Autorouter komplett das Routing
uebernehmen soll, oder nach der Methode wie es WinBox macht. Interessant ist
hierbei das DP-Box, wenn der Autorouter immer eingeschaltet ist, auch in die
S&F Files schaut, wenn er selber keine Route zum Ziel finden kann. Bei DP-Box
kann der Sysop auch bestimmen ob alle Mails oder nur P-Mails zur Berechnung
des Autorouting herrangezogen werden soll. Der Vorteil dieser Methode ist das
man davon ausgehen kann, das Persoenliche Mails nicht von irgentwelchen
Webpages herruntergeladen werden und somit auch ein sicherer Rueckweg fuer
P-Mails besteht. Da jedoch das P-Mail aufkommen im CB-PR Netz zu gering ist,
sollte diese Funktion nicht eingeschaltet werden.

Bei den Autoroutern hat der Progrmmierer der DP-Box jetzt was neues ange-
fangen, das Active Routing. Dieses System arbeitet mit dem Austausch von
Routinginformationen die auf echte Laufzeit- und Datendurchsatz Messungen
basieren. Das heisst es werden wie bei INP3 im Netrom bzw. beim Flexnetrouting
Laufzeiten gemessen. Diese Messungen werden in einer Routingtabelle abgelegt
und den angeschlossenen Boxen mitgeteilt. Ansich also genau wie Netrom. Dieses
System funktioniert sehr gut. Jedoch ist es noch nicht in andere Boxen ein-
gebaut, so das nur DP-Box 6.00.00 bislang diese Art des Autoroutings unter-
stuezt. Dieser Autorouter funktioniert auch nur, wenn der Forward direkt
abgewickelt wird. Bei reinen Import-Export Boxen funktioniert dieser Router
nicht.

4.3 Baycom Box Autorouter
~~~~~~~~~~~~~~~~~~~~~~~~~

Auch die aktuellen Baycomboxen haben einen Autorouter, wenn er denn einkompil-
liert wurde. Er kann auch komplett ausgeschaltet werden. Er arbeitet nach
einem aehnlichem Prinzip wie der WinBox Autorouter. Nur das der BCM Autorouter
auch die Hops (Anzahl Boxen die eine Mail passiert hat) auswertet und in seine
Berechnungen einfliessen laesst. Waerend bei WinBox jede eingehende Mail
analysiert wird und zur Berechnung der Routen herangezogen wird, so ist es
bei diesem Autorouter moeglich, das Alter einer Mail zu bestimmen, die fuer
die Berechnung der Routingpfade benutzt werden soll. Damit wird verhindert,
das uralte Mails das Autorouting negativ beeinflussen koennen. Der Autorouter
der BCM ist wie bei WinBox eine Unterstuetzung. Routing Eintrage in der
FWD.BCM haben vorrang. Traegt der Sysop dort nix ein, so wird das komplette
Routing vom Autorouter uebernommen.

5. Nachwort
===========

Hiermit enden meine Ausfuehrungen. Ich hoffe das die Informationen vielen
Sysops helfen moege ihre Box, vor allem das Routing, in den Griff zu bekommen.
Danken moechte ich den Programmieren der Boxen die sich die Muehe gemacht
haben eine sehr umfangreiche Software zu schreiben. Vor allem die Program-
mierer die es erlauben ihre Software im CB-Funk kostenlos zu benutzen gebuehrt
mein Dank. Die Programmierer der FBB-Tools Forwardmaker und Forwardroute
moechte ich auch nicht unerwaehnt lassen, haben sie doch eine gute Hilfe fuer
die FBB Gemeinde programmiert.

Zu Danken habe ich auch dem Pseudonym "Meikel Katzengreis". Lesern der
Newsgroup "z-netz.alt.telecom.cb-funk" bestimmt bekannt. Dieser hatte mir
in meiner Anfangszeit als Sysop das Routing erklaert.

6. Quellenangaben
=================

Auszuege in diesem Text entstammen teilweise den Dokumentationen von:
DP-Box, WinBox, BaycomBox, FBB, FWDMaker und Forwardroute

73 de Marc-Andre (DMA284)

Sysop der DP-Box DBO284 und des X-Net 1.30 Nodes DNX284 in Kl.Oesingen,JO52FP

Aus meinem Archiv: XNet und NETROM

Sun, 19 Apr 2026 13:36:18 +0200

Moin!

Seit einigen Wochen experimentiere ich wieder mit Packet Radio und leider
muss man sagen, das man das Netz voellig vergessen kann und das trotz AXUDP
Verbindungen zwischen den Nodes.

Faellt denn Niemanden ausser mir auf das NETROM nicht wirklich funktioniert?

Ja, es gibt ein tolle Nodeliste, aber wenn man versucht vor allem entferntere
Nodes zu erreichen dann funktioniert das nicht. Der Grund ist auch voellig
klar. Es liegt daran das immer noch viel zu haeufig die Software XNet
verwendet wird.

XNet ist an sich gar nicht mal schlecht aber es hat einen grossen Makel. Es
mixt die beiden Routing Grundlagen naemlich die des Time Dependent Routing
(TDR) via INP3 und dem Qualitaets basierten Routingshema.

Das Qualitaets basierte Routing Schema ist das urspruengliche Verfahren wie
eine Route zu einem Nachbar NETROM Node berechnet wird. Der Sysop gibt den
einzelnen Ports seines Nodes eine "Qualitaet" fest vor. Jede Software die
NETROM kann muss also einem Port eine Qualitaet zuweisen. In der
Vergangenheit war das oft der Wert 192 fuer einen 1200 Baud Funkport im CB.

Ein NETROM Node schickt in regelmaessigen Abstaenden ein NODES Broadcast als
AX.25 UI Frame an das Call NODES aus. Damit identifiziert er sich bei anderen
Nodes als NETROM Node und gleichzeitig schickt er damit eine Liste mit NETROM
Nodes mit die er selber kennt. Ein Node Broadcast sieht so aus:

10:09:38T DNO284>NODES Port=1 NODES broadcast from WITBPQ
WITPBXBO284 via DNO284 qlty=192
WITCNVNO284-4 via DNO284 qlty=192

Empfaengt ein NETROM Node so einen Broadcast, traegt er den sendenden Node bei
sich in der Nodeliste mit der Port Qualitaet 192 ein. Weitere Nodes in der
Liste ebenfalls, aber reduziert in der Qualitaet basierend auf der Port
Qualitaet und der Qualitaet die der sendene Node diese Nodes selber bei sich
eingetragen hat.

Zur veranschaulichung:

Wir haben 3 Nodes. NODE01 <> NODE02 <> NODE03.

Alle Nodes haben eine Port Qualitaet von 192 eingetragen. NODE01 und NODE03
sehen sich nicht direkt.

NODE02 sendet an NODE03 das er NODE01 mit Qualitaet 192 empfaengt. NODE03
berechnet nun die Qualitaet von NODE01 so:
192/256 * 192/256 = 0,75 * 0,75 = 0,5625 * 256 = 144

Wuerde es jetzt noch einen NODE04 geben der NODE03 hoert wuerde NODE01 bei
ihm mit Qualitaet 108 eingetragen werden.

144/256 * 192/256 = 0,5625 * 0,75 = 0,421875 * 256 = 108

Und so geht das immer weiter wenn noch mehr Nodes in diesem Netz hinzukommen.

Die Qualitaet kann den Wert 0-255 annehmen. Und wie man in den Berechnungen
sieht kommt bei 192/256 der Wert 0,75 bei raus. Damit wollte man abbilden wie
zuverlaessig ein Funkverbindung zwischen zwei Nodes fuer gewoehnlich ist. Man
koennte auch schreiben 75% der AX.25 Pakete zwischen zwei via Funk
verbundenen Nodes kommen an. Dieser Wert kann erreicht werden, wenn zwei
Nodes die Frequenz ganz fuer sich alleine haben, aber nicht wenn auf diesem
Kanal noch weitere Stationen sind. Tummeln sich jetzt mehrere Nodes und ggf.
noch User auf einer Frequenz wie es bei CB-PR ueblich war, war 192 auch schon
immer zu hoch gesetzt. Wenn man Glueck hatte kamen vielleicht gerade mal 50%
der AX.25 Pakete an oder noch weniger. Dementsprechend muesste man die
Qualitaet entsprechend anpassen bei 50% waere 128 ein guten Wert. Die
meisten Nodes haben Port Statistiken gefuehrt, anhand diesen haette man
ermitteln koennen wie gut ein Port performt.

Obiges war jetzt die Beschreibung fuer Funk Links. Im heutigen CB-PR kommen
vor allem AXUDP Links via Internet vor, welche die Nodes miteinander
vernetzen. Das ist im Grunde nicht schlimm da wir, anders als im AFU, keine
exklusiven Frequenzen fuer eine Backbone Vernetzung zwischen Nodes haben.
Haeufig wir hier dann gerne die Port Qualitaet fuer solche AXIP/AXUDP Links
von 255 eingetragen. Das ist aber genauso falsch, weil Internet, welches auch
Paket basiert ist, nicht 100% Fehlerfrei ist. IP Pakete koennen und duerfen
verloren gehen. Nun ist unzweifelhaft das Links ueber Internet stabiler sind,
also kann man hier einen besseren Wert fuer die Qualitaet eintragen.

Die NADA (NorthEast Digital Association), eine in den 80er Jahren in den USA
gegruendete Organisation von Funkamateur Packet Radio Sysops hat fuer ihr
Netz Richtlinien herausgebracht. Dort wurde unter anderem festgelegt das
fuer AXIP/AXUDP Links die Port Qualitaet 203 betragen soll. Ich denke das ist
ein gute Wert. Er liegt hoeher als bei Funk Links und laesst die Moeglichkeit
zu das Internet Routen besser dastehen als reine Funk Links. Fuer lokale
Dienste wie z.B. die eigene Box oder der Convers kann der Wert 228 genutzt
werden. Dann resultiert daraus im Nodes Broadcast bei Nachbar Node eine
Qualitaet von 203 und ist somit genauso hoch wie der eigene Node.

Das oben genannte Routing mittels Qualitaeten hat schon in den Anfangstagen
so seine Probleme gehabt. Wie sich ja aus der von mir oben hoffentlich
einigermassen beschrieben kurzen Beschreibung ergibt, gibt die Qualitaet
ueberhaupt keinen Anhaltspunkt wie gut eine Node zu Node Verbindung
tatsaechlich ist. Sie ist ja nur angenommen und von den Sysops parametrisiert.
Jeder weiss, wenn sich Bedingungen aendern, muesste sich auch die Qualitaet am
besten automatisch mit aendern. Das koennen verschiedene Dinge sein. Zum
Beispiel wenn ein Link oder eine Frequenz stark ausgelastet ist, sinkt der
Datendurchsatz. Ergo muesste die Qualitaet sich verschlechtern. Tut sie aber
nach dem alten NETROM verfahren nicht.

Ein weiterer Grund ist wie Nodes wieder aus der Nodes Tabelle verschwinden.
Das geschieht aus einer reinen Zeit Komponente heraus. Es gibt bei NETROM den
Parameter OBSINIT. Das ist der Startwert des Veraltenszaehlers. Wird ein Node
das erste mal in einem Node Broadcast empfangen bekommt dieser den
Zaehlerwert von OBSINIT. Sendet unser Node ebenfalls einen Node Broadcast
wird dieser Wert um 1 verringert. Ist dieser Wert auf 0, fliegt der Node aus
unserer eigenen Nodes Tabelle raus. Ein Zweiter Parameter ist der Wert
OBSMIN. Dieser gibt an wann ein Node unserer Nodes Tabelle nicht mehr weiter
gemeldet wird. OBSINIT und OBSMIN haengen also davon ab wie oft unser Node
seinen Node Broadcast sendet. Ein guter Wert sind meiner Meinung nach 10
bis 15 Minuten. Ich bin der Meinung wenn man einen Node seit einer Stunde
nicht mehr im Broadcast gelesen hat, sollte er aus der Liste fliegen. Also
setzt man OBSINIT bei 10 Minuten Broadcast Intervall auf 6. Bei 15 Minuten
auf 4. Alle Node in einem Netz sollten bei Node Broadcast Intervall und bei
OBSINIT und OBSMIN die selben Werte haben, ansonsten ist das Netz von vorn
herein zum scheitern verurteilt. Sysops die nicht angepasste Werte dort
stehen haben, sollte vom Netz ausgeschlossen werden.

Weil das alte NETROM Node Austauschverfahren so unzuverlaessig ist, hat man
sich INP3 fuer NETROM ausgedacht. Hier werden mehrere Dinge ueberprueft damit
ein Link und somit der Nachbar Node und dessen erreichbare Nodes in der
eigenen Nodesliste angezeigt wird und auch an andere Nodes weiter geleitet
wird.

* Es muss ein AX25 Link zwischen den Nodes dauerhaft bestehen.

Im alten Netrom Netz wurde mit den oben beschriebenen Nodes Broadcasts auf
sich aufmerksam gemacht. Nun konnte die Situation entstehen das er Broadcast
aussendene Node den empfangenen Node selbst garnicht hoeren kann. Der
empfangene Node traegt den aussendenen Node und die weiteren im Broadcast
enthaltenen Nodes aber in seine Node Tabelle ein und sendet auch die darueber
verbreiteten Nodes weiter aus. Kommt jetzt eine NETROM Paket an beim Broadcast
empfangenden Node an, kann dieses Paket nicht weitergeleitet werden zum zuvor
Broadcast sendenen Node.

Sieht also ein INP3 NETROM Node einen Nachbar Node via Node Broadcast, baut er
einen AX.25 Connect zu diesem auf. Nur wenn das klappt, wird der Node erst in
die Nodes Tabelle bei ihm eingetragen.

* Laufzeitmessung

Zwischen INP3 Netrom Nodes werden Paketlaufzeiten ermittelt. Laufzeiten geben
einen Anhalt wie schnell ein Paket von Sender zum Empfaenger und zurueck
braucht. Das Ganze nennt sich abgeuerzt RTT (RoundTripTime). Da die Bandbreite
eines Links ja vorgeben ist, bedeutet eine kurze laufzeit das hoher Daten
Durchsatz moeglich ist. Ist ein Link ausgelastet oder sogar von Stoerungen
betroffen, werden die Laufzeiten schlechter.

* Hopcount

INP3 weiss wie viele Nodes zwischen den Nodes sind.

* Gesicherte Uebermittlung von Routing Informationen

INP3 sendet zu den Nachbar Nodes keine Nodes Broadcast mehr aus. Sondern die
Informationen werden gesichert in der AX.25 Verbindung zwischen beides Nodes
uebertragen.

* Negative Routing Informationen

INP3 meldet nicht mehr verfuegbare Links und darueber gelernte Nodes sofort als
nicht mehr erreichbar zu seinen anderen Nachbar Nodes weiter. Anders als beim
Routing ueber Qualitaet wo erst ein Node aus der Tabelle fliegt wenn von ihm
nach einer bestimmten Zeit kein Nodes Broadcast mehr empfangen wird.

Was hat nun XNet mit dem ganzen zu tun?

Nun es ist eigentlich einfach. NETROM an sich ist erstmal nur ein Protokoll
was Verbindungen herstellt zwischen entfernten Nodes. Die Routing
Informationen werden aber wie oben beschrieben auf zwei verschiedene Arten
ermittelt. Qualitaet und INP3. Waehrend Routing nach Qualitaetsangaben sich
quasi nur auf die Einschaetzungen der Sysops aufbaut, ermittelt INP3 Fakten
anhand von Laufzeitmessungen und ob ein Link tatsaechlich existiert, also
zwei Nodes auch wirklich eine Verbindung herstellen koennen.

Es ist auch gar kein Problem wenn diese zwei verschiedenen Verfahren in einem
Netz zusammen kommen. Es muss aber sichergestellt sein das jeder Node diese
Verfahren getrennt haelt. Ausser XNet macht das jede NETROM Node Software die
ich kenne.

XNet berechnet aus Laufzeiten Qualitaeten und aus Qualitaeten Laufzeiten. Das
ist ein absolutes NoGo! Aber welche Folgen hat das denn nun?

Schauen wir uns das noch mal an. Qualitaet = Von Sysop festgelegt und wenn
ein Nodes ueber ungesicherte Broadcasts weiter gemeldet wird, verringert sich
von Node zu Node die Qualitaet. Ueber einen auch vom Sysop einzurichtenen
Veraltenszaehler kann ein Node, wenn er nicht mehr in Broadcasts gehoert wird
auch wieder aus einer Nodes Liste verschwinden.

INP3 = Zeitbasiert mittels RTT ermittelte Laufzeiten, gesicherte Uebertragung
von Routing Infos via AX.25 Link und negative Rueckmeldungen. Nodes fliegen
bei AX.25 Abbruch zum Nachbarknoten direkt aus der Nodeliste und werden auch
sofort als nicht mehr erreichbar an andere Nachbar Nodes weitergemeldet.
Somit eine vertrauenswuerdige Routing Umgebung, mit gesicherten Informationen
zum Netzzustand.

Die Folge ist nun, dass ein Node, der nur in der nicht vertrauenswuerdigen
Qualitaets Umgebung existiert und in dieser Umgebung moeglicherweise ausserhalb
unseres Qualitaets Horizonts lag, nun in der vertrauenswuerdigeren INP3
Umgebung auftaucht, wo er den NetRom veraltens Prozess umgehen kann. Die
Information koennte dann mit einer hoeheren "Qualitaet" in das qualitaets
Netrom-Netz zurueckkehren, als wenn sie ueber eine direktere reine Netrom-Route
empfangen worden waere.

Hier ein Beispiel wie das aussieht:

AP1DIG ==>n dnx284 +

routing WITXRONX284 v AP0NOD

LOCAL Inp 3 rx: -.- (unreach) tx: -.-
DAB563-9 Inp 3 rx: 1.48 ( 9 hops) tx: -.-
> AP0NOD Inp 3 rx: 1.21 ( 6 hops) tx: -.-
CB0ESN Inp 3 rx: -.- (unreach) tx: 1.38
CB0GER Inp 3 rx: -.- (unreach) tx: -.-
AX25N0 Inp 3 rx: -.- (unreach) tx: 1.44
CT1NET Q BC Obs 0 RxQual 0
AP1NOD Q BC Obs 6 RxQual 0
NL5POP Q BC Obs 0 RxQual 0
Broadcasted 432s ago with quality 244

AP1DIG ==>
*** route: AP1DIG AP0NOD KS0NOD KS1NOD-2 AP0NOD* AP1DIG

DNX284 ist ein Test Node von mir, den ich jetzt seit mehrern Tagen Offline
genommen habe. Trotzdem ist er in Nodes Listen weiterhin vorhanden und wird
von XNet Nodes wie hier zu sehen mit der Qualitaet von 244 weiter
gebroadcastet und natuerlich somit auch via INP3 mit einer fiktiven RTT
weiter gegeben.

Ein weiterer Grund den ich nicht verschweigen moechte ist das einige Nodes
die z.B. mit BPQ laufen den Parameter AUTOSAVE fuer die Nodes Liste
aktiviert haben. Dieser sollte immer ausgeschaltet werden. Denn damit
werden bei jedem Neustart von BPQ ggf. alte nicht mehr vorhandene Nodes
neu ins Netz eingespielt, obwohl die schon lange weg sind.

Deswegen ist XNet fuer das CB-PR und fuer alle sonstigen Netze die schlechteste
Software die man AX.25 NETROM Netzen antun kann. Im AFU Bereich wo Packet
auch nur noch von wenigen betrieben wird, ist die Software so gut wie
verschwunden. Ich finde man sollte dieses auch im CB-PR so handhaben. Im
Grunde bleiben einem nur drei NETROM Node Programme uebrig wenn man sich
umschaut.

BPQ: Aktive Weiterentwicklung inklusive Source-Code verfuegbar. Fuer Windows,
Linux und auch auf nem RasPi lauffaehig. Aeltere Versionen auch auf DOS.
Zahlreiche Schnittstellen vorhanden. INP3 faehig und rudimentaer sogar schon
IPv6 faehig. Bevorzugt leider altes Qulitätsbasiertes NETROm Routing, kann
jedoch mit dem Parameter PREFERINP3ROUTES=1 dazu gezwungen werden INP3 zu
bevorzugen bei der Routing Entscheidung.

Xrouter: Aktive Weiterentwicklung. Leider closed Source. Nur auf Linux,
Windows und RasPi verfuegbar. Aeltere Versionen auch fuer DOS. INP3 faehig
und bevorzugt von Haus aus INP3, wenn vorhanden.

TNN: Keine aktive Weiterentwicklung. Open Source Quellcode aber nicht fuer
aktuelle Compiler angepasst und Probleme wenn auf 64Bit System compiliert
wird. Angepasste CB Versionen verfuegbar. INP3 faehig und bevorzugt von Haus
aus INP3, wenn vorhanden.

Ich moechte jedem Sysop bitten sich mal die Alternativen anzusehen. Zum einen
erweitert man dadurch seinen Horizont und tut, wenn man sich entschliesst
XNet aufzugeben, auch was Gutes fuer das Netz.

Fuer Sysops die nicht wechseln koennen, weil sie XNet in einem TNC3 oder TNC4
laufen haben. Sollten nur Links zu Nodes aufbauen die keine NODES Broadcast
aussenden. Ebenso sollten sie selber mit dem Befehl "ro bc del nodes" das
Aussenden von Nodes Broadcast abschalten.

Link Partner zu XNet Nodes sollten nur INP3 erlauben. Nodes Broadcast zum
XNet Nodes ebenfalls abschalten und Nodes Broadcast von XNet Nodes
ignorieren oder die Port Qualitaet auf 0 oder 1 setzen.

Falls das alles nix hilft bleibt nur noch, das XNet Nodes von Sysops ohne
XNet vom Netz ausgeschlossen werden.

55 & 73 Marc-Andre DMA284

D1JW aus Uetersen SH

Sun, 19 Apr 2026 11:45:46 +0200

Moin Moin
Ich bin der Jürgen aus Uetersen (Schleswig Holstein)

Ich habe damals CB-Funk gemacht und auch Packet Radio bis ca. ende der 90er.
Jetzt jabe ich wieder ein CB Funkgerät im Auto (Albrecht AE5900) die auch super läuft.
Vor ein paar Tage habe ich dann ein TNC2C geschenkt bekommen ich möchte es mal wieder probieren mit Packet Radio.
Dazu muss ich aber erstmal die Kabel und die Software fertig machen. Mal schaue welche Software ich da nehme damals hatte ich Grafik Packet was mir super gefallen hat aber ja leider unter Win 11 nicht läuft.

MFG Jürgen
Jetzt erstmal weiter umschauen hier :-)

Verbindungen CB und Amateurfunk PR-Netz

Sun, 19 Apr 2026 10:43:43 +0200

Moin!

Mir ist aufgefallen das in der Nodes Liste auch eindeutige Amateurfunk Stationen zu finden sind. Ich habe mindestens eine solche Verbindung identifiziert und möchte darum bitte diese zu kappen. Und das jeder Sysop sich verdammt nochmal um seine Station kümmert und ein Auge drauf hält.

NX284:WITTNG} Connected to AP1NOD
Willkommen im Network-Node-Hannover/Ahlem >>AP1NOD<< AXIP/APRS/Gateway
              >> Apolo Netzwerk System Hannover Stadt <<
N=Nodes R=Routes P=Ports I=Info AP1=AP1BOX AP=AP2BOX AP4=AP4BOX ?=HILFE
r r
APAPRS:AP1NOD} Routes
...
> 3 AE5E-14   192 72 375    0   0% 0 0 08:01 0 192
...
axm 3
APAPRS:AP1NOD} AXIP Mheard for Port 3
...
AE5E-14   216.172.112.208 U 8093   Sun Apr 19 08:19:26 2026
...
c ae5e-14
APAPRS:AP1NOD} Connected to 5ENODE:AE5E-14
Enter 'INFO' for connection information.
BPQ32:AE5E-14} DXC DXA BBS CHAT CONNECT BYE INFO NODES ROUTES PORTS USERS MHEARD
axm 1
5ENODE:AE5E-14} AXIP Mheard for Port 1
...
AP1NOD    84.146.198.4    U 10093 Sun Apr 19 08:24:14 2026 K
AP2NOD    84.146.198.4    U 10093 Sun Apr 19 08:20:28 2026

Ronald Stordahl scheint der Benutzer zu sein. https://en.wikipedia.org/wiki/Ronald_Stordahl

Wobei ich nicht weiß wer zu wem die Verbindung aufgebaut hat. Aber diese einfachen Auto Uplink Funktionen wie sie BPQ mit Autoaddmap, oder auch TNN und XNet haben sind einfach Gift für das Netz.

55 & 73 Marc-Andre

MH Liste 18.04.2026

Sat, 18 Apr 2026 06:20:27 +0200

LK0NRW:LK0NOD} Heard List for Port 1
LK1NOD     00:00:04:08
CT3NOD     00:00:08:46
DCT645-10  00:00:12:18    via CT1NET,CT3NOD*,WIDE2-2
LK1-1      00:00:17:32
DQB906-15  00:00:18:06
STRELA-1   00:00:18:06
DCT645-12  00:05:10:16
STRELA-2   00:05:14:58
DCT645-3   00:05:26:34
DCT645-11  00:05:57:24
DCT645-15  00:07:38:13
DCT645-5   00:07:54:32
DCT645     00:07:55:05
STRELA-7   00:08:41:39
DQB906     00:09:15:35
STRELA-4   00:09:44:31
DCT645-4   00:09:44:31
DQB906-1   02:22:12:49
DME53      02:23:18:23
LK2-4      02:23:19:07
LK2-1      03:00:16:38
LK2NOD     03:07:40:05
LK2-7      03:10:24:23
CT0NOD     04:19:53:28
LK7CB-15   05:23:21:08
CT1NET     06:03:04:36
DATZE-1    06:03:52:40
DATZE-2    06:04:13:31
CT1PI-1    06:21:17:24
CT1PI      06:21:22:16