Region-Konfiguration für Repeater ab Firmware 1.12

Servus,

da die im Internet auffindbare Dokumentation zum Region-Feature (ab Version 1.12 in der Repeater-Firmware) etwas dürftig ist, habe ich Code gelesen und folgende Erkenntnisse daraus gezogen. Wenn ich hier etwas falsch wiedergebe, gerne kommentieren.

Allgemeine Doku zum Konzept gibt es hier:


Versionshistorie:

  • 2026-02-22: Warnhinweise zu blockierten Flood-DMs hinzugefügt, danke an SK-Base für den Hinweis.
  • 2026-02-24: Konkretisierung der Beschreibung der Wildcard *

Was sind Regionen?

Stell dir Regionen als Analogie wie Postleitzahlen-Bereiche vor. Ein Repeater kann entscheiden: „Ich leite nur Pakete aus bestimmten Bereichen weiter“ oder „Ich leite alles weiter“.

Wichtig: Regionen sind aktuell (Februar 2026) freiwillig. Geräte können mit oder ohne Region betrieben werden.

Die zwei wichtigsten Befehle

1. Regionen anzeigen

region list

Zeigt deine konfigurierten Regionen an. Beispiel:

* F

de-by-muc^ F

de-by-nbg

2. Region hinzufügen/bearbeiten

region put <name>       # Neue Region (ohne Forwarding)

region put <name> F     # Neue Region (mit Forwarding)

region allowf <name>    # fügt das F fuer Forwarding hinzu

region denyf <name>     # entfernt das Forwarding-Flag F

region save             # speichert die Tabelle

Das F Flag verstehen

Das wichtigste Symbol überhaupt: F

  • Mit F = Pakete aus dieser Region werden weitergeleitet

  • Ohne F = Pakete werden blockiert (nur lokal empfangen)

Beispiel:

de-by-muc F    ← Pakete werden weitergeleitet

de-by-nbg      ← Pakete werden NICHT weitergeleitet

Die Wildcard * verstehen

Die Wildcard * ist eine Spezial-Region für Geräte ohne Region-Konfiguration.

:warning: WICHTIG: Missverständnis Nr. 1

Viele denken: * F bedeutet „leite alles weiter“, es ist eine Default-Regel

Realität: * F bedeutet „leite nur Pakete von Geräten ohne konfigurierte Region weiter“

Der Repeater unterscheidet zwei Arten von Flood-Paketen:

  • Einfacher Flood (ROUTE_TYPE_FLOOD) – von Companions ohne konfigurierte Region

  • Transport-Flood (ROUTE_TYPE_TRANSPORT_FLOOD) – von Companions mit konfigurierter Region

Die Wildcard * steuert ausschließlich den einfachen Flood. Transport-Flood-Pakete durchlaufen einen eigenen Code-Pfad, bei dem die Wildcard nie konsultiert wird.

Absender Sendet Wildcard * F relevant? Weitergeleitet?
Companion ohne Region einfachen Flood Ja Ja
Companion mit Region de-by-muc Transport-Flood Nein Nur wenn de-by-muc explizit auf dem Repeater konfiguriert ist

Auswirkung auf DM (Direktnachrichten)-Discovery

Die Region-Filterung betrifft alle Flood-Pakete – auch DM-Discovery-Requests (Pfad-Ermittlung). Diese wird durchgeführt, wenn dem Companion noch kein Pfad zum Empfänger bekannt ist.

Direkt-geroutete Pakete (Path-Antwort und eigentliche DM) sind dagegen nicht betroffen:

Phase Route-Typ Region-Filter aktiv?
Discovery-Request (Pfad suchen) Flood Ja – wird blockiert wenn Region auf dem Repeater fehlt
Path-Antwort Direct Nein
Eigentliche DM Direct Nein

Das bedeutet: Scheitert der Discovery-Flood am Repeater, wird der Pfad nie gefunden – und die DM kann gar nicht erst gesendet werden.

Wann wird Discovery blockiert?

Companion Wildcard-Config Ergebnis
Ohne Region * F (Flood erlaubt) Discovery funktioniert
Ohne Region * ohne F (Flood gesperrt) Discovery blockiert
Mit Region de-by-muc Egal – Wildcard spielt keine Rolle Discovery funktioniert nur, wenn de-by-muc F auf dem Repeater konfiguriert ist

Konsequenz: Für Companions ohne Region muss die Wildcard * F gesetzt sein, damit DM-Discovery funktioniert. Für Companions mit Region (z.B. de-by-muc) muss die jeweilige Region mit F auf dem Repeater eingetragen sein – die Wildcard hilft hier nicht.

Standard-Konfigurationen

Konfiguration 1: „Öffentlicher Repeater für eine Region“

Ziel: Unterstütze alle Nutzer in meiner Region.

Konfiguration:

* F
de-by-muc^ F

Was passiert:

  • :white_check_mark: Companions ohne Region: Funktionieren

  • :white_check_mark: Companions mit Region de-by-muc: Funktionieren

  • :cross_mark: Companions mit anderen Regionen: Funktionieren NICHT

Für wen: Lokale Community-Repeater


Konfiguration 2: „Gateway zwischen mehreren Regionen“

Ziel: Verbinde mehrere Regionen miteinander.

Konfiguration:

* F
de-by-muc^ F
de-by-nbg^ F
de-bw-ulm^ F

Was passiert:

  • :white_check_mark: Alle drei Regionen können miteinander kommunizieren

  • :white_check_mark: Companions ohne Region funktionieren auch

Für wen: Repeater an geografischen Grenzen, „Brücken“-Repeater


Konfiguration 3: „Nur meine private Region“

Ziel: Nur meine eigene Gruppe, keine Fremden.

Konfiguration:

*
private^ F

(Beachte: * ohne F)

Was passiert:

  • :white_check_mark: Companions mit Region private: Funktionieren

  • :cross_mark: Companions ohne Region: Funktionieren NICHT

  • :cross_mark: Alle anderen Regionen: Funktionieren NICHT

  • :warning: Achtung bei Direktnachrichten: Da die Wildcard * kein F hat, werden hier auch systemrelevante „Flood DMs“ (Discovery-Pakete zur Wegfindung) von Geräten ohne konfigurierte Region blockiert. Direktnachrichten von/an unkonfigurierte Geräte schlagen an diesem Repeater fehl, da der Repeater den Such-Traffic (ROUTE_TYPE_FLOOD) verwirft.

Für wen: Private Firmen-Netze, abgeschirmte Communities


Konfiguration 4: „Alles durchlassen“ (Maximale Kompatibilität)

Ziel: Ich will allen helfen, egal welche Region.

:warning: Problem: Das geht nicht mit der Wildcard alleine!

Falsche Konfiguration:

* F ← Hilft nur Geräten OHNE Region

Richtige Konfiguration:

Du musst jede Region einzeln eintragen:

* F
de-by-muc^ F
de-by-nbg^ F
de-bw-ulm^ F
at-vie^ F

# ... alle Regionen die du unterstützen willst

Für wen: Zentrale Hub-Repeater mit guter Verbindung


Konfiguration 5: „Gar nichts weiterleiten“

Ziel: Repeater nur für lokale Kommunikation (Zero-Hop).

Konfiguration:

*

(Keine einzige Region mit F)

Was passiert:

  • :cross_mark: Nichts wird weitergeleitet

  • :white_check_mark: Lokale Geräte können direkt empfangen (Zero-Hop)

  • :warning: Routing-Sackgasse: Ein Repeater in diesem Modus leitet auch keine Flood-DMs zur Routenfindung weiter. Das bedeutet, dass er nicht dabei hilft, Wege für neue Direktnachrichten im Netzwerk aufzubauen.

Für wen: Test-Setups, Monitoring-Stationen


Häufige Szenarien und Probleme

Problem 1: „Mein Repeater leitet keine Pakete weiter“

Checkliste:

  1. Zeige Konfiguration: region list

  2. Hat die betroffene Region ein F?

  3. Ist die Home-Region des Companions richtig eingetragen?

  4. Ist der Companion mit Region konfiguriert? → Dann braucht der Repeater die Region!

Häufigster Fehler:

* F ← Admin denkt das reicht

Companion hat aber de-by-mucFunktioniert nicht!

Lösung:

* F
de-by-muc^ F

Problem 2: „Seit Companion-Update funktioniert nichts mehr“

Wahrscheinliche Ursache: Companion hat jetzt eine Region konfiguriert.

