MeshCore Regions / Flooding – Vorschlag für sinnvolle Default-Einstellungen

General
1

Hallo zusammen

Ich bin neu hier im Forum und vor Kurzem von Meshtastic auf MeshCore umgestiegen bzw. gerade dabei, MeshCore auszuprobieren. Dabei habe ich zunächst die auf

empfohlenen Einstellungen übernommen.

Ich habe auch die bestehenden Beiträge hier im Forum zum Thema Flooding und Regions gelesen, insbesondere:

Da diese Diskussion schon etwas älter ist und ich keinen neueren Beitrag dazu gefunden habe, möchte ich meine aktuellen Beobachtungen und einen daraus abgeleiteten Vorschlag zur Diskussion stellen.

Meine Beobachtung

Ich habe mit den Region-Einstellungen getestet und dabei folgendes Verhalten beobachtet:

Wenn auf einem Repeater für die Root-Region * Flooding deaktiviert ist, scheint die Erreichbarkeit stark davon abzuhängen, dass entlang des gesamten benötigten Pfads eine gemeinsame Region vorhanden ist und von allen beteiligten Repeatern gefloodet wird.

Das betrifft nach meinen Beobachtungen nicht nur Channels, sondern insbesondere auch Direct Messages (DMs) bzw. die Path Discovery. Wenn die beteiligten Repeater keine durchgängig unterstützte gemeinsame Region wie beispielsweise europe, dach oder ch haben, kann ein ansonsten möglicher Pfad unterbrochen werden.

Ähnliches beobachte ich bei der Default Region eines Companion/Client-Geräts: Sobald dort beispielsweise ch als Default Region gesetzt ist, wird der entsprechende Traffic mit diesem Region Scope versendet. Befindet sich auf dem benötigten Pfad ein Repeater, der ch nicht floodet, kommt die Nachricht offenbar nicht durch.

Konkreter Test

Standort: Konstanz (Deutschland, Grenzregion)

Mit Default Region ch:

  • Companion/Client mit Default Region ch
  • Ping in #test
  • Ergebnis: keine Antwort

Ohne Default Region:

  • gleicher Client, gleicher Standort
  • Default Region entfernt
  • erneut Ping in #test
  • Ergebnis: Winterthur wird über 9 Hops erreicht und die Antwort kommt zurück

Für mich ist das ein recht anschauliches Beispiel: Der Pfad Konstanz → Winterthur über 9 Hops ist grundsätzlich vorhanden und funktioniert ohne Region Scope. Mit ch als Default Region funktioniert er hingegen nicht.

Vorschlag für robuste Default-Einstellungen

Daraus ergibt sich für mich momentan folgender Ansatz:

Repeater:

  • * standardmässig Flood erlauben
  • unscoped Traffic stattdessen über flood.max.unscoped auf eine sinnvolle maximale Hop-Anzahl begrenzen
  • Regions wie ch, ch-de, dach und europe zusätzlich verwenden, um regionalen Traffic gezielt zu steuern bzw. zu begrenzen

Companion/Client:

  • standardmässig keine Default Region
  • eine Default Region nur setzen, wenn bewusst eine entsprechende Einschränkung gewünscht ist bzw. sichergestellt ist, dass die relevante Repeater-Infrastruktur diese Region durchgängig unterstützt

Damit wären Regions in erster Linie ein Mittel zur Optimierung und Begrenzung des Floodings, ohne dass sie unbeabsichtigt die Erreichbarkeit zwischen verschiedenen Teilen des Meshes unterbrechen.

Gerade bei mobilen Clients halte ich das für wichtig: Ein Client weiss im Voraus nicht, über welche Repeater eine Nachricht bzw. eine Path Discovery tatsächlich laufen wird. Insbesondere in Grenzregionen kann der funktionierende Pfad über Repeater mit unterschiedlichen Region-Konfigurationen führen.

Deshalb erscheint mir als robuster Ausgangspunkt:

* Flood erlauben + flood.max.unscoped sinnvoll begrenzen + keine Default Region am Companion

statt unscoped Traffic grundsätzlich zu blockieren.

Mich würde interessieren, ob ich das Region-/Flooding-Modell von MeshCore damit richtig interpretiere und ob andere dieses Verhalten – insbesondere den Unterschied mit und ohne Default Region am Companion – ebenfalls reproduzieren können.

2

Persönlich nutze ich die max.flood.unscoped und sperre die Region * nicht. Da gehen die Meinungen aber auseinander. Persönlich nutze ich auf dem Client immer eine Region, passe die aber nach Bedürfnis an. Seit ein paar Tagen sind aber meine Clients ausgeschaltet, da so oder so nur Blödsinn versendet wird. Völlig belanglosen Scheissdreck, den niemand interessiert. Meine Repeater laufen aber nach wie vor. Siehe: Lesenswerter Report aus NL: Was bremst unser Mesh wirklich? - #3 by Pepe_The_Frog

