MeshCore Regions

[HB9HVS]

Guten Tag CHIX und die ganze Regionen-Community

Herzlichen Dank für eure Arbeit. Die Anleitung von CHIX zu den Regionen ist eigentlich ausgezeichnet und grafisch sehr ansprechend. Und nun habe ich auch das Prinzip verstanden: Das Ganze funktioniert auf der Basis einer freiwilligen Einstellung der Verbreitungsregion im Companion, d.h. wir basieren damit auf Vernunft, Weitsicht, Netzkenntnis von MeshCore und Rücksichtnahme aller Nutzer. Ob das je funktionieren wird?

Was mir noch fehlt in einfacher Sprache:

• private Kanäle werden weiterhin über alle Repeater weitergeleitet (no scope)(stimmt das?)
• Meldungen von einem Contact direkt zum anderen sind sogenannte “no scope” und werden über alle Repeater weitergeleitet (stimmt das?)

Jedenfalls Danke für eure Arbeit und die genialen Entwicklungen. Ich werde nach und nach die Repeater updaten mit der neusten FW und die entsprechenden Regionen hinterlegen.

Bei bereits mehreren tausend Repeatern in Europa wäre die Erhöhung der Autoadvert-Zeit auf mindestens 24-48 Stunden dringend. (bei mir ca. 100 Adverts in 6 Std.).

Beste Grüsse - bin gespannt, wie es weitergeht.

Heinz

[HB9JAQ]

Guten Abend Heinz… . Ja, das ist richtig. Es geht lediglich um die Channels. Technisch wäre von der Companion-Firmware her ein “Regioning” auch bei Floods privater Meldungen möglich, aber das wird von den Apps (bis dato) nicht verwendet. Private Meldungen werden vermutlich so oder so nicht den Löwenanteil der Transmissionen ausmachen. Dann eher schon die Adverts. Wobei die Rechnung auch hier zeigt, dass 100 Adverts in 6h (6 x 3600s = 21600s) eigentlich noch gar nicht so viel sind. Wenn man pro Advert eine Sekunde Air-Time veranschlagt, so ergibt sich ein Quotient von 100/21600=0.0046, also ca. 0.5% Last… grins (ich weiss, ich weiss, das Repeating erhöht diesen Wert noch ein wenig, aber nicht immens). 73 aus Münsingen!

[Paul_Simmen]

Hab den Effekt der Abschaltung heute mit dem MeshCore Analyzer beobachtet.

[HB9HVS]

Salü Peter
Du hast natürlich recht, die Adverts der Repeater machen vom Datenvolumen her nicht viel aus. In der App “verstopfen” sie aber die “Discover List” erheblich, ohne mir umwerfende Informationen zu liefern. Natürlich könnte ich das Filter auf “Users” setzen. Das mache ich dann jeweils auch.

Was ich in der ganzen Diskussion noch nicht verstanden habe: Kann ich meinen Repeater auch so konfigurieren, dass er einen bestimmten Channel (z.B. “Public”) NICHT übermittelt?
LG Heinz

[HB9JAQ]

Meines Wissens existiert eine solche Filtermöglichkeit auf den Repeatern nicht. Du kannst einen unerwünschten Channel aber auf deinem Companion löschen (auch den “Public”…)

[Paul_Simmen]

Guten Tag Heinz

Es ist der Repeater, der die Pakete übermittelt. Der Companion schlüsselt diese auf und ordnet sie dem ‘Public’, den ‘Privaten’ oder den ‘#Hashtag’ - Kanälen zu. Einzig der ‘Public’ hat einen statischen, für alle Nutzer identischen Schlüssel. Der Schlüssel ist öffentlich: MeshCore/docs/faq.md at main · meshcore-dev/MeshCore · GitHub

Nachrichten, welche du im ‘Public’ sendest werden von allen Repeatern weitergeleitet und bei allen Empfängern im ‘Public’ angezeigt.

Nachrichten, welche du im ‘Privaten’ sendest werden von allen Repeatern weitergeleitet und aber nur bei denjenigen Empfängern angezeigt, welche über den Schlüssel des ‘Privaten’ verfügen.

