MeshCore und Meshtastic im Vergleich: zwei Netze, zwei Denkweisen

Wer heuer in Kärnten mit LoRa-Mesh anfängt, steht schnell vor derselben Frage: MeshCore oder Meshtastic? In Foren wird sie gerne als Glaubensfrage geführt. Das ist sie nicht — die beiden Projekte lösen unterschiedliche Probleme.

Die Kurzfassung vorweg: Meshtastic ist für dynamische Ad-hoc-Netze gebaut. Geräte kommen, gehen, bewegen sich, und das Netz soll trotzdem funktionieren. MeshCore ist für geplante Infrastruktur gebaut: feste Repeater an bekannten Standorten, klare Rollen, sparsamer Umgang mit Sendezeit. Alles Weitere folgt daraus. Wer erst einmal wissen will, worum es bei Meshtastic überhaupt geht, findet das auf unserer Meshtastic-Seite und im Beitrag Texten, wenn das Netz weg ist.

Wie ein LoRa-Mesh überhaupt funktioniert

LoRa ist ein Funkverfahren für kleine Datenmengen über große Entfernungen. Ein Textpaket von hundert Zeichen braucht je nach Einstellung eine halbe bis mehrere Sekunden Sendezeit. Datendurchsatz ist nicht das, wofür man LoRa nimmt — Reichweite ist es.

Ein Mesh entsteht, wenn Geräte Pakete füreinander weiterreichen; jede Zwischenstation heißt Hop. Ein Node am Dobratsch hört ein Paket aus dem Gailtal und gibt es Richtung Klagenfurt weiter, obwohl Absender und Empfänger einander nie direkt hören. Zu unterscheiden sind dabei der Broadcast an alle (der offene Kanal) und die Direktnachricht an einen bestimmten Node. Die interessante Frage ist nicht ob, sondern wie weitergereicht wird — alle teilen sich denselben Kanal, und was der eine sendet, blockiert für die anderen die Luft. Jede Designentscheidung im Mesh ist eine Entscheidung über Sendezeit („Airtime“).

Routing: Flooding gegen Source Routing

Meshtastic verwendet Managed Flooding. Ein Broadcast wird von jedem Node, der ihn empfängt, erneut ausgesendet, bis das Hop-Limit erschöpft ist (Voreinstellung 3, Maximum 7). „Managed“ heißt: Vor dem Weiterleiten wartet ein Node kurz und horcht. Hat inzwischen jemand anderer dasselbe Paket weitergereicht, unterdrückt er die eigene Aussendung. Wie lange gewartet wird, hängt vom Empfangspegel ab — wer schwach empfangen hat, also vermutlich weit weg sitzt, sendet früher. So wandert das Paket nach außen, statt in der Nachbarschaft im Kreis zu laufen. ROUTER und REPEATER haben Vorrang und senden auch dann, wenn sie andere schon gehört haben.

MeshCore geht zweistufig vor. Die erste Nachricht an einen neuen Gesprächspartner läuft geflutet; aus der Zustellbestätigung lernt der Sender den Pfad. Danach nutzt er eine explizite Source Route und schreibt die Hop-Kette ins Paket — der Kopf trägt dafür einen Routentyp (ROUTE_TYPE_FLOOD oder ROUTE_TYPE_DIRECT), dahinter die Liste der Node-Hashes. Nur die genannten Repeater fühlen sich angesprochen.

Eine Einschränkung gehört dazu: Das gilt für Direktnachrichten. Gruppen- und Kanalnachrichten müssen auch bei MeshCore geflutet werden — eine Nachricht an viele kennt keinen einzelnen Pfad. Die Doku sagt das ausdrücklich; Repeater begrenzen den Flood-Anteil mit set flood.max. Wer hauptsächlich im offenen Kanal plaudert, holt sich also einen guten Teil des Flooding-Verhaltens zurück.