2 Likes
3

Du beingst es auf den Punkt und lieferst auch die Erklärung, warum viele Betreiber eine isolierte Insel die funktioniert einem grossen Netz vortiehen, welches nicht (mehr) funktioniert. Leider verstehen einige Benutzer den Sinn solcher Netze nicht und verwechseln sie mit einer Gaming-Party.

L.G. Christoph

2 Likes
4

Den Konsens, «flood *» zu deaktivieren, wieder in Frage zu stellen, ist eine vermeintlich gute Idee, die sich jedoch als falsch erweist.

Angesichts der exponentiell steigenden Nutzerzahlen wird die Überlastung der Bandbreite zu einem immer grösseren Problem. Wir müssen verantwortungsbewusst handeln und dem zuvorkommen. So zu tun, als würde das Problem nie auftreten, ist keine verantwortungsvolle Option.

Leider verwechseln die meisten Nutzer Meshcore mit WhatsApp und nutzen ausschliesslich die öffentlichen Kanäle. Ausserdem versenden sie wenig nützlichen Datenverkehr («Schönen Tag», «Guten Abend aus Lausanne», «Erhalten mit 10 Hops»). Wir müssen Lösungen finden, um den Datenverkehr so weit wie möglich einzuschränken. Massnahmen wie die Reduzierung der Häufigkeit von Adverts sind zwar nützlich, angesichts der Herausforderung jedoch völlig unzureichend.

«Flood *» zuzulassen bedeutet, an der Utopie eines riesigen Mesh-Netzwerks festzuhalten, das ganz Europa (und warum nicht den ganzen Planeten) abdeckt. Das ist eine utopische und absolut unrealistische Vorstellung vom Mesh-Netzwerk. Nach einigen Hops steigt die Wahrscheinlichkeit, dass die Nachricht nicht zugestellt wird. Die Verzögerungen nehmen zu. Mit zunehmender Entfernung nähert sich die Wahrscheinlichkeit, dass die Verbindung unterbrochen wird, schliesslich 100 % an.

Ich betreibe mehrere Repeater im Wallis. Warum sollte ich Solarenergie und Bandbreite darauf verwenden, Advert-Nachrichten aus Norddeutschland oder Südkroatien an meine Nachbarn weiterzuleiten? Wen in der Schweiz interessiert es schon, dass ein Benutzer irgendwo in Griechenland sein Radio eingeschaltet und eine Advert gesendet hat? Das macht überhaupt keinen Sinn.

Das Zulassen von Nachrichten ohne Scope trägt dazu bei, die Frequenz zu überlasten, die Dienstqualität für alle zu verschlechtern und die Sendegeschwindigkeit legitimer Nachrichten zu verringern (aufgrund von Kollisionen). Dies wird unweigerlich zu einer Überlastung des Netzwerks führen, d. h. zur statistischen Unmöglichkeit, dass Nachrichten rechtzeitig gesendet werden können.

Bei einem Duty-Cycle von 10 % führt das Zulassen von Nachrichten ohne Region dazu, dass die Repeater einen Teil ihrer Zeit damit verbringen, völlig nutzlose Advert-Nachrichten vom anderen Ende Europas weiterzuleiten. Es besteht dann die Gefahr, dass ihre Sendekontingente aufgebraucht werden und legitime Nachrichten nicht mehr versendet werden können. Auch dies verschlechtert die Qualität für alle.

Die Lösung «allow.flood.unscoped» wird leider als Möglichkeit genutzt, die Regionspflicht zu umgehen. Das ist zwar eine Art, sich ein gutes Gewissen zu verschaffen, läuft aber de facto darauf hinaus, zumindest auf lokaler Ebene zu einem Mesh ohne Regionen zurückzukehren. Dies ist insbesondere dann der Fall, wenn der Wert auf mehr als 1 oder 2 eingestellt ist. Anstatt gefiltert zu werden, wird der Datenverkehr ohne Region einfach tiefer ins Netzwerk weitergeleitet, in der Annahme, dass der nächste Repeater die Aufgabe hat, ihn zu filtern.

Wir müssen verantwortungsbewusst handeln: Das Wachstum der Nutzerzahlen ist nicht nur eine Tatsache, sondern lässt sich auch planen. Wir dürfen nicht so tun, als wären wir überrascht.

Wir müssen heute Massnahmen ergreifen, damit das Mesh auch in 6, 12 oder 18 Monaten noch funktioniert – trotz der Hunderte von «Gute Nacht»- und «Erhalten in 5 Hops»-Nachrichten, die stündlich versendet werden. Die katastrophale Erfahrung mit Meshtastic zeigt uns, dass ein Mesh ohne Regionen zusammenbricht. Es ist amüsant festzustellen, dass die Nutzer von Meshtastic alle zu Meshcore wechseln und dennoch genau dieselben Fehler wiederholen, die Meshtastic zum Scheitern gebracht haben. Was für eine Ironie!

