Innerhalb jedes MeshCore-Pakets befindet sich eine Nutzlast (Payload), die über den Payload-Typ im Paketkopf identifiziert wird. Folgende Payload-Typen existieren:
- Node Advertisement (Knotenbekanntmachung)
- Acknowledgement (Empfangsbestätigung)
- Returned Path (Rückpfad)
- Request (Anfrage – enthält Ziel-/Quell-Hashes + MAC)
- Response (Antwort auf REQ oder ANON_REQ)
- Plain Text Message (Klartextnachricht)
- Anonymous Request (Anonyme Anfrage)
- Group Text Message (Gruppentext-Nachricht, unverifiziert)
- Group Datagram (Gruppen-Datagramm, unverifiziert)
- Multi-Part Packet (Mehrteiliges Paket)
- Control Data Packet (Steuerdatenpaket)
- Custom Packet (benutzerdefiniertes Paket – rohe Bytes, eigene Verschlüsselung)
Dieses Dokument beschreibt die Struktur jedes einzelnen dieser Payload-Typen.
HINWEIS: Alle 16- und 32-Bit-Ganzzahlfelder sind im Little-Endian-Format (niedrigstwertiges Byte zuerst) gespeichert.
Wichtige Konzepte
- Node Hash (Knoten-Hash): Das erste Byte des öffentlichen Schlüssels eines Knotens.
Node Advertisement (Knotenbekanntmachung)
Dieser Payload-Typ informiert Empfänger darüber, dass ein Knoten existiert, und liefert Informationen über den Knoten.
| Feld | Größe (Bytes) | Beschreibung |
|---|
| public key | 32 | Öffentlicher Ed25519-Schlüssel des Knotens |
| timestamp | 4 | Unix-Zeitstempel der Bekanntmachung |
| signature | 64 | Ed25519-Signatur über öffentlichen Schlüssel, Zeitstempel und App-Daten |
| appdata | Rest des Payloads | Optional, siehe unten |
Appdata
| Feld | Größe (Bytes) | Beschreibung |
|---|
| flags | 1 | Gibt an, welche der folgenden Felder vorhanden sind (siehe unten) |
| latitude | 4 (optional) | Dezimaler Breitengrad multipliziert mit 1.000.000, als Ganzzahl |
| longitude | 4 (optional) | Dezimaler Längengrad multipliziert mit 1.000.000, als Ganzzahl |
| feature 1 | 2 (optional) | Reserviert für zukünftige Verwendung |
| feature 2 | 2 (optional) | Reserviert für zukünftige Verwendung |
| name | Rest der Appdata | Name des Knotens |
Appdata Flags
| Wert | Name | Beschreibung |
|---|
0x01 | is chat node | Bekanntmachung für einen Chat-Knoten |
0x02 | is repeater | Bekanntmachung für einen Repeater (Weiterleitungsknoten) |
0x03 | is room server | Bekanntmachung für einen Raumserver |
0x04 | is sensor | Bekanntmachung für einen Sensorserver |
0x10 | has location | Appdata enthält Breiten-/Längengrad-Informationen |
0x20 | has feature 1 | Reserviert für zukünftige Verwendung |
0x40 | has feature 2 | Reserviert für zukünftige Verwendung |
0x80 | has name | Appdata enthält einen Knotennamen |
Acknowledgement (Empfangsbestätigung)
Eine Bestätigung, dass eine Nachricht empfangen wurde. Bei Returned-Path-Nachrichten kann eine Empfangsbestätigung auch im „Extra"-Payload mitgesendet werden (siehe Returned Path), anstatt als separates Bestätigungspaket verschickt zu werden. CLI-Befehle lösen keine Empfangsbestätigungen aus – weder als eigenes Paket noch als Extra-Payload.
| Feld | Größe (Bytes) | Beschreibung |
|---|
| checksum | 4 | CRC-Prüfsumme über Nachrichtenzeitstempel, Text und öffentlichen Schlüssel des Absenders |
Returned Path, Request, Response und Plain Text Message
Returned Path (Rückpfad), Request (Anfrage), Response (Antwort) und Plain Text Message (Klartextnachricht) verwenden alle dasselbe Grundformat. Details zum Klartext-Inhalt des jeweiligen Chiffretexts finden sich in den nachfolgenden Unterabschnitten.
| Feld | Größe (Bytes) | Beschreibung |
|---|
| destination hash | 1 | Erstes Byte des öffentlichen Schlüssels des Zielknotens |
| source hash | 1 | Erstes Byte des öffentlichen Schlüssels des Quellknotens |
| cipher MAC | 2 | MAC (Message Authentication Code) für die verschlüsselten Daten im nächsten Feld |
| ciphertext | Rest des Payloads | Verschlüsselte Nachricht, Details siehe Unterabschnitte unten |
Returned Path (Rückpfad)
Returned-Path-Nachrichten beschreiben die Route, die ein Paket vom ursprünglichen Absender genommen hat. Empfänger senden Returned-Path-Nachrichten an den Absender der Originalnachricht zurück.
| Feld | Größe (Bytes) | Beschreibung |
|---|
| path length | 1 | Länge des nächsten Feldes |
| path | siehe oben | Eine Liste von Node-Hashes (jeweils ein Byte pro Knoten) |
| extra type | 1 | Typ des zusätzlich mitgesendeten Payloads, z. B. Acknowledgement oder Response. Verwendet dieselben Werte wie im Paketformat |
| extra | Rest der Daten | Inhalt des zusätzlich mitgesendeten Payloads, folgt demselben Format wie die in diesem Dokument definierten Hauptinhalte |
Request (Anfrage)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Absenderzeit (Unix-Zeitstempel) |
| request data | Rest des Payloads | Anwendungsspezifischer Anfrage-Inhalt |
Für die gängigen Chat-/Server-Hilfsfunktionen in BaseChatMesh sind derzeit folgende Request-Typ-Werte definiert:
| Wert | Name | Beschreibung |
|---|
0x01 | get stats | Statistiken eines Repeaters oder Raumservers abrufen |
0x02 | keepalive | Keep-Alive-Anfrage für aufrechterhaltene Verbindungen |
Get Stats
Ruft Informationen über den Knoten ab, die unter anderem Folgendes umfassen können:
- Batteriestand (in Millivolt)
- Aktuelle Länge der Sendewarteschlange
- Aktuelle Länge der freien Warteschlange
- Letzter RSSI-Wert (Empfangssignalstärke)
- Anzahl empfangener Pakete
- Anzahl gesendeter Pakete
- Gesamte Sendezeit / Airtime (in Sekunden)
- Gesamte Betriebszeit / Uptime (in Sekunden)
- Anzahl der als Flood gesendeten Pakete
- Anzahl der direkt gesendeten Pakete
- Anzahl der als Flood empfangenen Pakete
- Anzahl der direkt empfangenen Pakete
- Fehler-Flags
- Letzter SNR-Wert (Signal-Rausch-Verhältnis)
- Anzahl der Duplikate bei direkten Routen
- Anzahl der Duplikate bei Flood-Routen
- Anzahl geposteter Nachrichten (?)
- Anzahl der Post-Pushes (?)
Get Telemetry Data
Nicht in BaseChatMesh definiert. Sensor- und anwendungsspezifische Anfrage-Payloads können von übergeordneter Firmware implementiert werden.
Get Telemetry
Nicht in BaseChatMesh definiert.
Get Min/Max/Ave (Sensorknoten)
Nicht in BaseChatMesh definiert.
Get Access List
Nicht in BaseChatMesh definiert.
Get Neighbors
Nicht in BaseChatMesh definiert.
Get Owner Info
Nicht in BaseChatMesh definiert.
Response (Antwort)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| content | Rest des Payloads | Anwendungsspezifischer Antwort-Inhalt |
Der Inhalt einer Response besteht aus opaken Anwendungsdaten (d. h. die Struktur wird von der jeweiligen Anwendung bestimmt). Es gibt kein allgemeines Response-Format über den oben gezeigten verschlüsselten Payload-Wrapper hinaus.
Plain Text Message (Klartextnachricht)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Sendezeit (Unix-Zeitstempel) |
| txt_type + attempt | 1 | Die oberen sechs Bits enthalten den txt_type (siehe unten), die unteren zwei Bits die Versuchsnummer (0–3) |
| message | Rest des Payloads | Der Nachrichteninhalt, siehe nächste Tabelle |
txt_type
| Wert | Beschreibung | Nachrichteninhalt |
|---|
0x00 | Klartextnachricht | Der Klartext der Nachricht |
0x01 | CLI-Befehl | Der Befehlstext der Nachricht |
0x02 | Signierte Klartextnachricht | Die ersten vier Bytes sind das Präfix des öffentlichen Schlüssels des Absenders, gefolgt von der Klartextnachricht |
Anonymous Request (Anonyme Anfrage)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| destination hash | 1 | Erstes Byte des öffentlichen Schlüssels des Zielknotens |
| public key | 32 | Öffentlicher Ed25519-Schlüssel des Absenders |
| cipher MAC | 2 | MAC für die verschlüsselten Daten im nächsten Feld |
| ciphertext | Rest des Payloads | Verschlüsselte Nachricht, Details siehe unten |
Room Server Login (Raumserver-Anmeldung)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Absenderzeit (Unix-Zeitstempel) |
| sync timestamp | 4 | Zeitstempel des Absenders für „Nachrichten seit Zeitpunkt X synchronisieren" |
| password | Rest der Nachricht | Passwort für den Raum |
Repeater/Sensor Login (Repeater-/Sensor-Anmeldung)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Absenderzeit (Unix-Zeitstempel) |
| password | Rest der Nachricht | Passwort für den Repeater/Sensor |
Repeater – Regions Request (Regionen-Anfrage)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Absenderzeit (Unix-Zeitstempel) |
| req type | 1 | 0x01 (Unter-Anfragetyp) |
| reply path len | 1 | Pfadlänge für die Antwort |
| reply path | (variabel) | Antwortpfad |
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Absenderzeit (Unix-Zeitstempel) |
| req type | 1 | 0x02 (Unter-Anfragetyp) |
| reply path len | 1 | Pfadlänge für die Antwort |
| reply path | (variabel) | Antwortpfad |
Repeater – Clock and Status Request (Uhrzeit- und Statusanfrage)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| timestamp | 4 | Absenderzeit (Unix-Zeitstempel) |
| req type | 1 | 0x03 (Unter-Anfragetyp) |
| reply path len | 1 | Pfadlänge für die Antwort |
| reply path | (variabel) | Antwortpfad |
Group Text Message (Gruppentext-Nachricht)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| channel hash | 1 | Erstes Byte des SHA256-Hashs des gemeinsamen Kanalschlüssels |
| cipher MAC | 2 | MAC für die verschlüsselten Daten im nächsten Feld |
| ciphertext | Rest des Payloads | Verschlüsselte Nachricht, Details siehe unten |
Der im Chiffretext enthaltene Klartext entspricht dem Format, das unter Plain Text Message (Klartextnachricht) beschrieben ist. Konkret besteht er aus einem vier Byte langen Zeitstempel, einem Flags-Byte und der eigentlichen Nachricht. Das Flags-Byte ist in der Regel 0x00, da es sich um eine „Klartextnachricht" handelt. Die Nachricht hat die Form : (z. B. user123: Bin unterwegs).
Group Datagram (Gruppen-Datagramm)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| channel hash | 1 | Erstes Byte des SHA256-Hashs des gemeinsamen Kanalschlüssels |
| cipher MAC | 2 | MAC für die verschlüsselten Daten im nächsten Feld |
| ciphertext | Rest des Payloads | Verschlüsselte Daten, Details siehe unten |
Die im Chiffretext enthaltenen Daten verwenden das folgende Format:
| Feld | Größe (Bytes) | Beschreibung |
|---|
| data type | 2 | Kennung für den Datentyp (siehe number_allocations.md) |
| data len | 1 | Länge der Daten in Bytes |
| data | Rest des Payloads | Abhängig vom Datentyp |
Control Data (Steuerdaten)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| flags | 1 | Die oberen 4 Bits enthalten den sub_type (Untertyp) |
| data | Rest des Payloads | Üblicherweise unverschlüsselte Daten |
DISCOVER_REQ (sub_type)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| flags | 1 | 0x8 (obere 4 Bits), prefix_only (niedrigstes Bit) |
| type_filter | 1 | Bit-Maske für jeden ADV_TYPE_* |
| tag | 4 | Vom Absender zufällig generierter Wert |
| since | 4 | (Optional) Epoch-Zeitstempel (standardmäßig 0) |
DISCOVER_RESP (sub_type)
| Feld | Größe (Bytes) | Beschreibung |
|---|
| flags | 1 | 0x9 (obere 4 Bits), node_type (untere 4 Bits) |
| snr | 1 | Vorzeichenbehafteter Wert, SNR×4 |
| tag | 4 | Vom DISCOVER_REQ zurückgespiegelter Tag-Wert |
| pubkey | 8 oder 32 | Knoten-ID (vollständig oder nur Präfix) |
Custom Packet (Benutzerdefiniertes Paket)
Benutzerdefinierte Pakete haben kein festgelegtes Format.
