Am 10. und 11. November 2026 hat ein Absender mit ständig wechselnden Namen das Kärntner Netz mit Kanalnachrichten geflutet. Gegen genau diesen Absender gibt es am Repeater keine Einstellung. Was hilft, ist, Menge und Weite der Floods auf allen Repeatern zu begrenzen. Hier steht ein Vorgehen, das für jede solche Lage gilt, egal wo und von wem. Der Vorfall vom 10./11.11. dient als Beispiel: was wir gesehen haben, was die Firmware kann und in welcher Reihenfolge wir vorgehen.
Stand 11.11.2026. Alle Zahlen sind aus den Paketen der Karte gerechnet, nicht am Funk gemessen. Die Maßnahmen unten sind ein Plan, noch nicht umgesetzt. Die Firmware-Angaben stammen aus der Dokumentation der Entwickler und sind bei uns noch nicht getestet.
Public und vier Hashtag-Kanälen. Nach jeder Nachricht ändert sich der Emoji-Anhang im Namen: 270 verschiedene Namen aus acht Grundnamen, 848 Nachrichten.| 10.11. | 11.11. | |
|---|---|---|
| Pakete | 471 | 377 |
| Kürzester Pfad bei einem Observer | bei 200 von 471 mit 0 Hops, sonst 1 | nie unter 2 Hops, Median 4 |
| Pakete, in deren Pfad ein Repeater zweimal steht | 0 | 149 (40 %) |
Beim übrigen Kanalverkehr stehen in 13 % der Pfade Schleifen. Am 10.11. hörten Observer viele Pakete mit 0 oder 1 Hops, der Absender war also in Funkreichweite. Am 11.11. verteilen sich die ersten Hops gleichmäßig über viele Repeater in ganz Kärnten, und jedes Paket kommt schon mit mindestens zwei Hops bei einem Observer an. Das passt zu vorbelegten Pfaden: Der Absender trägt gefälschte Hash-Bytes in das Pfadfeld ein. Dasselbe beschreibt Issue 3278 im MeshCore-Repo für eine Flut in den Niederlanden. Bei uns ist das ein Hinweis, kein Beweis.
Folge: Aus den Pfaden dieser Nachrichten lässt sich nichts über die echten Verbindungen der Repeater untereinander ableiten.
Ein Repeater sieht von einem Kanalpaket nur den Kopf: Routentyp, Pfad, einen 1-Byte-Kanal-Hash und den verschlüsselten Rest. Er entschlüsselt nichts und prüft keine Signatur.
| Was man sperren möchte | Warum es nicht geht |
|---|---|
| Name | steckt im verschlüsselten Teil und ändert sich ohnehin nach jeder Nachricht |
| Schlüssel des Absenders | Kanalnachrichten tragen keinen. Es gibt keine Absender-Identität, die man sperren könnte |
| Kanal | Der Hash ist ein Byte und frei wählbar. Ein privater Kanal schützt den Inhalt, aber nicht vor Flut: Ein Repeater leitet auch Zufallsbytes mit beliebigem Kanal-Hash weiter, weil er nichts prüfen kann |
| Pfad | wird vom Absender bestimmt, siehe oben |
| Scope | Der Transport-Code ist ein 16-Bit-Wert, abgeleitet vom Regionsnamen. Wer den Namen kennt, kann ihn berechnen. Das ist eine Ableitung aus Drittquellen, von den Entwicklern nicht bestätigt |
Ein Scope sortiert, er schützt nicht. Wirksam sind nur Maßnahmen, die Menge, Weite und Form der Floods begrenzen. Den Absender selbst erreicht man nur, wenn man ihn findet und anspricht.
Wer sich an Sendeleistung und Duty Cycle hält, handelt innerhalb der Regeln. Eine Flut aus lauter erlaubten Aussendungen ist deshalb kein Fall für eine Behörde, sondern eine technische Aufgabe: Das Netz muss sie aushalten.
Hier spricht die Rechnung dafür, dass es so war: Der Absender kam in der Spitzenstunde auf rund 200 Pakete. Bei etwa einer Sekunde Sendezeit je Paket sind das rund 200 s je Stunde, also etwa 5,6 % und damit unter den 10 % des Bandes. Die Spitze von 19 Nachrichten je Minute zählt dafür nicht, weil der Duty Cycle über die Stunde gemittelt wird. Ob es ein oder mehrere Geräte waren, wissen wir nicht, die Rechnung gilt für ein einzelnes Gerät. Gemessen haben wir die Sendeleistung nicht.
Firmware-Angaben nach CLI-Befehle und Konfigurator.
| Maßnahme | Befehl | Firmware | Wirkung | Nebenwirkung | Empfehlung |
|---|---|---|---|---|---|
| Schleifen erkennen | set loop.detect moderate |
ab 1.14, Standard aus | wirft Floods weg, in deren Pfad der eigene Hash schon steht. Hätte am 11.11. 40 % der Pakete getroffen | bei 1-Byte-Hashes (14 von 63 Kärntner Repeatern) kollidieren fremde Repeater, dort minimal |
ja, überall |
| Hop-Grenze senken | set flood.max <n> |
alle | Pakete mit langem Pfad werden nicht weitergegeben. Pfade der Flut am Observer: Median 4, bis 21 Hops. Übriger Verkehr: Median 6, 90 % bis 12 | zu niedrig schneidet echten Verkehr in Randlagen ab | ja, gestuft: erst 24, nach Messung 16 |
| Hop-Grenze für Pakete ohne Scope | set flood.max.unscoped <n> |
ab 1.16 | Die Flut kam ohne Scope. Pakete mit Scope bleiben unberührt | Geräte ohne Scope reichen kürzer | später, wenn der Scope breit gesetzt ist |
| Sendezeit deckeln | set dutycycle 10 |
ab 1.15 (af ist veraltet) |
jeder Repeater begrenzt sich selbst. Der Standard ist 50 %, im Band um 869,6 MHz gelten nach unserem Stand 10 % (Rechtslage → Recht) | echter Verkehr wird bei Dauerlast ebenfalls gebremst | ja |
| Sendeverzögerung | set txdelay, set rxdelay |
alle | verteilt Wiederholungen, hilft nicht gegen die Menge | gering | nein |
| Pakete ohne Scope sperren | region denyf * |
ab 1.10 | wirft die Flut weg, solange sie ohne Scope kommt | zwingt alle Sender zu einem Scope. Der Absender kann sich einen setzen. Die Entwickler raten ab („NOT advised"). Aus einem Fork wird gemeldet, dass ein Paket mit Code 0 durchrutscht (ungeprüft) | nur als Notschalter, siehe Regionen |
| Einstieg sperren | block.entry, block.channel |
nur MeshOS-Firmware | stoppt Kanalverkehr über einen bestimmten ersten Hop | bei gefälschten Pfaden wirkungslos, 1-Byte-ID | nein |
| Privater Kanal | — | — | schützt Gespräche vor fremden Schreibern | Floods bleiben möglich | nicht gegen die Flut |
| Filter in der App | Spam-Filter im Client | App | versteckt Nachrichten | spart keine Sendezeit | nur zur Beruhigung |
| Weiterleitung am Einstieg abschalten | set repeat off (zurück: set repeat on) |
Firmware nicht angegeben | Die Repeater, die den Absender direkt hören, geben nichts mehr weiter. Die Flut kommt nicht ins Netz | Dort fällt auch der echte Verkehr aus. Der Absender kann den Standort wechseln. Ob die Einstellung einen Neustart überlebt, steht nicht in der Dokumentation | letztes Mittel, zeitlich begrenzt |
| Absender finden | Pegel an den Observern | — | grenzt den Standort ein | Aufwand | ja, parallel |
| Protokolländerung | Issue 3278 (Flood-Budget), Issue 3109 (signierte Public-Nachrichten) | offen | langfristig | liegt nicht bei uns | Daten beisteuern |
Wenn einzelne Betreiber allein etwas einstellen, bringt das wenig: Die Flut läuft über jeden Repeater, der sie weiterleitet. Wirksam ist nur eine einheitliche Mindestabwehr auf allen Repeatern.
Auf allen Repeatern, die es unterstützen:
set loop.detect moderate # 1-Byte-Repeater: minimal
set dutycycle 10 # ab Firmware 1.15
set flood.max 24 # später 16, siehe Phase 2
flood.max auf diesen Wert plus Reserve setzen, voraussichtlich 16.flood.max.unscoped auf 8 bis 12 setzen (ab 1.16).region denyf * als Notschalter dokumentieren: wer ihn setzt, wann, wie er zurückgenommen wird. Nicht als Dauerzustand. Vorher an einem Repeater prüfen, ob ein Paket mit Code 0 durchkommt.set repeat off). Das stoppt die Einspeisung, nimmt aber allen anderen dort den Weg ins Netz. Deshalb nur befristet, mit Absprache in der Gruppe, und mit Rückschalten (set repeat on), sobald die Flut vorbei ist. Hört man ihn an mehreren Stellen oder wechselt er den Standort, hilft das nicht.loop.detect, dutycycle.loop.detect und flood.max.unscoped auf allen gängigen Boards (nRF52, ESP32) ab diesen Versionen laufen.region denyf * Pakete mit Code 0 durchlässt.set repeat off einen Neustart übersteht und ob der Repeater danach noch Adverts sendet. Die Dokumentation sagt dazu nichts. Vor dem Ernstfall an einem Repeater ausprobieren.