Man wird mir sagen: «Die neuen Nutzer kennen sich mit der Einstellung der Regionen nicht aus.» Na und? Wenn man eine Technologie nutzt, versucht man dann nicht ziemlich schnell herauszufinden, wie sie funktioniert? Sehr schnell gelangen neue Nutzer auf «meshcore.ch» und finden dort Informationen. Warum sollte man Nutzer belohnen, die sich weigern, sich zu informieren, und damit die Qualität für alle anderen gefährden? Das Verhindern von «Flood *» hat einen pädagogischen Wert: Es zwingt die Nutzer dazu, sich EIN WENIG über die Funktionsweise des Netzwerks zu informieren. Und wenn sie feststellen, dass es nicht wie WhatsApp oder Facebook funktioniert, scheint mir das sehr vorteilhaft zu sein!

Ich hoffe, dass die Empfehlungen bezüglich der Regionen und des «Flood *» so bleiben, wie sie heute sind, und dass es nicht zu einer zunehmenden Nachlässigkeit kommt. Würde man beispielsweise «allow.flood.unscopped» auf 2 oder 3 setzen, hätte dies verheerende Folgen für die hochgelegenen Repeater, die ihre Schutzfunktion für das Netz nicht mehr erfüllen würden und zusätzlichen unzulässigen Datenverkehr, unnötige Werbung und falsch konfigurierte Bots in den Schweizer Frequenzbereich senden würden.

7 Likes
5

Ich bin zwar kein Fan von Blockaden, aber vermutlich wäre es ein Ansatz, wenn man einzelne User schlicht und einfach Sperrt. Bzw. es bräuchte die Möglichkeit, bestimmte User direkt auf dem Repeater zu blockieren. Es sind ja so oder so immer die gleichen Whatsapp-Nachrichten von den gleichen Nutzern. Man müsste diese anschreiben und Ihnen das ganze erklären. Nützt es nichts, wird der User direkt auf dem Repeater gesperrt. Kommt dann eine Nachricht vom User XY, wird sie schlicht und einfach nicht weitergeleitet. Wäre allerdings mit Arbeit für uns alle verbunden.

Es ist wie beim Autofahren. Jeder macht irgendwie was er will. Es wird gerast, gedrängelt, etc. Dafür gibt es Bussen, damit es einigermassen in Grenzen bleibt. Genau gleich (und ich bin kein Fan davon), müsste es auch im Meshcore betrieben werden. Wird das System für Müll ausgenutzt, wird man ausgeschlossen.

Wieso diese Härte? Weil selbst mit Region, jeder irgendwelchen Scheissdreck (sorry) verbreiten kann. Unter Public lese ich aktuell alles, von test, meow, Moin, Guten Morgen aus Freiburg, etc. Regelmässig schreibt auch jemand, wo er jetzt gerade seine Pause macht. Was interessiert es die Leute, wer wo Pause einlegt und was er sich jetzt gerade zwischen die Binde schiebt?

Ich sehe jedenfalls keine andere Lösung, ausser es werden Nutzer gedrillt und ansonsten blockiert.

Es gibt schlicht und einfach Personen, mit denen kann man nicht diskutieren. Das merke ich auch in meiner Nachbarschaft, mit einem anderen Repeater User. Ich habe mich kurzgeschlossen, damit wir uns nicht in die Quere kommen. Es kamen mal Antworten, heute ist allerdings Ruhe. Seine Repeater stehen und man sieht sie, aber die Repeater Funktion wurde deaktiviert. Dann bau ich eben das Tal selbst aus. Ist schade und kam in meiner Region nun zweimal vor. Genau gleich geht es im Mesh ab, viele machen was sie wollen und scheren sich um nichts.

6

Das sind zwei verschiedene Themen.

Die von Ihnen angesprochene Frage der Aufklärung der Nutzer ist sehr wichtig. Derzeit gibt es keine Möglichkeit, Nutzer zu sperren, und dies wird wahrscheinlich auch nicht eingeführt werden, da Blacklists zur Bildung von Cliquen führen und nichts einen Nutzer daran hindert, seine Adresse zu ändern, wenn er zurückkehren möchte. Um dieses Problem anzugehen, ist die meiner Meinung nach wirksamste Lösung, das Verhalten der Leute öffentlich anzusprechen und vor allem aufklärend zu wirken. Wenn man ihre Identität kennt, kann man ihnen eine höfliche und erklärende E-Mail schicken, die sie über die Funktionsweise des Mesh-Netzwerks aufklärt. Viele Nutzer missbrauchen das System, ohne es zu wissen, da sie nicht verstehen, dass eine einzige öffentliche Nachricht über Hunderte und bald Tausende von Repeatern gesendet wird!

