BRONTEKST voor de samenvatting op deze site (mc-info) Opgehaald op 2026-09-04 met een gewone HTTP-request (platte tekst uit de HTML; navigatie, footer en reactieformulier weggelaten). nodenet.be is leidend; bij verschil tussen deze tekst en de live pagina geldt de live pagina. ============================================================================== BRON 1 URL: https://nodenet.be/wijziging-in-floodbeleid-voor-unscoped-berichten-vanaf-1-augustus-2026/ Titel: Wijziging in floodbeleid voor unscoped berichten vanaf 1 augustus 2026 Gepubliceerd: 2026-07-24 (volgens de pagina), laatst bijgewerkt 2026-08-01 Opgehaald: 2026-09-04 ============================================================================== Vanaf 1 augustus voeren we binnen het Belgische MeshCore-netwerk een aanpassing door aan de verwerking van unscoped berichten. ## Wat verandert er? Vanaf die datum raden we aan om je repeater zo in te stellen dat enkel nog berichten doorgelaten worden met één van de volgende scopes: - eu (europa) - bx (benelux) - be (België) - be-vlg (Vlaams Gewest) - be-vli (Provinciaal niveau: in dit voorbeeld Limburg) Berichten zonder scope (unscoped) zullen niet langer onbeperkt door het netwerk worden geflood. Hoe je region’s instelt in je repeater kan je hier terugvinden. ## Waarom deze wijziging? De afgelopen maanden zien we een sterke toename van verkeer afkomstig uit het Verenigd Koninkrijk. Dit is vooral merkbaar aan de kust, waar: - gunstige propagatieomstandigheden regelmatig verbindingen over het Kanaal mogelijk maken; - minstens één repeaterbeheerder gebruikmaakt van een richtantenne (Yagi) die specifiek richting het Europese vasteland uitzendt. Hoewel dit technisch interessant is en aantoont hoe krachtig MeshCore kan zijn, leveren deze berichten voor de meeste Belgische gebruikers geen relevante informatie op. Het gevolg is dat een groot aantal berichten onze Belgische mesh binnenkomt en zich verder verspreidt. Dit zorgt voor: - extra belasting van repeaters; - hogere kanaalbezetting; - onnodige opslag van berichten; - een verhoogd risico op verzadiging van het netwerk. ## Aanbevolen configuratie Aan de kust wordt gekozen om alle unscoped berichten te stoppen. Voor repeaters elders in België is een iets soepelere aanpak waarschijnlijk wenselijk: set flood.max.unscoped 3 Hiermee krijgen nieuwe gebruikers of bezoekers uit naburige regio’s nog steeds de mogelijkheid om regionale berichten te verspreiden, zelfs wanneer zij nog niet vertrouwd zijn met ons scopesysteem. Deze instelling biedt een goed evenwicht tussen: - openheid voor nieuwe gebruikers; - regionale interoperabiliteit; - bescherming tegen grote hoeveelheden irrelevante externe berichten. ## En mijn DM’s dan? DM’s worden standaard zonder scope verzonden. Om ervoor te zorgen dat jou DM’s toch verder geraken dan het aantal hops dat ingesteld werd via flood.max.unscoped, kan je in jouw companion, in de experimentele settings de Default Region Scope op bv be zetten. Dan kan je mits alle Belgische repeaters be als regio ingesteld hebben binnen België DM’s versturen. ## Wat vragen we van jou? We vragen alle Belgische repeaterbeheerders om hun configuratie vóór 1 augustus na te kijken en indien mogelijk een van bovenstaande instellingen toe te passen. Ons doel is niet om internationale connectiviteit onmogelijk te maken, maar wel om ervoor te zorgen dat het Belgische netwerk performant blijft en beschikbaar blijft voor de gebruikers waarvoor het bedoeld is. Bedankt voor jullie medewerking en de blijvende inzet voor het Belgische MeshCore-netwerk. Tags:Info ============================================================================== BRON 2 URL: https://nodenet.be/instellingen/regio-en-scope/ Titel: Regio en Scope Opgehaald: 2026-09-04 (De pagina bevat onder het artikel ook lezersreacties; die staan hieronder mee vanaf "5 gedachten over", maar zijn NIET als bron voor de samenvatting gebruikt.) ============================================================================== Voor de regio-indeling volgen we de internationale standaarden: Volgens ISO 3166 is de landcode voor België BE. Verder is België opgedeeld in 3 regio’s en 10 provincies. (ISO 3166-2) Hoewel we bij de naamgeving van de repeaters gekozen hebben om de ISO standaarden te volgen, en hoofdletters te gebruiken bij de afkortingen, is het voor het instellen van de berichten scope veel handiger om met kleine letters te werken. De landcode voor België wordt dus “be” ## Belgische regio’s ISO Code Regio Code Gewest BE-BRU be-bru Brussels Hoofdstedelijk Gewest BE-VLG be-vlg Vlaams Gewest BE-WAL be-wal Waals Gewest ## Provincies ISO Code Regio Code Provincie BE-VAN be-van Antwerpen BE-WBR be-wbr Waals Brabant BE-VLI be-vli Limburg BE-WLG be-wlg Luik BE-WLX be-wlx Luxemburg BE-WNA be-wna Namen BE-VOV be-vov Oost-Vlaanderen BE-VBR be-vbr Vlaams Brabant BE-VWV be-vwv West-Vlaanderen ## Repeater Configuratie Je configureert de regio’s van de repeater via de CLI (command line interface). Log hiervoor in op je repeater via de Companion‑app of via een USB/seriële verbinding. De minimale configuratie bestaat uit land en provincie. Gebruik een geneste structuur om de regio’s correct in te stellen. Voer de commando’s één voor één uit en wacht na elk commando op een OK‑bevestiging voordat je verdergaat. Een voorbeeld: we configureren een repeater in Limburg. Limburg (be-vli) ligt in het Vlaams Gewest (be-vlg), in België (be), in de BeNeLux (bx), in Europa (eu) Voor praktisch gebruik in normale omstandigheden (zonder calamiteiten) raden we aan om de scope “be” te gebruiken voor berichten van gebruikers in België . region def eu bx be be-vlg be-vli region default be region save Controleer met het commando region of de configuratie gelukt is. Dit zou je moeten zien: region * eu F bx F be^F be-vlg F be-vli F ## Kies bewust welke regio’s je configureert Configureer op je repeater enkel de regio’s waarvan je installatie geografisch echt deel uitmaakt. Een repeater in Limburg hoeft dus niet zomaar elke beschikbare regio door te laten. Hoe ruimer je configureert, hoe groter de kans dat berichten verder door het netwerk reizen dan nodig is, en dat is precies wat we willen vermijden. Voor repeaters in grensgebieden kan het zinvol zijn om meer dan één regio in te stellen. Denk aan een repeater die zowel verkeer uit Belgisch als uit Nederlands Limburg zinvol kan ondersteunen. Ook daar geldt: wees selectief en overdrijf niet. Te veel regio’s tegelijk configureren leidt tot onnodige netwerkbelasting en onvoorspelbaar gedrag. Stuur je zelf een bericht, kies dan altijd de kleinste scope die nog iedereen bereikt die het bericht moet ontvangen. Een lokaal bericht hoeft geen Benelux-bericht te worden. In grensgebieden is het daarom vaak beter om samen een aparte, logische regio af te spreken. Een scope die Belgisch én Nederlands Limburg omvat, is voor het netwerk een efficiëntere oplossing dan meteen de brede bx-scope (Benelux) te gebruiken. Je houdt zo de berichtstroom binnen het gebied waar ze werkelijk relevant is. Maak dit soort beslissingen nooit alleen. Stem af met de beheerders van naburige repeaters, zodat iedereen dezelfde regio’s gebruikt en het netwerk efficiënt en voorspelbaar blijft werken. ## Extra: geneste region’s Geef bij het aanmaken van de region’s altijd aan wat hun relatie is tenopzicht van elkaar. Zo is be-vlg een onderdeel van be, daarom schrijven we: region put be-vlg be En is be-vli een onderdeel van be-vlg en schrijven we: region put be-vli be-vlg Willen we aan de region’s van deze repeater ook Vlaams brabant toevoegen (be-vbr), dan nesten we die onder be-vlg. region put be-vbr be-vlg En voegen we Kuringen (bekrn) toe, dan schrijven we: region put bekrn be-vli Sluit altijd af met “region save” opdat je ingevoerde configuratie na een reboot nog steeds actief is. Opmerking: de huidige repeater firmware houdt geen rekening met de geneste regiostructuur. M.a.w. een child regio neemt nog niet de flood settings over van een parent regio. Alle feedback is welkom via de reacties. ## 5 gedachten over “Regio en Scope” - Edwin Mortelez 2026-07-25 bij 23:42 Antwoord Jullie maken het onnodig ingewikkeld Waarom werken met sub regio’s, Dat is een systeem dat men gebruikt op routers in bedrijven maar voor ons niet relevant is Gewoon de regio’s naast elkaar. be, bx, wvl enz naast elkaar ipv onder elkaar En op de companion gewoon de regio zetten naargelang het kanaal. Vb BEmesh op be zetten. EU mag daar nooit inkomen.Dit zal uitnodigen zoals nu op * gewoon de hele dag test te zien en ontvangen op 27 hops in plaats X Dit vervuild het hele netwerk als geheel Europa probeert hoe ver ze geraken. Dan noeten we gewoon blijven verder werken zonder regio’s. De Belgen komen trouwens aan heel weinig airtime. De vervuiling komt steeds vanuit het buitenland op 1 byte. Niet van Belgen. Laat ons het gewoon houden op be. 70 procent zal niets begrijpen van cli commando’s. Maar be kunnen ze gewoon instellen in de interface. Be toevoegen en Deny * en het is opgelost. - - Myst 2026-08-01 bij 07:16 Antwoord Sub regios laat repeaters toe om airtime te vrijwaren voor uzelf. (Wanneer het te druk is, of wanneer we een spammer hebben). Naast elkaar: airtime vol = jij kan niet meer in je eigen repeater of met je buur praten. Sub regios: je airtime bijna vol = eu uit… nog vol = bx uit… nog vol = be uit, etc… Het heeft weinig zin om heel het netwerk in te stellen voor de nood van augustus 2026. Indien er volgende maand een lolbroek is die wil spammen zou de vraag zijn “waarom niet in een keer correct ingesteld” - - Sysop 2026-08-01 bij 08:31 Antwoord Volgens de documetatie https://docs.meshcore.io/cli_commands/?h=nested#region-examples nemen geneste regions de flooding flag over van de parent region. Ik heb al op andere plaatsen gelezen dat dit zo (nog) niet geïmplementeerd is. Moest dat wel zo zijn, of in de toekomst zo geïmplementeerd worden, dan is het voor jou scenario om airtime te vrijwaren zelfs beter om de regio’s niet te nesten. Een deny flood op EU zou dan je hele repeater stil leggen. Dat moeten we dus nog eens even testen. Door af en toe eens te vragen om wat te wijzigen, zien we ook snel welke de slapende repeaters zijn. *edit* -> net getest, flood deny van een hoofdregio houdt het verkeer van de child regio niet tegen. - - Myst 2026-08-01 bij 15:11 Antwoord Allemaal deel van een platform in ontwikkeling. (Maar ook deels wat het leuk en uitdagend maakt.) Hieronder is het beschreven, en in een van de links is ook een optie om het zelf uit te proberen met fw. https://github.com/meshcore-dev/MeshCore/commit/30ebe2c3f7b6e08eda08603a54b7856541f7bc72 https://github.com/meshcore-dev/MeshCore/pull/2960 Alternatief https://github.com/meshcore-dev/MeshCore/issues/2747#issuecomment-4688993246 - Sysop 2026-07-26 bij 08:02 Antwoord Meshcore is nog in volle ontwikkeling, en voor de meesten ontbreekt nog steeds een echt doel. Daarom lijkt het ons nuttig om voorlopig nog wat opties open te laten. Eens we onze echte bestaansredenen gevonden hebben kunnen we daar nog voor gaan. Voorloping blijven we verder experimenteren. Je idee om regio’s op hetzelfde niveau te programmeren lijkt vanuit een gebruikersstandpunt wel een vereenvoudiging, en kan volgens mij ook door elkaar gebruikt worden. Bedankt voor je input.