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.