Vorher (funktionierte):

  • Companion ohne Region → nutzt Wildcard

  • Repeater hat * F → leitet weiter

Nachher (funktioniert nicht):

  • Companion mit Region de-by-muc → sendet mit Transport-Code

  • Repeater hat nur * Fblockiert!

Lösung: Region zum Repeater hinzufügen:

region add de-by-muc F


Problem 3: „Ich will NUR meine Region, nicht die Wildcard“

Konfiguration:

* ← Ohne F!

meine-region^ F

Effekt:

  • :white_check_mark: Nur deine Region wird weitergeleitet

  • :cross_mark: Alte Geräte ohne Region funktionieren nicht mehr

  • :warning: Routing-Einschränkung (Flood DMs): Das Entfernen des F bei der Wildcard * blockiert das allgemeine Flooding. MeshCore nutzt dieses Flooding aber als Fallback, um initiale Pfade für Direktnachrichten zu finden, wenn die direkte Route (noch) nicht bekannt ist. Ohne * F werden neue DMs von/an Geräte ohne Regions-Tag am Filter gnadenlos gedroppt.

  • Ist das gewollt? → In der Übergangsphase der Community definitiv nicht als Default zu empfehlen, da es das globale Routing für DMs bricht! Wirklich nur für isolierte, private Netze nutzen.


Problem 4: „Hierarchie funktioniert nicht“

Missverständnis:

de-by^ F
  de-by-muc^     ← Angenommen: erbt F von parent

Realität: Hierarchie ist nur optisch!

Ein Paket von de-by-muc wird NICHT von de-by F weitergeleitet!

Lösung: Jede Region explizit markieren:

de-by^ F
de-by-muc^ F

Entscheidungshilfe: Welche Konfiguration brauche ich?

Frage 1: Bist du Teil einer organisierten Community?

JA → Nutze die Community-Region:

* F
community-region^ F

NEIN → Gehe zu Frage 2


Frage 2: Willst du allen helfen oder nur bestimmten Gruppen?

Allen helfen → Trage viele/alle Regionen ein:

* F
region1^ F
region2^ F
region3^ F

Nur bestimmten Gruppen → Nur die Regionen mit F:

*
meine-region^ F

Frage 3: Gibt es alte Geräte ohne Regionen in deinem Gebiet?

JA → Behalte * F:

* F
...

NEIN → Kannst * ohne F nutzen:

*
...

Empfohlene Standard-Konfiguration

Für die meisten Repeater:

* F
de-by-muc^ F

(Ersetze de-by-muc durch deine lokale Region)

Diese Konfiguration:

  • :white_check_mark: Unterstützt alte Geräte ohne Region

  • :white_check_mark: Unterstützt neue Geräte mit deiner Region

  • :white_check_mark: Blockiert andere Regionen (reduziert Traffic)

  • :white_check_mark: Ist einfach zu verstehen


Wichtige Hinweise

:warning: Das ^ Symbol

Das ^ markiert deine Home-Region. Es hat keine Auswirkung auf Forwarding, es ist nur für dich als Marker:

de-by-muc^ ← Das ist "meine" Region

:warning: Groß-/Kleinschreibung

Regionen sind case-sensitive!

de-by-muc :white_check_mark:

DE-BY-MUC :cross_mark: (unterschiedliche Region!)

:warning: Region-Namen

Erlaubte Zeichen: a-z, A-Z, 0-9, -, $, #

Typische Konvention: land-bundesland-stadt

  • de-by-muc (Deutschland-Bayern-München)

  • at-vie (Österreich-Wien)

  • ch-zh (Schweiz-Zürich)


Zusammenfassung: Die Regeln

  1. Wildcard * F = Für Geräte ohne Region

  2. Region mit F = Pakete werden weitergeleitet

  3. Region ohne F = Pakete werden blockiert

  4. Hierarchie = Nur optisch, keine Vererbung

  5. Mehr Regionen = Mehr Traffic, aber mehr Kompatibilität

  6. Weniger Regionen = Weniger Traffic, aber nur bestimmte Gruppen

Faustregel: Wenn du dir unsicher bist, nutze die empfohlene Standard-Konfiguration und füge bei Bedarf weitere Regionen hinzu.