Nachrichten, welche du im ‘#Hashtag’ sendest werden von allen Repeatern weitergeleitet und bei denjenigen Empfängern angezeigt, welche sich den Schlüssel des ‘#Hashtag’ gegeben haben.

Auf der Seite Companion vergibst du Kanäle und bestimmst die Region, in welche die Nachricht übertragen wird. Mehr ist ohne ‘Schrauben an der Firmware’ nicht möglich.

Direktnachrichten A↔B (dafür ist MeshCore eigentlich ausgelegt) werden unabhängig der Region oder eines Kanals durch die Repeater übertragen.

Lieber Gruss, Paul

P.S. Meine Antwort soll nicht belehrend sein! Aber ich denke, ausführliche Antworten helfen im Moment das Verständnis für die Funktion von MeshCore zu wecken.

[HB9HVS]

Danke Paul!

Deine Antwort ist nicht belehrend sondern lehrreich! Und manchmal hilft es mir, wenn ich die Dinge anders formuliert nochmals lesen kann. Nun habe ich bereits einen guten Überblick über die Technik der “Regions” und kann sie Schritt für Schritt anwenden. Zudem kann ich weitere Kollegen und Repeater-Betreiber dazu animieren, die Regions zu programmieren und anzuwenden. Das wäre ja dann eigentlich das Wichtigste .

LG Heinz (aus dem Nachbardorf)

[chix]

Wichtig ist auch, dass man versteht das die Companion Nodes alle Nachrichten von Flood Packages immer empfangen.

Heisst wenn man jetzt zum Beispiel einen Channel wie Public löscht, dann hat das null Einfluss auf den eigentlichen LoRa Funk-Verkehr. Deine Node entschlüsselt die Nachrichten nicht mehr und zeigt sie dir nicht mehr an, aber empfangen wird sie trotzdem.

Es macht also nichts wenn man viele Channels in seiner Liste hat, zumindest fürs Empfangen der Nachrichten

Was das Filtern auf Repeatern angeht wird eher nichts so schnell kommen. Soweit ich das verstehe ist die Philosophie bei den Entwicklern keine solchen Einschränkungen zu erlauben. MeshCore soll ein offenes Mesh für alle sein, sobald man irgendwelche Filter einbaut sind die auch leicht zu missbrauchen.

[Martin]

@chix

Wichtig ist auch, dass man versteht das die Companion Nodes alle Nachrichten von Flood Packages immer empfangen.

Aus meiner Sicht empfangen immer alle Nodes alle Nachrichten, die sie hören können.

• Companion Nodes reagieren nur auf abonnierte Channels und direkt an sie addressierte Meldungen
• Repeater leiten weiter, wenn es flood ist oder ihr Rep-prefix im Pfad
• Room Server sind auch repeater und nehmen Nachrichten für sie entgegen

(Ohne Berücksichtigung von regions und Companions, welche das repeater flag gesetzt haben).

Dies kann man auch in der App sehen: Tools → Rx Log

Die Hauptaussage stimmt aber: das reine Empfangen belastet das Netz nicht.

mfg Martin

[chix]

Komplett richtig, du hast das wesentlich besser formuliert als ich

[Bullit]

Die Repeater im Oberwallis und welche aktuell erreichbar sind (es gibt da einen Abtrünigen welchen wir umplatzieren müssen) wurden entsprechend den Empfehlungen eingestellt.

Wir haben diese mit ch, ch-de, ch-fr, ch-it (falls wir unsere Tessiner auch irgendwann erreichen) europe und vs konfiguriert. Die Wildcard bleibt natürlich ebenfalls auf „Flood allowed“. Auch weitere Repeater werden entsprechend der Empfehlung definiert dass wir „compliant“ zum restlichen Mesh sind

[Rolfy-HB9ODI]

Guten Morgen.

Die Regions werden fleißig benutzt und das Ganze funktioniert im Moment ziemlich gut. Es sind auch ein paar Micro-Regions entstanden, welche rege benutzt werden. Hier im Süden haben wir auch eine Telegram-Gruppe; in dieser Gruppe sind die Admins der wichtigen Repeater. Hier sprechen wir ab, was zu tun ist und was man lassen sollte.

