eternityforest/lazymeshProof-of-Concept-Mesh-Netzwerk für IoT/Amateurfunk mit globalem Routing über das Internet
Mesh-Routing-System, das die Verwendung eines OpenDHT-Proxys als Backend unterstützt, sodass Knoten direkt über das Internet kommunizieren können. Sehr frühe Pre-Alpha, Proof of Concept, funktioniert möglicherweise noch nicht, usw.
Dies ist sowohl für Hobby-/Funkamateur-Anwendungsfälle als auch für eher typische Verbraucher-/kommerzielle IoT-Arbeiten gedacht, versucht aber ausdrücklich nicht, das Internet zu ersetzen oder große, stark frequentierte Gebiete mit Rundstrahlantennen abzudecken.
Es verfügt nicht über das Next-Hop-Routing im Meshtastic-Stil, daher der Name LazyMesh. Wenn du es für Offgrid-Anwendungen in einem dicht besiedelten Gebiet verwenden möchtest, benötigst du wahrscheinlich Richtantennen und manuell koordinierte Routen-IDs.
Derzeit ist dies die einzige tatsächliche Anwendung. Öffne die Beispiel-Arduino-Skizze, passe sie mit deinem Benutzernamen und einem geheimen Kanalschlüssel an, der ein starkes Passwort sein muss.
Gib deine Nachricht im seriellen Monitor von Arduino ein, und du solltest mit allen anderen Geräten chatten können.
Nachrichten sollten durchkommen, solange sich die Knoten entweder im selben Netzwerk befinden oder beide Internetzugriff haben.
Besuche den Web-Client, um über das Internet per MQTT mit dem Knoten zu chatten. Lege einfach einen Benutzernamen fest, füge einen Kanal hinzu und gib das Kanalpasswort ein. Der Kanalname kann beliebig sein und beeinflusst nur die Beschriftung in der Benutzeroberfläche.
Du kannst auch die Beispielskizze „Daten lesen/schreiben“ ausprobieren. Diese legt Daten-ID 195 als lesbar und Daten-ID 196 als lesbar und beschreibbar offen. Gehe auf die Website, gib deine Kanaldaten ein und verwende den Dialog für Datenanfragen, um ID 196 von allen Geräten anzufordern.
Klicke dann auf „set“ und setze sie auf etwas anderes, und versuche dann, sie erneut zu lesen.
Der Web-Client ist derzeit fest darauf codiert, test.mosquitto.org zu verwenden; das wird sich in Zukunft ändern.
Knoten benötigen eine Möglichkeit, die Zeit zu synchronisieren, um zu kommunizieren. Wenn sie noch nie Zeit von einer vertrauenswürdigen Quelle empfangen haben, setzen sie ihre Zeit derzeit anhand eines beliebigen Pakets, das sie sehen.
Dies könnte ein Sicherheitsrisiko darstellen, das Replay-Angriffe ermöglicht. Daher sollten Geräte, die Sicherheit benötigen, eine vertrauenswürdige Zeitquelle haben.
Sobald die Zeit initial gesetzt wurde, passt der Code seine Systemzeit um bis zu 1 Sekunde pro Tag an, um mit anderen Knoten synchron zu bleiben. Ein Auseinanderdriften aus der Synchronisation sollte daher kein großes Problem darstellen.
In LazyMesh ist alles ein Kanal, es gibt keine direkten Nachrichten. Wenn du solche möchtest, erstelle einfach einen dedizierten privaten Kanal.
Kanäle werden durch ein Passwort definiert. Wer das Passwort kennt, hat Lese- und Schreibzugriff.
Es gibt 256 Routennummern. Jedes Paket hat eine solche, und Repeater wiederholen nur, wenn sie eine passende Routennummer aktiviert haben. Standardmäßig wird alles mit Routennummer 0 gesendet, die standardmäßig aktiviert ist.
Das betrifft nur Repeater. Knoten hören auf jede Mesh-Routennummer, wenn ein Paket direkt für sie bestimmt ist.
Paketnutzlasten sind MessagePack-Arrays. Sie wechseln zwischen ganzzahligen Daten-IDs und Datenelementen. 192–256 sind für anwendungsspezifische Nachrichten reserviert.
ID 32 ist für Textnachrichten vorgesehen, die mit einem Benutzernamen und einem Doppelpunkt versehen werden können.
ID 2 wird für eine eindeutige ID verwendet, die eine Ganzzahl sein muss. Viele Anwendungen benötigen diese möglicherweise überhaupt nicht.
Hänge ein Metadaten-Längenbyte und N Bytes Metadaten an.
Um den IV zu erstellen, nimm 12 zufällige Bytes für den IV. Verschlüssele dann das Ganze. Stelle den IV voran und hänge 4 Authentifizierungs-Tag-Bytes an.
Nimm dann die ersten 8 Bytes des Routing-ID-Hashs und konvertiere sie in Hex.
Das MQTT-Thema lautet lazymesh_route_HEX.
Beachte, dass wir ein Top-Level-Thema verwenden. Dadurch ist es nicht möglich, über Wildcards auf öffentlichen Brokern gleichzeitig alle LazyMesh-Kanäle zu abonnieren, was es ziemlich einfach machen würde, alle per DoS anzugreifen.
Einfach die rohen Pakete, die auf 224.0.0.251:2221 per Broadcast gesendet werden.
Nichts davon ist endgültig!!!
All numbers are little-endian.
1 byte header:
2 bit packet type(Either 1 or 2, depending on if we want ACK)
3 bits TTL hops remaining
1 bit allow slow transport(LoRa etc)
1 bit allow global routing
1 bit was already global routed
1 byte header 2:
1 bit first send attempt:
Whenever we create a or recieve a packet, set this bit. After trying to send it,
clear it. This way, as long as we assume packet loss is low-ish, we can count the repeaters in the area
without extra overhead.
1 bit repeater bit:
Marks that this packet should be included when counting repeaters.
Set it if you would repeat the packet or one like it, even if you originated it.
1 bit interest bit:
If this is set, the node who sent it is directly interested in the channel,
not purely just a repeater. If first send is also set, it is treated as an
implicit ack
1 bit location enabled
If this bit is set, repeaters may add location metadata to the packets forwarded to the internet. This metadata must be encrypted with the routing ID as the key,
meaning nearby people could track you for 1 hour after you get out of range.
Not implemented anywhere at the moment.
5 reserved 0 bits
1 byte mesh route number
1 byte path loss accumulated:
5 bits total
3 bits last hop
Every hop is a point of path loss,
plus whatever extra cost heuristic the transport applies.
1 extra point of loss should be roughly the same "badness" as
10dbm extra loss on wifi.
16 bytes routing ID:
Changes every hour, derived from the channel PSK by a hash.
The PSK is just the 16 byte SHA256 of the password.
The routing ID changes hourly, and is the SHA256 of:
The letter 'cr'
The count of hours since 1970 as a 32 bit unsigned int
the PSK
8 Bytes random entropy:
Used as part of the IV for the cipher
4 bytes timestamp:
Also part of the IV, also prevents replay attacks
N bytes ciphertext:
AES-GCM encrypted.
The encryption key changes hourly, and is the SHA256 of:
The letter 'c'
The count of hours since 1970 as a 32 bit unsigned int
the PSK
6 bytes auth tag:
The last 6 bytes are the GCM tag
Einige Implementierungen können sich dafür entscheiden, dies vollständig zu ignorieren.
ACKs sind grundsätzlich pro Hop, es sei denn, eine höhere Protokollebene möchte End-to-End-ACKs durchführen.
ACK-Pakete werden weder wiederholt noch geroutet oder Ähnliches, und sie sind auch nicht authentifiziert. Jeder Schritt der Mesh-Wiederholung hat seine eigene Bestätigung; aus Sicht des ursprünglichen Absenders ist es „Fire-and-Forget“.
Wie Meshtastic und die meisten anderen ist das Protokoll „halbzuverlässig“. Wie in allen Netzwerken gibt es Randfälle, die zu Fehlern führen können.
Echte Zuverlässigkeit muss auf einer höheren Ebene erreicht werden.
Für jedes Paket sendet jeder interessierte Zuhörer dieses bestimmten Kanals genau einmal eine Kanalbestätigung, es sei denn, er erkennt, dass bereits mehr als 8 ACKs von anderen Knoten gesendet wurden.
Dieses Paket muss über alle Transporte gesendet werden, nicht nur über den, über den das Paket gekommen ist. Andernfalls könnten andere Knoten eine falsche Vorstellung davon bekommen, wie viele Zuhörer es gibt.
Wenn ein Paket sowohl das Bit für den ersten Sendeversuch als auch das Interessen-Flag gesetzt hat, ist dies wie ein impliziter ACK. Wenn wir eine Kopie des Pakets senden, müssen wir nicht zusätzlich einen ACK senden, um uns zur Interessenzahl hinzuzufügen.
Repeater bestätigen, indem sie einfach eine Kopie des Pakets senden. Wenn diese mit dem Flag für die erste Kopie markiert ist, zählen wir sie. Aus diesem Grund müssen Transporte wie WLAN wiederholen, auch wenn es nicht wirklich sinnvoll ist.
Dies gilt NICHT für globale Routing-Transporte. Globales Routing wird separat behandelt und unterliegt keinerlei ACKs, Wiederholungen oder Ähnlichem; wir gehen davon aus, dass der MQTT-Server alles übernimmt.
Knoten können eine Nachricht einige Male erneut senden, wenn sie weniger Antworten als erwartet erhalten.
Knoten dürfen niemals mehr als 6 Repeater und 6 Kanalzuhörer erwarten, selbst wenn sie mehr Antworten erhalten, da das einfache ACK-Schema darüber hinaus ungenau wird, wenn der Paketverlust moderat ist.
1 byte header:
Always 0, packet type is control, and these are not routable or repeatable
1 byte header 2:
Same as on the data packets. Not really used at the moment
1 byte subtype:
CONTROL_TYPE_CHANNEL_ACKNOWLEDGE
You can acknowlege as a channel listener
so the sender knows how many there are.
4 byte message ID:
just the first 4 bytes of the random IV from the packet we are ACKing
Jede Stunde, ein paar Minuten vor der vollen Stunde, sollten Knoten eine Ankündigung der Kanäle senden, an denen sie interessiert sind.
Dies sollte mit den rollierenden Codes für die nächste Stunde gesendet werden, nicht für die aktuelle, damit Verbindungen im Voraus aufgebaut werden können und alles funktioniert, auch wenn die Zeiten nicht synchron sind.
Knoten bilden ein Mesh über Bluetooth mithilfe eines Extended-Advertising-Pakets mit der Service-UUID d1a77e11-420f-9f11-1a00-10a6beef0001, wobei die Nutzlast einfach das obige Paketformat ist.
BLE-Pakete dürfen niemals das Flag „erste Kopie“ gesetzt haben, und wir zählen keine Repeater über BLE. Der Paketverlust ist einfach zu hoch für jedes einfache und skalierbare Schema, das ich mir vorstellen kann.
Daher behandeln wir es einfach als einen inhärent verlustbehafteten Kanal, den wir etwas abmildern, indem wir Pakete bis zu 4 Mal wiederholen – oder bis wir damit aufhören müssen, um ein anderes Paket zu senden.
Solange der Knoten nicht versucht, mehr als ein oder zwei Pakete pro Sekunde zu senden, bietet das reine Wiederholungsschema eine gewisse Zuverlässigkeit. Wenn wir darüber hinausgehen, wird zurückgerudert, um nicht alles zu stören.
Wir stoppen auch das Senden, wenn wir sehen, dass zu viele andere Knoten in derselben Gegend zu viele Kopien des Pakets senden.