Die Nutzung von Regionen beantwortet eine etwas andere Frage. Ich habe im obigen Beitrag einige Fragen und Antworten dazu dargelegt.

1 Like
7

Vielen Dank euch allen für die Rückmeldungen und die interessante Diskussion! Ich sehe schon, dass Regions und Flooding offenbar ein ziemlich heisses Thema sind. :slightly_smiling_face:

Ich möchte meinen ursprünglichen Punkt noch etwas präzisieren, da ich mich teilweise zu allgemein ausgedrückt habe:

Mir geht es nicht darum, Regions grundsätzlich infrage zu stellen oder möglichst viel unscoped Traffic durch das gesamte Mesh zu flooden. Mein konkreter Punkt ist die Pfadfindung (Path Discovery) für Direct Messages über Regionsgrenzen hinweg.

Wenn für einen Kontakt bereits ein funktionierender Pfad bekannt ist, ist das eine andere Situation. Problematisch wird es meines Erachtens dann, wenn noch kein gültiger Pfad zum Empfänger vorhanden ist und dieser mittels Flooding erst gefunden werden muss.

Wenn * auf den Repeatern nicht gefloodet wird und der Flood für die Path Discovery einen Region Scope trägt, braucht es entlang des möglichen Pfads eine entsprechende durchgängige Region-Konfiguration. Fehlt diese an einem notwendigen Repeater, endet die Path Discovery dort – obwohl grundsätzlich ein funktionierender Funkpfad zum Empfänger vorhanden wäre.

Gerade an Regions- bzw. Landesgrenzen halte ich das für relevant. Ein Benutzer in Deutschland möchte beispielsweise einem Benutzer in der Schweiz eine DM schicken. Die beiden können kaum wissen, über welche Repeater die Path Discovery laufen wird und welche Regions dort jeweils konfiguriert sind – und sollten dies meiner Meinung nach auch nicht wissen müssen.

Auch eine übergeordnete gemeinsame Region löst das Problem meines Erachtens nicht zuverlässig: Man kann in einem dezentralen Mesh nicht davon ausgehen, dass beispielsweise eu oder europe auf allen benötigten Repeatern einheitlich konfiguriert und für Flooding freigegeben ist.

Eventuell wäre deshalb folgende Lösung denkbar:

Könnte man die Path Discovery für Direct Messages anders behandeln als anderen Flood-Traffic?

Beispielsweise könnten Regions weiterhin zur Begrenzung von Channel- und anderem Flood-Traffic verwendet werden, während für die Path Discovery zu einem konkreten DM-Empfänger ein entsprechend begrenztes, regionsübergreifendes Flooding möglich bleibt.

Soweit ich die aktuelle Implementierung verstehe, lässt sich das mit den heutigen Region-/Flood-Einstellungen nicht getrennt konfigurieren und würde vermutlich eine Änderung in MeshCore erfordern.

Für mich ist das der eigentliche Kernpunkt: Regions sollen unnötiges Flooding begrenzen, aber die Pfadfindung zu einem grundsätzlich erreichbaren DM-Kontakt sollte möglichst nicht allein an einer Regionsgrenze bzw. an unterschiedlichen Region-Konfigurationen der dazwischenliegenden Repeater scheitern.

Falls ich die technische Funktionsweise der DM Path Discovery an dieser Stelle falsch verstehe, bin ich für eine Korrektur natürlich dankbar.

8

Hallo Michael

Mit dem Erscheinen der Firmware 1.10 im November 2025 wurde das Thema hier im Forum ausführlich behandelt. Hier der Link zu dieser Diskussion MeshCore Regions

Das Fazit aus dieser Diskussion ist in die Empfehlungen REGIONS | MeshCore Switzerland eingeflossen. Diesen Empfehlungen gilt es m.E. nichts hinzuzufügen oder davon wegzulassen.

Repeater leiten die Pakete, egal um welche Art der Payload es sich handelt, entsprechend ihrer Konfiguration und dem Header der Aussendung weiter. Wenn der Eigner eines Repeaters die Konfiguration des Gerätes nicht in den ‘Owner Infos’ hinterlegt hat, findest du mit dem Analyzer https://analyzer.letsmesh.net/packets oder mit einem anderen Analyse-Tool heraus, welchen Weg die Pakete nehmen.

Damit du mit deinem Freund ennet der Grenze regelmässig und in guter Qualität DM-Verkehr haben kannst, richtet ihr dafür am besten eine Insellösung ein oder bedient euch einem Messanger-Dienst. Siehe den Post von HB9DTZ weiter oben. Christoph schreibt auch, weshalb das sinnvoll ist.

L.G. Paul

2 Likes