Kanäle, Regions & Scopes

Mit zunehmender Größe des MeshCore-Netzwerks wird es immer wichtiger, Funkverkehr dort zu halten, wo er tatsächlich benötigt wird.

Eine Nachricht für Wien muss normalerweise nicht durch ganz Österreich weitergeleitet werden. Ein Test aus Niederösterreich muss nicht automatisch ganz Österreich erreichen. Genau dafür verwendet MeshCore Regions bzw. Scopes.

Das Ziel von Scoping ist nicht, Kommunikation einzuschränken, sondern das verfügbare Funknetz effizienter zu nutzen:

• weniger unnötige Airtime
• weniger unnötige Weiterleitungen
• weniger Belastung weit entfernter Repeater
• bessere Skalierbarkeit bei wachsender Teilnehmerzahl

Die nachfolgenden Befehle beziehen sich ausschließlich auf die Verwendung der CLI (Command Line Interface) eingaben. Hier wird aktuell NICHT das Meshcore-GUI (iOS/Android APP) erklärt.

Die wichtigste Grundregel lautet: So groß wie notwendig, aber so lokal wie sinnvoll.

Für Firmware 1.12 und neuer werden Public Regions in der MeshCore-GUI und in der Repeater-CLI ohne führendes # geschrieben.

Für Neueinsteiger reicht zunächst dieses Modell:

CHANNEL
= In welcher Gruppe schreibe ich?

SCOPE
= Für welches geografische Gebiet soll die Nachricht verteilt werden?

REGION AM REPEATER
= Welche gescopten Nachrichten leitet dieser Repeater weiter?

Beispiel für den österreichweiten Channel:

Channel: #austria
Scope:   at

Auf dem Repeater heißt die dazugehörige Public Region:

at

Damit ergibt sich:

#austria
   |
   +--> Scope: at
            |
            +--> Repeater mit Public Region at

Hashtag-Channels und Public Regions werden bewusst unterschiedlich geschrieben:

Wenn wir schreiben:

Channel: #vienna
Scope:   at-w

ist #vienna der Channel. at-w ist zugleich Scope und Name der Public Region auf dem Repeater.

Ein Channel ist die Kommunikationsgruppe.

Beispiele:

#austria
#vienna
#noe
#ooe
#inn-salzach
#english
#test
#bot

Der Scope bestimmt dagegen, in welchem geografischen Bereich eine Nachricht sinnvoll weitergeleitet werden soll.

Beispiel:

#austria
Scope: at

Ein lokaler Wiener Channel verwendet dagegen:

#vienna
Scope: at-w

Eine Region ist eine organisierte geografische Kennzeichnung.

Auf einem Repeater können beispielsweise folgende Public Regions hinterlegt sein:

*
europe
at
at-ost
at-w

Der Repeater entscheidet anhand seiner konfigurierten Regions und Flood-Berechtigungen, welche gescopten Flood-Pakete er weiterleiten darf.

Der Befehl:

region

zeigt die konfigurierten Regions und deren Flood-Status an.

Bei der hier empfohlenen flachen Konfiguration sieht die Ausgabe beispielsweise so aus:

*^ F
europe F
at F
at-ost F
at-w F

Das F bedeutet, dass Flooding für diese Region erlaubt ist.

Das ist besonders wichtig für die Konfiguration:

Neu mit region put angelegte Regions sind bereits standardmäßig für Flooding freigegeben.

Wenn nach:

region put at-w

die Antwort:

OK - (flood allowed)

erscheint, ist ein zusätzliches:

nicht notwendig.

Dasselbe gilt für alle weiteren mit region put neu erzeugten Regions.

region allowf wird daher hauptsächlich benötigt, wenn:

• eine bereits vorhandene Region aktuell gesperrt ist,
• eine zuvor mit region denyf deaktivierte Region wieder freigegeben werden soll,
• oder der Wildcard-Eintrag * gezielt für ungescopte Pakete aktiviert werden soll.

Der Scope ist die Region, die für eine Nachricht bzw. einen Channel verwendet wird.

Wenn wir schreiben:

Scope: at-w

meinen wir die öffentliche MeshCore-Region:

at-w

* ist ein Sonderfall.

Der Wildcard-Eintrag:

*

steuert insbesondere den Umgang mit Flood-Paketen ohne Region Transport Code, also mit ungescopten Paketen.

Beispiel:

region allowf *

bedeutet:

Ungescopte Flood-Pakete dürfen weitergeleitet werden.