Und Meshtastic ist hier nicht auf dem Stand von 2023: Seit Version 2.6 gibt es Next-Hop-Routing für Direktnachrichten. Der erste Kontakt läuft über Flooding, dabei merkt sich der Node, über welchen Nachbarn die Antwort kam, und nutzt ihn künftig gezielt; bleibt er stumm, fällt das Gerät beim letzten Wiederholungsversuch auf Flooding zurück. Beide Systeme fluten also Broadcasts und routen Direktnachrichten gezielt — MeshCore mit vollständiger Pfadangabe im Paket, Meshtastic mit einem gespeicherten nächsten Hop.

Wer leitet weiter? Die Rollenfrage

MeshCore trennt. Nur Repeater leiten weiter, und nur wenn Hop- und Adresskriterien passen. Clients beziehungsweise Companions — die Geräte am Gürtel oder im Rucksack — senden und empfangen ausschließlich; die Doku nennt das den Kern des „messaging-first“-Designs. Dazu kommt der Room Server, ein schwarzes Brett, das Nachrichten speichert und beim Anmelden zustellt; per set repeat on kann er auch weiterleiten, wovon die Doku abrät.

Meshtastic kennt ein gutes Dutzend Rollen, aber in der Voreinstellung leitet jedes Gerät mit. In einem dünn besiedelten Netz ist das genau richtig: Jedes Handgerät verbessert die Abdeckung. In einem dichten Netz ist es das Problem — zwanzig Geräte im selben Tal, die jeden Broadcast brav wiederholen, sättigen die Airtime. Das Werkzeug dagegen ist vorhanden: CLIENT_MUTE leitet nichts weiter und bildet die MeshCore-Client-Semantik nach, ROUTER_LATE wiederholt zwar immer, aber erst nach allen anderen. Der Unterschied ist also weniger der Werkzeugkasten als die Voreinstellung: MeshCore erzwingt die Trennung, Meshtastic überlässt sie dem Betreiber.

Dazu kommt die Grundlast. Meshtastic sendet laufend NodeInfo, Position und Telemetrie in konfigurierbaren Intervallen. MeshCore arbeitet mit signierten Adverts: Ein Repeater flutet ab Werk alle zwölf Stunden einen (set flood.advert.interval), im österreichischen Netz wird auf 24, besser 48 Stunden entzerrt, dazu optional ein Zero-Hop-Advert für die Nachbarschaft (set advert.interval, in Minuten). Das ist eine andere Größenordnung an Hintergrundverkehr — auf einem geteilten Band mit gesetzlicher Sendezeitgrenze der praktisch relevanteste Unterschied.

MQTT: derselbe Name, zwei Konzepte

Beide Projekte reden von MQTT und meinen Grundverschiedenes. Kaum ein Punkt wird häufiger missverstanden.

Bei MeshCore ist MQTT ein Abgriff nach außen. Ein Observer-Node protokolliert die Pakete, die er über Funk empfängt, und schiebt sie per Bridge-Software auf einen MQTT-Broker; von dort holen Karten und Analysewerkzeuge die Daten ab. Ein Rückweg ist im offiziellen Observer-Pfad nicht vorgesehen. Fremde Firmware kann das durchaus — es gibt Repeater-Builds mit bidirektionaler MQTT-Brücke, sie sind nur nicht der Normalfall.

Bei Meshtastic ist MQTT ein bidirektionales Gateway. Ein Node mit Internetverbindung veröffentlicht empfangene Pakete unter Topics der Form msh/REGION/2/e/CHANNELNAME/USERID (binär) beziehungsweise msh/REGION/2/json/… (lesbares JSON). Der Standard-Broker ist mqtt.meshtastic.org. Entscheidend: Uplink und Downlink werden pro Kanal getrennt eingeschaltet (uplink_enabled, downlink_enabled). Ist Downlink aktiv, kommen Nachrichten aus dem Internet wieder über HF in die Luft.

Hier lohnt genaues Hinsehen. Am öffentlichen Broker hat das Projekt nachgebessert: Es gilt eine Zero-Hop-Policy — was aus dem Internet kommt, erreicht nur die direkt angebundenen Nodes und wandert nicht weiter durchs lokale Mesh. Dazu kommen eine Filterung auf wenige Pakettypen und vergröberte Positionsdaten. Der Schreckensfall „halb Europa funkt ins Gailtal“ ist damit weitgehend entschärft.

Möglich bleibt er am eigenen Broker, und die Doku sagt das ausdrücklich: Private Broker setzen die Zero-Hop-Policy nicht durch und können mit dem Standardschlüssel das Mesh mit Verkehr fluten. Wer dort Downlink aktiviert, entscheidet über fremde Sendezeit im eigenen Tal; wer ein reines HF-Netz will, lässt Downlink aus. Zweite Falle am eigenen Broker: Ohne gesetztes encryption_enabled gehen die Pakete unverschlüsselt hinaus, auch bei eigenem Kanalschlüssel.

Fürs Kartenlesen bleibt: Taucht auf einer Meshtastic-Karte ein Node auf, weiß man nicht ohne Weiteres, ob er über Funk oder über das Internet dorthin kam. Bei MeshCore ist ein Eintrag im Regelfall ein echter HF-Empfang. Beides sagt nichts darüber, ob der Node von dort erreichbar ist, wo man selbst steht.

Verschlüsselung und was sie tatsächlich schützt

MeshCore verschlüsselt Kanalnachrichten mit einem gemeinsamen Kanalschlüssel. Im Paket steht dazu ein „channel hash“ — ein Byte aus dem SHA256 des Schlüssels — plus MAC und Chiffrat. Ein Repeater kann also zuordnen und weiterleiten, ohne den Inhalt zu sehen. Der Haken: Der Schlüssel des öffentlichen Kanals steht in der Dokumentation (hex 8b3387e9c5cdea6ac9e5edbaa115cd72). Der Public Channel ist technisch verschlüsselt, praktisch offen. Erst ein eigener Kanal mit eigenem Passwort schützt wirklich, und dieses Passwort geht nie über Funk. Direktnachrichten laufen über Schlüsselpaare Ende zu Ende.

Meshtastic verschlüsselt kanalbasiert mit einem Pre-Shared Key (AES256-CTR). Der Standardkanal verwendet ebenfalls einen öffentlich bekannten Schlüssel (AQ==). Eigene Kanäle mit eigenem PSK sind möglich, und seit Version 2.5 gibt es PKI-basierte Direktnachrichten mit einem Schlüsselpaar pro Node. Die Symmetrie ist damit größer, als beide Lager erzählen: Der voreingestellte offene Kanal nutzt bei beiden einen allgemein bekannten Schlüssel, echte Vertraulichkeit beginnt bei beiden erst mit einem selbst vergebenen.

Zwei Ehrlichkeiten dazu: Welchen Cipher MeshCore verwendet, steht in der öffentlichen Doku nicht — dort finden sich „cipher MAC“ und „ciphertext“, aber kein Verfahren; kursierende „AES-256“-Angaben sind nicht belegbar. Die Meshtastic-Doku benennt ihre Grenzen dagegen selbst: keine Perfect Forward Secrecy, keine Integritätsprüfung bei Kanalnachrichten, und wer den Kanalschlüssel hat, kann sich als jemand anderer ausgeben.

Regionen und Traffic-Begrenzung

MeshCore kennt ein Region-Scoping, das bis ins Paketformat reicht: Die Routentypen ROUTE_TYPE_TRANSPORT_FLOOD und ROUTE_TYPE_TRANSPORT_DIRECT führen eine Regionskennung mit. Repeater bekommen Regionen zugewiesen, Kanäle lassen sich damit verknüpfen; ist ein Repeater nicht zuständig, verwirft er das Paket. Die Makroregionen folgen der EU-Systematik NUTS-1, darunter liegen Staat und Bundesland; für Kärnten lautet die empfohlene Liste * · at · at-ktn · at-sued. So frisst Verkehr aus Vorarlberg im Gailtal keine Sendezeit.

Ein Äquivalent im Protokoll hat Meshtastic nicht — begrenzt wird über Hop-Limit und getrennte Kanäle. Das ist gröber: Ein Hop-Limit kennt Entfernung, aber keine Landesgrenze.

Praxis in Kärnten: Einstellungen, Namen, Bänder

Für MeshCore in Österreich gilt das Preset, das die Community EU/UK Narrow nennt:

• Frequenz: 869.618 MHz
• Bandbreite: 62,5 kHz
• Spreading Factor: SF8
• Coding Rate: 8
• CLI: set radio 869.618,62.5,8,8

Achtung: Es kursieren noch ältere Werte (869.525 MHz, BW 250 kHz, SF11). Damit hört man niemanden und wird von niemandem gehört — der häufigste Anfängerfehler, und er sieht aus wie ein Hardwaredefekt.

Für die Benennung hat sich das Schema AT-BEZIRK-NAME nach den KFZ-Kennzeichen eingebürgert. Kärntner Kürzel: K, KL, FE, HE, SP, SV, VI, VL, VK, WO. Beispiele: AT-VL-Dobratsch, AT-HE-Gailtal. Laut dem Portal meshcore.at umfasst das österreichische Netz über 300 aktive Nodes.

Bei Meshtastic ist das Gegenstück kürzer: Region EU_868 einstellen, beim Standard-Preset LongFast bleiben — die Frequenzdetails ergeben sich aus der Region. Betrieben wird in Österreich teils auf 868 MHz, teils auf 433 MHz. Der Unterschied ist rechtlich, nicht technisch: 868 MHz ist lizenzfreier SRD-Betrieb. Der Bereich um 433 MHz überlappt mit dem 70-cm-Amateurfunkband — wer dort mit Rufzeichen sendet, darf mehr Leistung nutzen, muss aber die Regeln des Amateurfunkdienstes einhalten, und dazu gehört das Verbot verschlüsselter Inhalte. Verschlüsselte Kanäle und Amateurfunkbetrieb passen also nicht zusammen. Passende Hardware für beide Welten haben wir unter Geräte lizenzfrei gesammelt.

Recht: lizenzfrei heißt nicht regelfrei

Zuerst ein verbreitetes Missverständnis: MeshCore auf 868 MHz ist kein Amateurfunk, sondern lizenzfreier SRD-Betrieb wie PMR oder CB — mehr dazu unter Lizenzfrei funken. Eine Amateurfunklizenz ändert daran nichts; sie erlaubt auf diesem Band weder mehr Leistung noch längere Sendezeiten.

Bei den Grenzwerten widerspricht sich das österreichische Portal meshcore.at derzeit selbst: Seine FAQ nennt 25 mW e.r.p. und 1 % Sendezeitanteil, die Repeater-Referenz empfiehlt gleichzeitig set tx 22 (22 dBm, rund 158 mW) und set af 9 (10 % Sendezeitanteil). Beides zugleich kann für dieselbe Frequenz nicht gelten.

Auflösung: Das 868er-Band ist kein einheitlicher Block, sondern in Teilbereiche mit unterschiedlichen Auflagen zerlegt. Die österreichische Frequenznutzungsverordnung (Anlage 2, BGBl. II Nr. 397/2019) verweist für beide auf die harmonisierte EU-Entscheidung 2006/771/EG — dort gilt für 868,0–868,6 MHz eine Grenze von 25 mW e.r.p., für 869,4–869,65 MHz dagegen 500 mW e.r.p. bei 10 % Sendezeitanteil. Die verwendeten 869.618 MHz liegen im oberen Teilbereich; die 25 mW und 1 % sind die Werte des unteren. Die empfohlenen 22 dBm bleiben deutlich unter der Grenze, set af 9 bildet die zulässigen 10 % ab. Auch Meshtastic nennt für EU_868 denselben Bereich mit 10 %.

Damit ist nicht alles gesagt: Zum Teilbereich gehören Nebenbedingungen, etwa zum Kanalraster, die bei 62,5 kHz Bandbreite eine Rolle spielen können. Wer eine feste Station plant, liest im Original nach — die Dokumente sind unten verlinkt.

Reife, Ökosystem und Risiko

Beim Ökosystem liegt Meshtastic deutlich vorne: mehr Clients, mehr Integrationen, ein ATAK-Plugin, eine erheblich größere Nutzerbasis, mehr Jahre Feldstabilität, umfangreichere Doku, mehr getestete Hardware. Wer im Problemfall rasch eine Antwort finden will, ist dort besser aufgehoben. MeshCores Stärke liegt in der Konsequenz des Entwurfs: sparsam mit Sendezeit, klare Rollen, Regionsbegrenzung im Protokoll.

Ein Risikopunkt gehört bei Konzepten mit Fünfjahreshorizont dazu: MeshCore ist jünger und steckt seit dem Frühjahr 2026 in einem Markenrechtsstreit. Im März 2026 hat ein bis dahin prominenter Beitragender im eigenen Namen eine britische Wortmarke „MeshCore“ angemeldet; das Kernentwicklerteam betreibt seither meshcore.io und hat laut meshcore.at Ende Juli 2026 Widerspruch eingelegt. Stand August 2026 ist die Sache offen. Ein Fork der Firmware ist nicht entstanden, wohl aber eine Aufspaltung von Webseite und App-Ökosystem — für Einsteiger heißt das: aufpassen, welcher Quelle man folgt.

Fazit: Wofür welches System

Kein Sieger auszurufen, sondern zwei Antworten auf zwei Fragen. Meshtastic passt, wenn das Netz beweglich ist und niemand die Topologie im Voraus kennt — Wandergruppe, Field Day, Übung im Gelände — und wenn man vom größeren Ökosystem profitieren will. MeshCore passt, wenn dauerhafte Struktur entstehen soll: Repeater auf Bergstandorten, klare Trennung von Weiterleitern und Endgeräten, sparsamer Umgang mit Sendezeit.

Beide laufen auf weitgehend derselben Hardware. Wer unsicher ist, flasht um und probiert beide — die Entscheidung ist billiger, als die Diskussionen darüber vermuten lassen.

Quellen

• MeshCore Österreich — Einstieg, Regionen, Repeater-Referenz, News: https://meshcore.at/ und https://meshcore.at/news
• MeshCore Projektseite und Firmware: https://meshcore.io/ · https://github.com/meshcore-dev/MeshCore
• MeshCore Dokumentation (FAQ, Paket- und Payload-Format): https://docs.meshcore.io/faq/ · https://docs.meshcore.io/packet_format/ · https://docs.meshcore.io/payloads/
• Observer-Aufbau (Beispielanleitung): https://chicagolandmesh.org/guides/meshcore/mqtt/
• Bidirektionale MQTT-Gateway-Firmware für MeshCore-Repeater: https://github.com/jmead/Meshcore-Repeater-MQTT-Gateway
• Meshtastic Mesh-Algorithmus: https://meshtastic.org/docs/overview/mesh-algo/
• Meshtastic Geräte-Rollen: https://meshtastic.org/docs/configuration/radio/device/
• Meshtastic MQTT-Konfiguration: https://meshtastic.org/docs/configuration/module/mqtt/
• Meshtastic MQTT-Integration, Topics und Zero-Hop-Policy: https://meshtastic.org/docs/software/integrations/mqtt/
• Meshtastic LoRa-Konfiguration (Hop-Limit, EU_868): https://meshtastic.org/docs/configuration/radio/lora/
• Meshtastic Verschlüsselung: https://meshtastic.org/docs/overview/encryption/
• Frequenznutzungsverordnung, Anlage 2 (BGBl. II Nr. 397/2019): https://www.ris.bka.gv.at/Dokumente/BgblAuth/BGBLA_2019_II_397/COO_2026_100_2_1702011.pdfsig
• Funk-Schnittstellenbeschreibungen und Frequenzverwaltung, RTR: https://www.rtr.at/
• Zum Markenrechtsstreit: https://lwn.net/Articles/1070218/