Why blocking flood * is bad, and should be avoided

General
1

LOCKING FLOOD ON * FUNDAMENTALLY BREAKS THE CORE OF MESHCORE.

It destroys the ability to reliably contact people via DM. It BALKANIZES the entire mesh, segmenting everything into isolated little bubbles until the network becomes basically unusable.

Not that long ago, Liam Cottle specifically mentioned on Discord that blocking flood * was a bad idea. They understand the challenges of the growing user base but blocking flood * literally breaks the core of what Meshcore is supposed to be and how it fondamentaly works.

This should never have been an option available to regular users, or even an option at all in most cases. Because this is exactly what happens when you hand “control/block” power to some people: they use it, promote it, don’t understand it, they decide for everyone else, and the mesh suffers.

It’s not an attack on anyone, but you understand what I mean. You experienced it in many other area in life. You know how some people can be, you know that even the most technical person can not understand basic things, or the total opposite.

Blocking flood * is the nuclear option for a problem that can (and should) be mitigated in many other ways FIRST, ways that existed even before firmware 1.16 too. But I never seen anyone implemented it, promoting it, talk about it.

It doesn’t take long to read what basic settings do, and understand how beneficial some of them can be, before going nuclear and blocking everything.

People act like Meshcore is on the verge of collapse when Meshtastic ran for 5+ years with thousands of users, useless telemetry everywhere, nodes never updated and poorly configured, and all kinds of weird stuff going on, and it still worked great.

People gradually moved to MediumFast and some big regions even went to ShortTurbo. Meshcore is far more optimized than that. It doesn’t blast telemetry constantly every 5 minutes from every node.

We are nowhere near that level of overload.

Radio is radio. Lora mesh networks lose signals like anything radio stuff, drop messages, and see activity spikes, do down, etc… That’s how it works. Almost nobody pushing hard for flood * blocks even has their repeaters properly configured. Many still run the default 50% duty cycle.