Dagegen:

region denyf *

bedeutet:

Ungescopte Flood-Pakete werden verworfen.

Wichtig:

Wenn die Ausgabe von:

region

bereits beispielsweise:

*^ F

zeigt, ist auch:

region allowf *

bereits nicht mehr notwendig.

Wir empfehlen daher grundsätzlich:

Zuerst region ansehen und nur Flood-Berechtigungen ändern, die tatsächlich geändert werden müssen.

Für eine Scoped-Nachricht arbeiten Companion und Repeater zusammen:

1. Im Companion wählst du einen Channel und den dazu passenden Scope, zum Beispiel #vienna mit dem Scope at-w.
2. Die gesendete Nachricht trägt genau einen Scope. Eine ungescopte Nachricht trägt stattdessen keinen Scope und fällt unter *.
3. Ein Repeater prüft, ob er genau diese Public Region kennt und ob dafür Flooding erlaubt ist (F). Nur dann leitet er das Paket weiter.
4. Ein Repeater ohne diese Region leitet das Paket nicht weiter. Dadurch bleibt lokaler Verkehr lokal und belastet nicht unnötig entfernte Infrastruktur.

Hat ein Repeater mehrere erlaubte Regions, gilt das als ODER: Er kann Pakete für jede dieser Regions weiterleiten. Das bedeutet nicht, dass * alle Regions umfasst. * steht ausschließlich für ungescopte Pakete.

Ein Scope ist keine Verschlüsselung und keine private Gruppe. Er ist ein Filter für die Verteilung im Funknetz. Die Privatsphäre eines Channels wird über dessen Channel-Konfiguration geregelt, nicht über den Scope.

Die Funktion Discover Regions zeigt Regions, die dem Companion bekannt sind, und hilft bei der Auswahl eines passenden Scopes. Sie legt eine Region jedoch nicht auf Repeatern an und schaltet dort auch kein Flooding frei.

Damit ein Scope in der Praxis funktioniert, müssen entlang des gewünschten Wegs passende Repeater diese Public Region besitzen und dafür Flooding erlauben. Wird eine Region nur im Companion ausgewählt, aber von den erreichbaren Repeatern nicht unterstützt, kann die Nachricht lokal enden oder gar nicht weitergeleitet werden.

Für die Auswahl gilt als einfache Orientierung:

• lokaler Channel: möglichst den lokalen Scope verwenden, zum Beispiel at-w;
• Kommunikation über mehrere Bundesländer: einen passenden größeren Scope verwenden, zum Beispiel at-ost;
• österreichweite Kommunikation: at verwenden;
• ungescopte Kommunikation nur dort verwenden, wo sie ausdrücklich gewünscht und von * unterstützt wird.

Ohne Scoping könnte beispielsweise eine lokale Wiener Nachricht über immer weitere Repeater verbreitet werden:

Wien
 |
 +--> Niederösterreich
       |
       +--> Oberösterreich
             |
             +--> Salzburg
                   |
                   +--> Tirol
                         |
                         +--> ...

Für eine lokale Nachricht ist das meistens unnötig.

Mit:

Scope: at-w

kann die Kommunikation auf die dafür vorgesehene Infrastruktur beschränkt werden.

Für MeshCore Austria werden die Regions bewusst ohne technische Hierarchie angelegt. Jede verwendete Region liegt direkt unter der Null-Region *.

*
|
+-- europe
+-- at
+-- at-ost
+-- at-sued
+-- at-west
+-- at-w
+-- at-noe
+-- at-bgld
+-- at-stmk
+-- at-ktn
+-- at-ooe
+-- at-sbg
+-- at-t
+-- at-vbg

Die Namen folgen weiterhin einer verständlichen geografischen Namenslogik. Beispielsweise steht at-ost für Ostösterreich und at-w für Wien. Daraus entsteht aber keine Parent-Child-Vererbung: Jede Region ist ein eigenständiger Eintrag.

Die Public Regions auf dem Repeater lauten:

europe
at

at-ost
at-sued
at-west

at-w
at-noe
at-bgld

at-stmk
at-ktn

at-ooe
at-sbg
at-t
at-vbg

Die folgenden Gruppen dienen nur der Orientierung. Sie sind keine technischen Ebenen und bewirken keine Vererbung.

*

Für Flood-Pakete ohne Region Transport Code.

Scope:

europe

Public Region:

europe

Für länderübergreifende Kommunikation.

Scope:

at

Public Region:

at

Für österreichweite Kommunikation.

at-ost
at-sued
at-west

Diese Namen können für größere österreichische Bereiche verwendet werden. Sie sind technisch eigenständige Regions direkt unter *.

Der gemeinsame österreichweite Channel:

#austria

verwendet:

Scope: at

bzw. als Public Region:

at

Channel:       #vienna
Scope:         at-w
Public Region: at-w

Channel:       #noe
Scope:         at-noe
Public Region: at-noe

Channel:       #ooe
Scope:         at-ooe
Public Region: at-ooe

#inn-salzach deckt einen größeren Bereich im Westen Österreichs ab.

Empfehlung:

Channel:       #inn-salzach
Scope:         at-west
Public Region: at-west

Für:

#english
#slovakia
#hungary
#czech

empfehlen wir derzeit:

Scope: europe
Public Region: europe

Sollten künftig abgestimmte nationale oder grenzüberschreitende Regions-Strukturen existieren, kann diese Empfehlung entsprechend angepasst werden.

#test und #bot verwenden bewusst nicht den lokalen Bundesland-Scope, sondern die direkt darüberliegende österreichische Großregion.

Beispiel Wien:

#vienna
Scope: at-w

#test
Scope: at-ost

#bot
Scope: at-ost

Der Scope von #ping richtet sich danach, welcher Bereich tatsächlich getestet werden soll.

lokal Wien       -> at-w
Ostösterreich    -> at-ost
Österreich       -> at

Channel:       #wetter-simmering
Scope:         at-w
Public Region: at-w

Lokaler / Bundesland-Channel?
        |
        +--> lokaler Scope

#test oder #bot?
        |
        +--> nächsthöhere Großregion

Mehrere Bundesländer einer Großregion?
        |
        +--> at-ost / at-sued / at-west

Ganz Österreich?
        |
        +--> at

Länderübergreifend?
        |
        +--> europe

Für die Konfiguration gibt es zwei relevante Möglichkeiten:

• lokal über USB und die Console von flasher.meshcore.io
• nachträglich über die Remote Command Line eines Repeaters

Dieser Punkt ist für eine möglichst einfache Konfiguration besonders wichtig.

Die aktuelle MeshCore-CLI legt neue Regions mit:

region put

standardmäßig bereits als flood-allowed an.

Beispiel:

region put europe

Antwort:

OK - (flood allowed)

Damit ist keine weitere Freigabe erforderlich.

Dasselbe gilt beispielsweise für flach angelegte Regions:

region put at
region put at-ost
region put at-w

Wenn diese Befehle erfolgreich waren, ist keine zusätzliche Flood-Freigabe notwendig.

Die früher auf dieser Seite gezeigten Konfigurationsblöcke mit region allowf nach jedem region put waren daher unnötig ausführlich.

region allowf bleibt ein wichtiger Befehl.

Er wird aber nur benötigt, wenn eine Region bereits existiert und aktuell nicht für Flooding freigegeben ist.

Beispiel:

region get at-w

zeigt, dass Flooding gesperrt ist. Daran zu erkennen, das nach der jeweiligen Region kein „F“ steht!

Dann:

region allowf at-w
region save

Ein weiterer häufiger Anwendungsfall ist der Wildcard-Eintrag:

*

Wenn:

region

kein F beim Wildcard-Eintrag zeigt und ungescopte Pakete weiterhin erlaubt sein sollen:

region allowf *
region save

Zeigt region dagegen bereits:

*^ F

ist auch dieser Befehl nicht erforderlich.

Repeater per USB verbinden und:

https://flasher.meshcore.io

öffnen.

Danach die Console öffnen und den seriellen Port auswählen.

ver

Immer zuerst:

region

Das zeigt die bestehenden Regions und ihren Flood-Status.

Nur ändern, was tatsächlich geändert werden muss.

Beispiel Wien:

*
+-- europe
+-- at
+-- at-ost
+-- at-w

Konfiguration:

region def europe|* at|* at-ost|* at-w|*

Optional bei entsprechender Funkabdeckung:

region put at-noe

Danach:

region

Die neuen Regions sollten bereits mit F angezeigt werden. Alle genannten Regions liegen direkt unter *.

Wenn alles korrekt ist:

region save

Es sind keine zusätzlichen region allowf #…-Befehle erforderlich.

Zuerst:

region

Angenommen vorhanden:

*
+-- europe
+-- at
+-- at-ost
+-- at-w

Niederösterreich ergänzen:

region put at-noe

Danach:

region

und:

region save

region get at
region get at-ost
region get at-w

Nur wenn eine bestehende Region gesperrt ist:

region allowf at-w
region save

region denyf at-w
region save

region denyf NAME sperrt das Flooding fuer genau diese eine Public Region auf diesem Repeater. Die Region wird dadurch nicht geloescht, aber Flood-Pakete mit diesem Scope werden von diesem Repeater nicht mehr weitergeleitet. Andere Regions bleiben davon unberuehrt.

Flood Deny sollte nur eingesetzt werden, wenn bewusst festgelegt werden soll, dass ein Repeater fuer einen bestimmten Scope nicht als Verteilpunkt dienen soll. Das kann beispielsweise bei einem klar abgegrenzten lokalen Repeater, bei unerwuenschter Ausbreitung eines bestimmten Scopes oder waehrend einer kontrollierten Umstellung sinnvoll sein.

Nicht als erste Massnahme verwenden, nur weil zu viel Verkehr vermutet wird. Zuerst pruefen, ob die betroffene Region tatsaechlich benoetigt wird und ob die Scopes der verwendeten Channels korrekt gesetzt sind.

Vor einem region denyf NAME immer:

• mit region den aktuellen Zustand ansehen;
• genau pruefen, welche Public Region gesperrt werden soll;
• sicherstellen, dass wichtige lokale, regionale und oesterreichweite Kommunikation nicht auf diese Region angewiesen ist;
• bei Remote-Aenderungen pruefen, dass der Repeater danach weiterhin ueber einen anderen erlaubten Weg erreichbar ist;
• beruecksichtigen, dass benachbarte Repeater die gesperrte Region eventuell weiterhin weiterleiten koennen.

Sicherer Ablauf:

region
region denyf at-w
region

Erst die Ausgabe kontrollieren. Wenn die Wirkung wie gewuenscht ist, dauerhaft speichern:

region save

Falls die Sperre nicht gewuenscht war oder eine benoetigte Region dadurch fehlt:

region allowf at-w
region save

Besonders wichtig: region denyf * ist etwas anderes. Es betrifft nicht eine einzelne Region, sondern alle ungescopten Flood-Pakete. Dafuer gelten die besonderen Hinweise im folgenden Abschnitt.

Serielle CLI, Firmware 1.12+:

region list allowed

bzw.:

region list denied

region remove at-noe
region save

Bei der hier empfohlenen flachen Konfiguration kann jede Region unabhängig entfernt werden. Eine Löschreihenfolge nach Parent-Child-Beziehungen ist nicht erforderlich.

MeshCore besitzt derzeit keinen eigenen:

region reset

oder:

region clear

Befehl.

Soll die Regions-Konfiguration vollständig neu aufgebaut werden, werden die nicht mehr benötigten Regions einzeln entfernt.

Beispiel einer flachen Konfiguration:

*
+-- europe
+-- at
+-- at-ost
+-- at-w
+-- at-noe

Entfernen:

region remove at-w
region remove at-noe
region remove at-ost
region remove at
region remove europe

Danach:

region

prüfen.

Wenn nur noch * vorhanden ist, kann die neue flache Konfiguration angelegt werden.

Am Ende:

region save

Der Befehl:

erase

ist kein Regions-Reset, sondern ein vollständiger Factory Reset des Nodes und sollte dafür nicht verwendet werden.

Der Default Scope ist die Region, mit der der Repeater seine eigenen Flood-Adverts versieht. Mit region default at werden die eigenen Flood-Adverts mit dem Scope at gesendet. Andere Repeater leiten diese Adverts nur weiter, wenn sie diese Region kennen und dafür Flooding erlauben.

Damit bestimmt der Default Scope vor allem, wie weit der Repeater selbst im Mesh sichtbar wird und wo andere Nodes eine Route zu ihm lernen können. Ein engerer Scope hält seine Adverts regional; ein breiterer Scope macht ihn über einen größeren Bereich sichtbar.

Er beeinflusst nicht, welche fremden oder empfangenen Pakete der Repeater weiterleitet. Dafür sind weiterhin die konfigurierten Regions und die Flood-Berechtigungen zuständig.

Anzeigen:

region default

Setzen:

region default at

Entfernen:

region default null

Der Default Scope bestimmt nicht, welche fremden Flood-Pakete weitergeleitet werden.

Beispiel: region default at-ost kann sinnvoll sein, damit die Adverts eines Repeaters in ganz Ostösterreich sichtbar sind. Die Wahl hängt von der gewünschten Erreichbarkeit ab, nicht nur vom exakten Standort.

Ein Default Scope ist daher optional. Ohne Default Scope bleiben eigene Flood-Adverts ungescopt. Soll keine Standardregion gesetzt sein, kann der Wert leer bleiben oder mit region default null entfernt werden.

Fuer MeshCore Austria werden Regions flach definiert. Es gibt keine Parent-Child-Vererbung.

Die Regel ist verbindlich: Nach jedem einzelnen Regionsnamen, auch nach dem letzten, muss |* stehen. Damit springt der Cursor nach jeder Definition zur Null-Region * zurueck.

Beispiel fuer Wien mit Burgenland:

region def europe|* at|* at-ost|* at-w|* at-bgld|*
region
region save

Alle Regions in diesem Beispiel liegen direkt unter *. Die Namen at-ost, at-w und at-bgld sind nur eine logische Namenskonvention; sie bilden keine technische Vererbung.

Eine Region ergaenzen:

region def at-noe|*
region
region save

Neue Regions aus region def sind bereits flood-allowed. Ein zusaetzliches region allowf ist nicht erforderlich.

Bei bestehenden Regions zuerst region ausfuehren, anschliessend nur die benoetigten flachen Eintraege definieren, erneut region pruefen und danach region save ausfuehren.

Für größere Strukturen existiert:

region load

region load kann auch hierarchische Eingaben abbilden. Diese Möglichkeit wird in dieser Anleitung bewusst nicht verwendet, weil die österreichischen Beispiele flach unter * angelegt werden.

Für die hier empfohlene flache Konfiguration ist region def mit |* nach jedem Regionsnamen die übersichtlichere und besser nachvollziehbare Variante.

Der interaktive Aufruf von region load ohne Argument funktioniert nicht sinnvoll über die Remote-CLI.

Wenn Remote Administration eingerichtet ist:

• Repeater auswählen
• Remote Administration öffnen
• Command Line öffnen

Zuerst:

ver
region

Dann nur die notwendigen Änderungen durchführen.

Beispiel Wien:

region put europe
region put at
region put at-ost
region put at-w

Optional:

region put at-noe

Danach:

region

prüfen.

Wenn die neuen Regions mit F angezeigt werden:

region save

Mehr ist nicht notwendig.

region put at-noe
region
region save

Nur wenn erforderlich:

region allowf at-noe
region save

region denyf at-noe
region save

region remove at-noe
region save

region denyf * verwirft ungescopte Flood-Pakete.

Vorher sicherstellen:

• benötigte Public Regions sind vorhanden
• die benötigten Regions sind flach und korrekt angelegt
• benötigte Regions sind flood-allowed
• angrenzende Repeater unterstützen die benötigten Regions
• gewünschte Kommunikation funktioniert
• Remote-Zugriff funktioniert weiterhin

Wenn:

region

bereits:

*^ F

zeigt, muss region allowf * nicht erneut gesetzt werden.

Aktuellen Wert anzeigen:

get flood.max.unscoped

Beispielsweise:

set flood.max.unscoped 3

Damit können ungescopte Nachrichten noch lokal weiterlaufen, ohne unnötig weit geflutet zu werden.

Die folgenden Beispiele sind bewusst minimal gehalten und verwenden keine technische Regionshierarchie. Jede Region wird direkt unter * definiert.

Da region put neue Regions bereits flood-allowed anlegt, werden keine redundanten region allowf #…-Befehle mehr verwendet.

Nach jedem Aufbau sollte mit:

region

geprüft werden, ob die benötigten Einträge ein F besitzen.

region def europe|* at|* at-ost|* at-w|*

region default at

region
region save

Optional Niederösterreich & Burgenland:

region def europe|* at|* at-ost|* at-w|* at-noe|* at-bgld|*
region
region save

region def europe|* at|* at-ost|* at-noe|*

region default at

region
region save

Optional Wien & Burgenland:

region def europe|* at|* at-ost|* at-w|* at-noe|* at-bgld|*
region
region save

region def europe|* at|* at-ost|* at-bgld|*

region default at

region
region save

Optional Niederösterreich & Wien:

region def europe|* at|* at-ost|* at-w|* at-noe|* at-bgld|*
region
region save

region def europe|* at|* at-sued|* at-stmk|*

region default at

region
region save

region def europe|* at|* at-sued|* at-ktn|*

region default at

region
region save

region def europe|* at|* at-west|* at-ooe|*

region default at

region
region save

region def europe|* at|* at-west|* at-sbg|*

region default at

region
region save

region def europe|* at|* at-west|* at-t|*

region default at

region
region save

region def europe|* at|* at-west|* at-vbg|*

region default at

region
region save

Nein.

Ein Repeater soll jene Regions kennen, die aufgrund seines Standortes und seiner Funkabdeckung sinnvoll sind.

Grenzrepeater können mehrere benachbarte lokale Regions besitzen.

Beispiel Wien / Niederösterreich:

at-w
at-noe

Optional kann zusätzlich die eigenständige Region:

at-ost

angelegt werden, wenn sie für einen verwendeten Scope benötigt wird. Sie ist kein gemeinsamer Parent der beiden lokalen Regions.

Firmware:

ver

Regions und Flood-Status:

region

Neue Region:

region put NAME

Wichtig:

region put

legt neue Regions bereits flood-allowed an.

Einzelne Region:

region get #NAME

Bestehende gesperrte Region wieder erlauben:

region allowf #NAME

Region sperren:

region denyf #NAME

Ungescopte Pakete erlauben, falls noch nicht erlaubt:

region allowf *

Region entfernen:

region remove #NAME

Default Scope:

region default #NAME

Default Scope löschen:

region default null

Flache Regionsdefinition kompakt anlegen:

region def europe|* at|* at-ost|* at-w|*

Speichern:

region save

1. ver

2. region

3. benötigte Regions mit region put anlegen

4. region

5. prüfen, ob die neuen Regions mit F markiert sind

6. nur falls nötig:
   region allowf ...

7. Default Scope setzen

8. region

9. region save

1. region

2. bestehende Regions und ihren Flood-Status prüfen

3. nur fehlende Regions mit region put ergänzen

4. region

5. nur gesperrte benötigte Regions mit region allowf aktivieren

6. nicht mehr benötigte Regions bei Bedarf entfernen

7. region

8. region save

• erase ist kein Regions-Reset, sondern ein Factory Reset des gesamten Nodes. AUFPASSEN

Companion:

• #austria ist ein Channel (Companion).
• at schreiben wir auf dieser Seite als Scope (Companion).
• daher ist der Kanal #austria mit dem Scope at in Verwendung (Companion).
• Normale lokale Channels verwenden den lokalen Scope (Companion).
• #test und #bot verwenden die nächsthöhere Großregion (Companion).
• #ping verwendet den Scope des tatsächlich getesteten Gebiets (Companion).

Repeater bzw. Repeater Admin Konfiguration im Companion Remote, oder über Serial:

• Die Public Region dazu heißt at.
• Die region-Ausgabe kann Public Regions je nach Firmware ohne führendes # anzeigen.
• F bedeutet, dass Flooding für die betreffende Region erlaubt ist.
• region put legt neue Regions bereits standardmäßig flood-allowed an, selbiges bei region def.
• Deshalb sind zusätzliche region allowf #…-Befehle nach erfolgreichen region put-Befehlen normalerweise überflüssig.
• region allowf ist vor allem für bereits vorhandene, gesperrte Regions oder für * relevant.
• Auch region allowf * ist nur erforderlich, wenn * nicht bereits mit F angezeigt wird.
• * steuert ungescopte Flood-Pakete und bedeutet nicht einfach „alle Regions“.
• Nicht jeder Repeater benötigt alle österreichischen Regions.
• Vor jeder Änderung zuerst region ausführen.
• Nach Änderungen erneut region prüfen.
• Erst danach region save verwenden.
• Es gibt keinen eigenen region reset-Befehl; für einen Neuaufbau werden nicht mehr benötigte Regions mit region remove entfernt.
• region load ohne Argument ist interaktiv und nicht für Remote-CLI geeignet.

ÖSTERREICHWEIT

#austria
Scope: at

LOKAL WIEN

#vienna
Scope: at-w

TEST / BOT AUS WIEN

#test / #bot
Scope: at-ost

Und für die Repeater-Konfiguration:

region put europe
region put at
region put at-ost
region put at-w

region
region save

Wenn region danach:

europe F
at F
at-ost F
at-w F

zeigt, ist alles bereits für Flooding freigegeben.

Zusätzliche Flood-Freigaben sind dann nicht notwendig.

So bleibt die Konfiguration einfacher, verständlicher und näher am tatsächlichen Verhalten der MeshCore-CLI.