Das funktioniert auch gut. Das Problem mit Kanal-Hash D9 (#test) ist immer wieder ein Thema, welches diskutiert wird. Ich habe es mit dem Erstellen einer speziellen FW versucht, hat aber nicht funktioniert. Gestern kam dann das Thema denyf* auf den Tisch. Wir testen das ein paar Tage lang, um zu sehen, was es bewirkt und welchen realen Einfluss es auf das Mesh hat. Keine Angst, das ist keine Dauerlösung.

Was aber jetzt komplett fehlt, ist die Verbindung in den Norden. Die Repeater Generoso und Transalp müssten mit einer Region programmiert werden, welche den N-S-Betrieb aufrechthält. Hat man dazu schon irgendwelche Ideen? Ich denke da an eine Makro-Region in der Art #eu oder Ähnliches. Was haltet Ihr davon?

Allen einen schönen Tag. Rolf

[chix]

@Rolfy-HB9ODI

denyf*

Mit denyf* funktionieren aber meinem Verständniss nach keine Direkt-Nachrichten mehr. Grundsätzlich heisst das ja, dass der Repeater keine Packages mehr weiter leitet die keiner Region zugeordnet sind.

Wenn man versucht eine direkte Nachricht zu senden und per Flood versucht wird ein Pfad zu finden, dann würde das nicht mehr klappen. Anscheinend sollen zu diesem Thema in 1.15.0 Verbesserungen kommen damit man die direkten Nachrichten auch eine Region zuordnen kann.

[Paul_Simmen]

Guten Tag Rolf
Schön, von dir zu lesen! Ich mache mir öfters mit Hilfe des Analyzers ein Bild der Situation auf dem Mesh. Selber betreibe ich den BRN Observer. Zusammen mit fri-bot-obs-1 decken wir die Region BRN recht gut ab. Die beiden Observer verfolgen den Verkehr via TRANSALP (Jungfraujoch).

Die Airtime wird sehr stark durch fehlerhafte Manipulation beim Senden (Region Scope wird nicht eingeschaltet) oder durch Ignorieren der technischen Gegebenheiten belastet.

In der Analyse begegnen mir sehr oft solche Bilder:

Viele Pakete sind mit 25 und mehr Hops unterwegs. Sie werden sehr oft im, der CH angrenzenden Raum, (z.B. bis Stuttgart) weiter geleitet.

Das hat nicht zuletzt damit zu tun, dass die Einstellung von Region-Scope bei den Absendern oft sehr locker gehandhabt wird.

Viele sind zudem der Ansicht, dass der Public-Kanal ohne Region-Scope zu betreiben sei.

Bittet man freundlich, doch den Region-Scope einzuschalten sieht es dann so aus:

Viel Airtime verbrauchen auch die Bots. Resp. deren Betreiber, welche nicht bereit sind, ihrem ‘Ding’ den Stecker zu ziehen oder es bestenfalls auf einem regionalen Kanal zu betreiben. Es gibt auch Amateurfunker, welche stündlich die Propagation auf MeshCore aussenden - unnötig, weil auf eingängigen Portalen jederzeit ersichtlich.
Aber das alles gehört wohl in die Kategorie: “Man macht es, weil irgend jemand mal ein Skript dafür auf GitHub veröffentlicht hat und man zeigen will: Ich kann das auch”.

Mit denyf * ist es nicht mehr möglich direkte Nachrichten zu übertragen. * sollte also nicht abgeschaltet werden!

Ich mache mir grosse Sorgen um das Netz in der Schweiz, nicht zuletzt um die TRANSALP-Verbindung. Darum setze mich für die Anwendung von Region-Scope und die Vermeidung von unnützem Verkehr ein.

Weil es so ‘gäbig geht’ wird MeshCore von vielen einfach genutzt. Weil der Einstieg niederschwellig ist und viele nicht bereit, oder in der Lage sind, sich ins Thema einzuarbeiten und die minimalen technischen Vorgaben zu beachten kommt es zu den bereits messbaren Engpässen im Netzbetrieb.

Ich glaube, dass mit offensiver Information schon viel erreicht werden kann. Nicht zuletzt wird auch hier der stete Tropfen den Stein höhlen.

Trotzdem wird es unumgänglich sein, auf der technischen Ebene (Betriebssystem) und mit Anpassungen von Repeater-Standorten an das Gelände (z.B. Ausnutzen von Funkschatten zur Verminderung des störenden Verkehrs) Korrekturen zu machen.

Ich denke Christoph (HB9DTZ) und du werdet (z.B. mit mehreren vorgelagerten Repeatern - analog Aeschiried) Wege finden um den Verkehr via TRANSALP zu regulieren. Zudem sind von den Entwicklern von MeshCore ja bereits Schritte zur Begrenzung des Verkehrs zu sehen.

Für Weitverbindungen gibt es in Deutschland und auch hierzulande die Idee von #europe

Jede noch so sinnvolle und durchdachte Massnahme zur Beschränkung der Ausbreitung wird aber nichts, oder nur wenig bringen, solange sie (trotz besserem Wissen) nicht angewendet wird.

Wir bleiben dran!

Lieber Gruss in den Tessin

Paul

[HB9HVS]

Danke Paul für Deine klaren Worte. Ich bin schon etwas schockiert, wie gewisse Nutzer reagieren auf die Bitte, doch die Regionen zu nutzen.

Zur Info: Der Repeater Aeschiried läuft noch auf einer älteren FW ohne Regionen. Ich werde den Repeater so bald wie möglich auswechseln, dann wären wir dort auch auf dem neusten Stand mit der Regionen-Option.
LG Heinz, HB9HVS

[Paul_Simmen]

Hallo Rolf

WoW… du hast HB9ODI_Sentinel wieder in Betrieb genommen! Vielen Dank!

Damit haben wir nun das ‘CH-Puzzle’ fast komplett und decken mit den derzeit 7 Observern fast alle IATA-Regionen der CH ab! Es fehlen nur noch die IATA-Regionen Basel (BSL) und das Graubünden (SMV) mit einem eigenen Observer.

[ssozonoff]

Hello,

I fully agree with you Paul, something to keep in mind is that several repeaters are still difficult to access with the winter conditions so as Heinz mentioned, still running older firmware, I am sure that as the summer approaches these will get updated and the use of regions will improve.

I run the GVA.observer and I am actively working on growing the network around the lake of Geneva and Valais area with more deployments planned in the coming months.

I agree that it will be both challenging and interesting to keep the Mesh “under control”! Two days ago there was an interesting case in the Netherlands of a node “accidentally” spamming their network. Here is the post mortem, so it happens very easily.

Small post-mortem about the E9-mystery that heavily impacted the Dutch mesh for the last 3 days. Monday, March 16 around 14:00 there was a sudden surge in TXT_MSG traffic. This is usually between 5%-20% of total packets, but now this reached a peak of 85% at one point. An investigation using observer data from letsmesh.net quickly showed there was a single node (short ID “E9”) sending messages in rapid succession, one packet every ~5 seconds. By looking at which repeaters tended to hear these messages first we figured out the approximate area where this traffic originated. Unfortunately there was no known node with ID E9 in that area, indicating it was a companion that had never broadcast an advert. We were kind of stuck for 2 days, and the mesh performance was significantly degraded during that time. Finally, tonight we managed to get in touch with the admin of one of the repeaters close to the mystery E9-node. On a hunch he contacted one of his local mesh-friends, who realized he had a HomeAssistant plugin that was constantly restarting (details are still sketchy). Killing that plugin immediately resolved the issue, bringing TXT_MSG traffic back to normal a level.

The good news is that it raises awareness and stimulates discussions amongst developers around better control and diagnostic tools. I believe the multi-byte path hashes will help in the diagnostics department.

Kind regards,

Serge

[HB9DTZ]

Es gibt nebst Aeschiried noch die Falkenfluh und die Bütschelegg. Alle drei sind auf ca. 1000m a.s.l. und haben gute Sicht auf Transalp N1. HB9JAQ hat sich um die Regioneneinstellungen der Bütschelegg und der Falkenfluh gekümmert, für Transalp müssen wir das noch nachholen, ich war da wegen der, von Rolf genannten Probleme ganz am Anfang der “Regions” Diskussion etwas zurückhaltend. Mit etwas Glück und abhängig vom Wetter werde ich nach Ostern zu den Transalp Repeatern fliegen- und dort die Upgrades vornehmen können.