I see it constantly with msg on Public (and other #, chtest, switzerland) 20-30 hops. Looking at the path, oh, what’s there. Major repeaters with their 64 hops max flood.

You can limit flood.max on a repeater, and you have been able to for a long time. Very few people actually do it, even though only a small minority who RTFM bother tuning settings. You can drop flood.max as low as you want. No more 64 hops default, why not set a well-placed repeater to just 11 or 14 hops?

You realize how you can optimize the mesh without compromising it completely with JUST that!? So please do that and remove your blocking.

You can adjust txdelay too, especially on mountain or well positioned repeaters. Make them wait longer so other repeaters can handle the packet first.

NOBODY changes these things.

Same with Companion: why isn’t there a strong recommendation to set it to 3 bytes? It doesn’t break anything meaningful (except compatibility with very old firmware <1.14.1) and drops you from 64 hops down to 21 without touching anything else when sending a message.

Imagine if people did that… and still be able to talk to people in other countries without any problems, or being able to travel and.

Why have an open source tool like that when you can have a roaming plan, and deal with big corps. At least it works, you’re tracked, but you

That’s how people break good intentions and good projects. You’re in an emergeny setting, you tried everything else and your last hop is your little mesh companion node

BUT YOU CAN’T CONTACT ANYONE because repeater around you block flood, and not all have the exact same region added to the repeaters! - Can you see how this whole idea is the most stupid thing ever ?

All these settings exist to optimize the mesh while keeping its core functionality intact: the ability to transmit a message to anyone, without artificial barriers.

I (and many, many others, most people) want to talk to everyone. When I travel to France, Germany, or the German-speaking part of Switzerland, I want to DM friends and participate in public channels without being artificially blocked. I want to be able to send a message in different channels to different people, send private message, as intended.

but it’s all broken now, it’s such a mess and a shame! I hate that, and you should too!

Do you realize how stupid this is? How badly it breaks the whole reason for an open-source mesh network to exist?

READ THE OFFICIAL DOCUMENTATION. Open flood back up on *, and limit it properly if needed. Firmware 1.16 introduced even better tools to keep flood working but controlled: Release v1.16.0 - MeshCore Blog

It was always possible with flood.max (USE IT), but now there are more granular options like flood.max.unscoped, flood.max.advert, etc.

Other useful settings:

  • int.thresh >>>> configures RSSI-based listen-before-talk to prevent collisions.
  • loop.detect >>>>rejects duplicate repeater ID hashes to stop broadcast storms.
  • flood.max (and the specific variants) —>>>>repeater-level hop limits for inbound flood packets.

Region scope and flood * blocks should be extreme last-resort measures only, not default recommendations.

Because people don’t follow (or don’t read) the recommendations, we’ve effectively balkanized the mesh across France, Germany, Switzerland, Italy, and beyond. Messages get sent, some people reply, but nobody else sees it, or some do, then you respond, but they won’t see it.

Private DMs straight-up fail. When major French repeaters changed settings, I couldn’t even talk to some friends anymore. Friends I recommended Meshcore to : see, it’s better than Meshtastic… well, it’s not with this only little option that now people push! That’s how stupid this push has been.

The whole point of Meshcore is flexibility, being able to move around and still talk to people, whether you’re in Germany, France, or Switzerland. Not trapping everyone in their little local bubble.

So please: change these recommendations. Stop following the overly restrictive French/German (And other weird stuff you read online) approaches. Open flood * back up. Limit hops and tune settings instead.

Don’t cry that it’s harder to remotely connect to your repeater sometimes. That’s the nature of radio… It’s meant to be used, not babysat with constant neighbor lists and stats. I don’t like to not being able to look into my repeaters in 1 sec either, but I understand that talking to people, messages, are what the mesh exist for.

I have repeaters up myself. Flood on * will never be blocked on mine, because I understand how the core of Meshcore work, and you should too. I limited flood.max to 14 (we could even go as low as 7 like classic Meshtastic), knowing Meshcore is vastly more efficient and doesn’t spam stupid telemetry. I tweaked the **int.thresh

Guess what, my repeaters don’t always rebroadcast the second they receive a packet, because I tweaked the settings so it only rebroadcast if it needs too… I effectively help to reduce the load on the mesh, while keeping it working as intended. And you should do that too.**

Restore flood on *. Tune your stuff (I gave you the settings you can look for). Don’t break the mesh.

Again, reducing the flood.max, changing your companion to 3byte (21 hops for your messages), you effectively reduce the congestion without breaking the core of Meshcore!

Thank you

Ich spreche kein Deutsch, aber hier eine Google-Ăśbersetzung meines gesamten Beitrags (ich weiĂź nicht, ob er gut ist, ich habe viel Zeit mit meinem ursprĂĽnglichen Beitrag verbracht) :

FLOOD AUF * BLOCKIEREN ZERSTĂ–RT DEN KERN VON MESHCORE

Es zerstört die Möglichkeit, Menschen zuverlässig per DM zu erreichen.
Es balkanisiert das gesamte Mesh, unterteilt alles in isolierte kleine Blasen, bis das Netzwerk praktisch unbrauchbar wird.

Noch nicht allzu lange her hat Liam Cottle auf Discord explizit gesagt, dass das Blockieren von Flood * eine schlechte Idee sei. Sie verstehen die Herausforderungen durch die wachsende Nutzerbasis, aber Flood * zu blockieren bricht buchstäblich den Kern dessen, was Meshcore sein soll und wie es grundlegend funktioniert.

Das hätte niemals eine Option für normale Nutzer sein dürfen – und in den meisten Fällen nicht einmal eine Option überhaupt. Genau das passiert nämlich, wenn man einigen Leuten „Kontroll-/Blockier-Macht“ in die Hand gibt: Sie nutzen sie, propagieren sie, verstehen sie nicht, entscheiden für alle anderen – und das Mesh leidet darunter.

Es ist kein Angriff auf irgendjemanden, aber du verstehst, was ich meine. Du hast das in vielen anderen Bereichen des Lebens schon erlebt. Du weißt, wie manche Leute sein können. Du weißt, dass selbst die technisch versiertesten Personen manchmal grundlegende Dinge nicht verstehen – oder genau das Gegenteil.

Flood * blockieren ist die nukleare Option

für ein Problem, das auf viele andere Weisen zuerst gemildert werden kann (und sollte) – Wege, die es schon vor Firmware 1.16 gab. Aber ich habe noch nie gesehen, dass jemand diese wirklich umgesetzt, beworben oder auch nur darüber gesprochen hat.

Es dauert nicht lange, zu lesen, was die grundlegenden Einstellungen bewirken und zu verstehen, wie nützlich sie sein können, bevor man alles nuklear blockiert.

Die Leute tun so, als stünde Meshcore kurz vor dem Zusammenbruch – dabei lief Meshtastic über 5+ Jahre mit Tausenden von Nutzern, nutzloser Telemetrie überall, nie aktualisierten und schlecht konfigurierten Nodes und allen möglichen merkwürdigen Dingen – und es hat trotzdem hervorragend funktioniert.

Die Leute sind nach und nach zu MediumFast gewechselt, manche große Regionen sogar zu ShortTurbo. Meshcore ist deutlich optimierter als das. Es blast nicht ständig alle 5 Minuten Telemetrie von jedem Node.

Wir sind nirgendwo in der Nähe dieses Überlastungslevels.

Radio ist Radio.

LoRa-Mesh-Netzwerke verlieren Signale wie alles andere im Funkbereich, Nachrichten gehen verloren, es gibt Aktivitätsspitzen, Ausfälle usw. So funktioniert das eben.

Fast niemand, der massiv für Flood-*-Blocks plädiert, hat seine Repeater überhaupt richtig konfiguriert. Viele laufen immer noch mit dem Standard-50%-Duty-Cycle.

Ich sehe es ständig bei Nachrichten auf Public (und anderen Kanälen wie chtest, switzerland) mit 20–30 Hops. Schaue ich mir den Pfad an: Ach, was haben wir denn da – große Repeater mit 64 Hops max Flood.

Man kann flood.max auf einem Repeater limitieren – und das geht schon sehr lange. Nur sehr wenige machen es tatsächlich.

Du kannst flood.max so niedrig setzen, wie du willst. Warum setzt man einen gut platzierten Repeater nicht einfach auf 11 oder 14 Hops?

Du kannst auch txdelay anpassen, besonders bei Berg- oder gut positionierten Repeatern.

NIEMAND macht diese Ă„nderungen.

Companion auf 3 Bytes stellen

Warum gibt es keine starke Empfehlung, Companion auf 3 Bytes zu stellen? Es reduziert von 64 Hops auf 21 Hops, ohne sonst etwas anzufassen.

Stell dir vor, alle würden das machen… und trotzdem mit Leuten in anderen Ländern problemlos sprechen können.

All diese Einstellungen existieren, um das Mesh zu optimieren, ohne seine Kernfunktionalität zu zerstören:
die Fähigkeit, eine Nachricht an jeden zu senden, ohne künstliche Barrieren.

Ich (und sehr, sehr viele andere) möchte mit allen sprechen können. Wenn ich nach Frankreich, Deutschland oder in die Deutschschweiz reise, möchte ich mit Freunden DMs schreiben und in öffentlichen Kanälen mitmachen – ohne künstlich blockiert zu werden.

Aber jetzt ist alles kaputt. Es ist ein einziges Chaos und eine Schande.

Lest die offizielle Dokumentation.
Macht Flood auf * wieder auf und limitiert es bei Bedarf richtig.

Firmware 1.16 hat sogar noch bessere Tools gebracht:

  • flood.max (und Varianten wie flood.max.unscoped, flood.max.advert etc.)
  • int.thresh → RSSI-basiertes Listen-Before-Talk
  • loop.detect → Verhindert Broadcast-StĂĽrme

Region-Scope und Flood-*-Blocks sollten absolute Notfallmaßnahmen sein – keine Standard-Empfehlung.

Stellt Flood auf * wieder her.
Optimiert eure Einstellungen statt den Kern des Netzwerks zu zerstören.

Reduziert flood.max + Companion auf 3 Bytes = deutlich weniger Last, ohne das Mesh kaputt zu machen.

Danke.

3 Likes
2

Thank you for taking the time to write such a detailed explanation.

I actually agree with the core point you are making: the purpose of MeshCore is to allow communication across the mesh, and blocking flood * can easily undermine that goal if it becomes a common practice rather than a last-resort measure.

What I would like to understand better is how you would configure different types of nodes in practice.

You mention several times that there are much better ways to optimize the mesh than blocking flood *, such as reducing flood.max, adjusting txdelay, tuning int.thresh, enabling loop.detect, and reducing Companion IDs to 3 bytes.

Could you provide some concrete examples of how you think different node types should be configured?

High-altitude mountain repeaters

For example, imagine a major mountain-top repeater with exceptional coverage and visibility over a very large area, potentially crossing regions and even national borders.

How would you configure:

  • flood.max

  • txdelay

  • int.thresh

  • duty cycle

  • Companion settings

  • region scope

Would you intentionally keep hop limits relatively low (e.g. 7–14 hops) despite the large coverage area?

Would you increase txdelay significantly so that local repeaters closer to users get the first opportunity to forward packets before the mountain repeater retransmits?

Rural repeaters

What about repeaters located in rural areas, villages, or small towns?

These nodes often provide local coverage but may also serve as important links between larger backbone nodes.

Would you configure them differently from mountain repeaters?

Should they use lower or higher flood.max values?

Should they rebroadcast more aggressively or less aggressively?

Urban repeaters

Dense urban environments present a completely different challenge because there may be many nodes hearing each other simultaneously.

How would you tune repeaters in cities?

Would you rely more heavily on int.thresh and longer delays to reduce unnecessary retransmissions?

Would you recommend different hop limits compared to mountain-top infrastructure?

Companion nodes

You also mentioned Companion IDs several times.

From your perspective, should Companion nodes generally be configured for 3-byte IDs by default?

Do you see any real downside to this today, apart from compatibility with very old firmware versions?

Would you recommend this for all users or only for people who frequently travel and communicate across larger regions?

A practical recommendation

If you were writing a “best practices” guide today, what would your recommended settings be for:

  1. A high-altitude long-range backbone repeater.

  2. A rural community repeater.

  3. An urban repeater.

  4. A typical portable Companion node.

I think many people would find this extremely useful because it would move the discussion away from simply saying “don’t block flood *” and toward showing exactly how the mesh can be optimized while still preserving the ability to communicate across regions and countries.

In other words, if blocking flood * is the wrong solution, what does the right solution look like in terms of actual settings and deployment strategies?

Best regards

swissAlisha

1 Like
3

Hi,
I’ll tweak this response later when I can, with a longer response, for those who want to experiment with these settings

But I’ll just like to respond to :

if blocking flood * is the wrong solution

It is a valid solution, and it’s not inherently wrong but in very specific contexts, for example, when running a dedicated mesh network for very particular use cases.

That said in a more general extreme scenario like as the mesh becoming completely unusable (even meshtastic despite with flood of useless telemetry, traceroute, etc every second, still functions well) blocking the flood would then be the right solution.

But this would only be a last resort after everything else has failed and there are no more tweaks left to mitigate the issue which I don’t see happening anyway.

Yeah there’s no need, IMO, to stay on 1byte it doesn’t really do any good.

I don’t think the critical repeaters aren’t already updated to 1.14.1, 1.15, or 1.16 anyway.

2byte is better, and 3byte would naturally drop the max hops from 64 down to 21. I haven’t seen any real drawbacks in everyday use

With more than 1byte, you can actually see the proper list of hops in the paths without duplicates too.

21 hops is still more than enough to go very far (or reach regions that are poorly connected, even “close” to us. 15+ hops to go to Chur is very common).

Plus, the tighter the mesh gets with repeaters, the fewer hops you actually need to reach people without even having to touch any repeaters <<< if everyone would change their companion settings with that, without even touching at the default setting of the repeaters, even those with max flood at the “max” 64, it would naturally decrease the load on the whole mesh (this is one of the first reason this flood blocking stuff pisses me off lol, because every single person who suggest this, doesn’t even use 2byte, let alone 3byte with their companion)

I’ll reply to the rest later when I have a bit more time

1 Like
4

Ich verstehe den Ansatz, das Netz nicht überlasten zu wollen, aber wie oben erwähnt, ist das generelle Deaktivieren von Flood* der falsche Ansatz und macht eigentlich zunichte, wofür ein Mesh-Netzwerk steht. Da das Ganze für alle immer noch recht "neu" ist, haben sich einige Einstellungen, die der Überlastung entgegenwirken können, noch nicht überall herumgesprochen. Eventuell macht es auch Sinn, die empfohlenen Einstellungen der Meshcore.ch-Seite zu ergänzen oder gegebenenfalls etwas strikter zu empfehlen.“ So oder so Tolles Forum, weiter so!

5

Ich bin aktuell nicht so extrem aktiv wie davor, ABER! , seit wann hat das Blockieren von * irgendwelche Auswirkungen auf PNs?

Soweit ich weiss nämlich GAR KEINE. Da stellt sich mir die Frage, ob ich was grösseres verpasst habe, oder ob der Thread-Ersteller nicht ganz wissend darüber ist, dass das blocken der *-Wildcard ausschliesslich Flood-Nachrichten betrifft und nie PNs betroffen hat.

Man möge mich bitte korrigieren wenn ich falsch bin!

1 Like
6

Nimm solche Posts nicht allzu ernst… Die beiden (Mesh.Ch und swissAlisha) haben sich heute Nachmittag auf dem Blog eingeloggt und wollen hier wohl etwas Spass haben…!
Lieber Gruss, Paul

5 Likes
7

Danke fĂĽr den tollen Artikel!

8

Hallo Paul

Ob ich seit Montag 15. Juni 2026 dabei bin oder seit zehn Jahren, sollte fĂĽr die Diskussion eigentlich keine Rolle spielen. Entscheidend sind die vorgebrachten Argumente und die Fakten.

Ich habe den Beitrag von Mesh.Ch aufmerksam gelesen und meine Gedanken dazu geaeussert. Dabei habe ich auch einige Gegenfragen zu den dort aufgestellten Thesen gestellt, weil ich an einer sachlichen Diskussion auf Faktenbasis interessiert bin.

Da Englisch nicht meine Muttersprache ist und meine Sprachkenntnisse nicht perfekt sind, kann es durchaus sein, dass einzelne Formulierungen missverständlich oder nicht optimal gewählt waren. Falls das der Fall ist, darfst du gerne nachfragen.

Was ich jedoch schade finde: Statt auf meine Argumente oder Fragen einzugehen, wird nun meine kurze Mitgliedschaft thematisiert und unterstellt, ich wolle hier nur „Spass haben“. Das traegt leider nichts zur eigentlichen Diskussion bei.

Wenn meine Aussagen sachlich falsch sind, bin ich jederzeit bereit, diese anhand von Fakten zu diskutieren und gegebenenfalls zu korrigieren. Genau dafuer sind Diskussionen ja da.

Freundliche Gruesse

Alisha

4 Likes
9

Dass die Annahme faktisch falsch ist, habe ich ja durch meinen kurzen Beitrag oben bereits klargestellt. Was sollte man diesbezüglich noch sagen? Es hat auf PNs keinen Einfluss. Also kein Grund für die unnötigen Sorgen.

1 Like
10

Seit wann ein User auf der Webseite ist, spielt meiner Meinung nach keine Rolle. Ich glaube auch nicht, das man einfach ein wenig Spass haben möchte. Wäre dem so, würde man nicht so grosse Texte verfassen. Ich habe es auch nur überflogen. Bei meinen Repeatern an der deutschen Grenze ist die Region * aktiviert und ehrlich gesagt, sind mir da die Vorgaben egal. Ich betreibe letztendlich den Repeater und ich entscheide was ich damit mache. Persönlich bin ich der Meinung, dass es keine Rolle spielt ob die Nachrichten nun über “ch” oder “europe” versendet werden. Das Ziel der Deaktivierung von * war ja, dass man das System nicht überlasten will. Wenn nun aber alle Repeater die Region “europe” aktiviert haben und die Nutzer alles über diese Region versenden, hebelt es so oder so gleich alles aus, was man erreichen wollte und am Schluss steht man wieder auf Feld 1. Stört es das Mesh wirklich, wird mit Sicherheit eine entsprechende Firmware kommen, um dies zu unterbinden. Passiert dies nicht, lässt man es ja auch bewusst zu. Im weiteren wird man so in der Schweiz ein Inselsystem betreiben, indem die Region * deaktiviert wird. Das ist aus meiner Sicht kontraproduktiv. Auf der anderen Seite sollte man meiner Meinung nach nicht nur zwischen hohen Repeatern auf den Bergen und jenen in den Tälern unterscheiden, sondern grundlegend auch zwischen Stadt und Land. Meiner Meinung nach kann man in den Städten getrost auf 3 byte gehen, da dort die Repeater Dichte massiv höher ist, als auf dem Land. Letztendlich ist es meiner Meinung nach zum heutigen Zeitpunkt viel zu früh, um solche grundlegenden Änderungen zu machen. Schliesslich weiss man noch nicht, wohin uns Meshcore führen wird. Alleine in den letzten 30 Tagen, kamen 12’000 Geräte dazu, was klar in der Map festgehalten ist. Meiner Meinung nach sollte man abwarten und Tee trinken und die Leute in anderem erziehen, wie das man nicht jeden Tag sinnlos “Guten Tag”, “Gute Nacht”, “en guete”, etc. schreibt. Sorry, aber wen interessiert der Müll, hat man jetzt ernsthaft das Gefühl, das irgendjemand solche Texte interessieren oder nützen?

2 Likes
11

Listen. Help others. Give feedback. Ask questions. Be friendly. The better approach in a forum in my opinion.

My 5c

6 Likes
12

Wenn jeder Nutzer die default Region gesetzt hat wird Diese für die DM Nachrichten verwendet unabhängig ob unscoped flood aktiv oder deaktiviert ist. Ich habe bei meinem Repeater über das es CLI

flood.max.unscoped 3

und in den Regionen Einstellungen " Pakete ohne Regionzurdnung " flood erlaubt

Sonnige GrĂĽsse, HE9LEC

2 Likes
13

Welcome to the community, @Mesh.Ch. If I understand your post correctly, you want to say that

  1. disabling flood on * “destroys the ability to reliably contact people via DM”.
  2. Better use flood.max(.unscoped/.advert), init.thresh, loop.detect and txdelay to control the routing of unscoped packages instead.
  3. Use 3-byte default path hash size.

Could you provide some detail on 1. how disabling flood on * kills DMs and could you attach a screenshot of Liam Cottle’s message on discord, as I did not find it.

I am looking forward to your best-practice values for 2.
Why do you suggest 3. 3-byte default path hash sizes? Edit: To reduce max hops to 32, I guess.

BTW: I would enjoy your input much more, if you would not SHOUT and refrain from accusations and generalizations. Thank you.

14

Hallo Sharp,

​darüber, ob Mesh.ch in seinem Beitrag den Ton nicht ganz getroffen hat, lässt sich streiten – aber viele seiner Beobachtungen und Ansätze, die Problematik des Netzes anzugehen, sind meiner Meinung nach genau richtig!

​Die DM-Nachrichten nutzen die default.region des Companions. Ist diese nicht eingestellt – was bei neuen Nutzern oft der Fall sein kann –, kommt die unscoped Region zum Zug. Wenn dann das Flooding von unscoped Nachrichten aktiviert ist, gehen keine Nachrichten raus. Also „unscoped flood“ aktivieren und mit der flood.max.unscoped-Funktion ein wenig einschränken.

​Ich selber habe heute mit den Einstellungen an meinem Repeater (flood.max 4, Region ch-de, flood.max.unscoped 3, tx 16) eine Verbindung bis nach Ulm an der Donau gehabt. Die Hops zu beschränken, wirkt sich nicht auf die Reichweite aus. Im Public-Kanal kommen Nachrichten mit 16 Hops rein, und ich meine, meine Antworten kommen dort an, obwohl mein Repeater auf 4 Hops eingeschränkt ist. Mein Handgerät sendet gerade mal mit 5 dB aus der Wohnung zum Repeater draussen auf dem Balkon.

​Wir sollten hier alle offen und neugierig auf neuen Input sein. Auch wenn jemand ganz neu in der Community ist, sagt das absolut nichts über dessen Wissen und Hintergrund aus.

​Gruss, HE9LEC

2 Likes
15

Hallo @HE9LEC

So möchte ich meinen Beitrag auch verstanden wissen. Wie ich geschrieben habe, freue ich mich auf den Vorschlag bezüglich genauer Einstellungen.
Bezüglich unscoped Nachrichten von neuen Nutzern: Hier stellt sich die Frage, ob man möchte, dass sich die Nutzer vorgängig etwas informieren und dann einen sinnvollen Scope einstellen, oder ob man sie von Anfang an auf dem ganzen Netz funken lässt… Da habe ich noch keine abschliessende Meinung dazu.

16

Hallo Sharp,

​freut mich sehr, dass wir da auf derselben Wellenlänge sind!

​Ich schlage vor, wir warten jetzt erst einmal die konkreten Einstellungs-Vorschläge von Mesh.ch ab. Sobald er seine Liste postet, können wir seine Werte hier im Detail analysieren und schauen, was umsetzbar ist und dem Netz einen Mehrwert bringt und was nicht.

​Gruss, HE9LEC

3 Likes
17

Hallo HE9LEC

Das war auch mein Gedanke wo ich auf English gestellt habe. Darum halte ich mich aktuell zurĂĽck mit schreiben.

Jm2c

Alisha

2 Likes
18

Deutsche Version " siehe unten "

Hi Mesh.ch,

​First of all, welcome to our community! Thanks for your detailed post and input.

​I see it very similarly when it comes to the core issue: if we completely shut down flood *, we unnecessarily break the network into isolated islands. This creates real issues, especially with DMs. On the first connection, DMs use the companion’s default.region. If new users haven’t set this up yet, it automatically runs via the unscoped flood. If you block that completely on the repeaters, no DM gets through at all. That’s why it’s much smarter to keep the path open and simply limit it using flood.max.unscoped.

​MeshCore has this exact built-in intelligence to look for the best path flexibly and independently. If we slice up the radio network with too many hard filters and scopes, we strip the protocol of this strength and the chance to optimize itself.

​This also aligns perfectly with my practical tests: my repeater is currently running with flood.max 4 and flood.max.unscoped 3 at 16 dBm. With this setup, I had a flawless connection all the way to Ulm an der Donau today! It just shows that we don’t need to cut down our physical range at all—disciplining and limiting the hops is more than enough without having to press the red button.

​Sharp mentioned above that he’s open to specific configuration suggestions. Feel free to drop your optimized values here so we can all look at them together in a calm and objective way. Great to have you on board bringing a fresh perspective!

​Cheers, HE9LEC

Hallo Mesh.ch,

​erst einmal willkommen bei uns in der Community! Danke für deinen ausführlichen Beitrag und den Input.

​Ich sehe das inhaltlich ganz ähnlich: Wenn wir flood * komplett dichtmachen, zerlegen wir das Netz unnötig in isolierte Inseln. Das führt vor allem bei den DMs zu echten Problemen. Bei der ersten Verbindung nutzen DMs ja die default.region des Companions. Wenn neue User diese noch gar nicht eingerichtet haben, läuft das automatisch über den unscoped flood. Blockiert man den auf den Repeatern komplett, kommt keine DM mehr durch. Deshalb ist es so viel geschickter, den Pfad offen zu lassen und einfach über flood.max.unscoped einzugrenzen.

​MeshCore hat ja genau diese eingebaute Intelligenz, sich flexibel und eigenständig den besten Weg zu suchen. Wenn wir das Funknetz mit zu vielen harten Filtern und Scopes aufteilen, nehmen wir dem Protokoll diese Stärke und die Chance, sich selbst zu optimieren.

​Das deckt sich auch mit meinen praktischen Tests: Mein Repeater läuft aktuell mit flood.max 4 und flood.max.unscoped 3 bei 16 dBm. Damit hatte ich heute eine einwandfreie Verbindung bis nach Ulm an der Donau! Das zeigt einfach, dass wir die Reichweite gar nicht beschneiden müssen – die Hops diszipliniert zu begrenzen reicht völlig aus, ohne gleich den roten Knopf zu drücken.

​Sharp ist ja oben im Thread auch offen für konkrete Vorschläge. Stell deine optimierten Werte am besten einfach mal hier rein, dann können wir uns das alle zusammen ganz unaufgeregt und sachlich anschauen. Schön, dass du hier frischen Wind reinbringst!

​Gruss, HE9LEC

2 Likes
19

Welcome to the community!

First off, a few general notations:

  • The settings on www.meshcore.ch are recommendations, no rules. Everybody can do whatever he/she wants apart from the legal restrictions here in Switzerland.
  • All these recommendations are based on discussions here in the community, it’s not a few people dictating anything.
  • MeshCore is changing quickly, the software itself but also the actual mesh. We have to continue to discuss the settings here, I expect them to change many more times since different measures become an option with new releases.

Just a quick note: I would really love to see you revise your initial post a bit, coming here and then shouting out loud that basically nobody here has an understanding of how MeshCore works and calling things stupid in capital and bold letters is extremely offending. I honestly believe that if that was formulated as a proposal instead of an attack, many more people would join the discussion here.

This is just my opinion, but these were the main reasons for the current recommendation to deny * flood packages:

  • Avoid that the mesh keeps using airtime for the thousands of channel flood messages which are completely irrelevant here in Switzerland. The direct messages are not the issue, its the channel messages.
  • Educate users to start using regions. If * is always an option, the assumption is that most users will simply never use any regions since it always works just fine without touching them.

I read your full post multiple times and I understand your thoughts, but somehow you do not provide specific settings, you call out options, but you do not explain how these configurations achieve the same results. Our mountain repeaters have a huge ranges, MeshCore can cross all of Switzerland within less than 4 hops from North to South. If we would want efficiently prevent flood messages from traveling through the complete mesh, we would need to set something like flood.max<=3 and flood.max.unscoped<=3, or maybe even less. Anything higher than that would mean that the messages already travel through the whole Swiss Mesh with every single repeater repeating all of these packages.

If we have to go that low, the result becomes almost identical to disabling flood completely, or not? I really have a conflict here, I’d love to let direct messages travel as far as somehow possible, but the channel flood messages need to be stopped somewhere.

Don’t get me wrong, while I might not agree on everything you wrote, I think this is an important discussion to have so that we can come to a conclusion as a community. I just don’t fully understand yet how to achieve the same target with the settings you propose, namely preventing the mesh to get overloaded by these thousands of channel flood messages.

Looking forward to your further thoughts :clinking_beer_mugs:

14 Likes
20

So if I get that right, setting flood.max.unscoped to something like 3 would also affect the path finding for direct messages if no default region is set since these are flood packages too?

A User in Switzerland would basically reach further when setting the default region to ch if we set flood.max.unscoped lower than flood.max, right?

Still learning about the details in the code :laughing: