Flood-Payload: Was steckt drin?
Die Payload-Struktur hängt davon ab, welcher Payload-Typ im Header steht. Bei Flood-Nachrichten sind das vor allem vier Typen:
1. ADVERT – „Hallo, hier bin ich!" (Typ 0x04)
Das ist wie eine Visitenkarte, die ein Knoten ins Netz wirft, um sich bekannt zu machen. Der Advert besteht aus drei Abschnitten:
| Feld | Grösse | Was ist das? |
|---|---|---|
| src_hash | 1 Byte | Kurzadresse des Absenders – wie deine Hausnummer |
| node_info | variabel | Die eigentliche “Visitenkarte”: Knoten-ID, Position, Fähigkeiten (z.B. “Ich bin ein Repeater”) |
| MAC | 2 Bytes | Digitale Unterschrift (abgekürzt aus HMAC-SHA256) – wie ein Siegel, das beweist: “Das kommt wirklich von mir” |
Nicht verschlüsselt, aber signiert – jeder darf es lesen, aber niemand kann es fälschen.
Alltagsvergleich: Stell dir vor, du gehst in einen Raum und rufst laut: “Ich bin ‘Hans’ ich stehe hier, und ich kann Nachrichten weiterleiten!”
Adverts kannst du vom Companion manuell aussenden. Repeater sowie ‘Desk’-Geräte senden Adverts in einstellbaren Zeitabständen aus.
2. GRP_TXT – Gruppen-Textnachricht (Typ 0x05)
Das ist wie eine Nachricht an eine WhatsApp-Gruppe – alle Mitglieder bekommen den gleichen Text. Sie besteht aus vier Abschnitten.
| Feld | Grösse | Was ist das? |
|---|---|---|
| channel_hash | 1 Byte | Kurzadresse der Gruppe/des Kanals – wie eine Raumnummer |
| src_hash | 1 Byte | Wer hat die Nachricht geschickt? |
| MAC | 2 Bytes | Prüfsumme – stimmt der Inhalt? |
| encrypted_data | variabel | Verschlüsselter Inhalt |
Der verschlüsselte Inhalt enthält nach dem Entschlüsseln:
┌──────────────┬──────────────────────┐
│ timestamp │ "Name: Nachricht" │
│ (4 Bytes) │ (Text als String) │
└──────────────┴──────────────────────┘
Beispiel: Nach Entschlüsselung steht da z.B.: "Paul: Hallo zusammen!"
Verschlüsselt mit dem gemeinsamen Gruppen-Schlüssel (ECDH Shared Secret).
Alltagsvergleich: Du schreibst eine Nachricht auf ein Blatt Papier, steckst es in einen verschlossenen Umschlag mit der Raumnummer drauf, und wirfst es in den Raum. Nur wer den Schlüssel zum Raum hat, kann es lesen.
3. GRP_DATA – Gruppen-Datenpaket (Typ 0x06)
Genau wie GRP_TXT, aber statt Text werden binäre Daten verschickt (z.B. Sensordaten, kleine Dateien).
┌────────────────┬────────────┬───────────┬─────────────────────┐
│ channel_hash │ src_hash │ MAC │ encrypted_data │
│ (1 Byte) │ (1 Byte) │ (2 Bytes) │ (variabel) │
└────────────────┴────────────┴───────────┴─────────────────────┘
Nach Entschlüsselung:
┌──────────────┬──────────────┐
│ timestamp │ blob (Daten)│
│ (4 Bytes) │ (variabel) │
└──────────────┴──────────────┘
Alltagsvergleich: Statt eines Briefs steckst du ein USB-Stick in den Umschlag – gleicher Umschlag wie bei GRP_TEXT, anderer Inhalt.
4. TRACE – Pfadverfolgung (Typ 0x09)
Das ist das Diagnose-Werkzeug – wie ein Paketverfolgungs-Link bei der Post. Damit kannst du sehen, welchen Weg eine Nachricht durchs Netz genommen hat.
┌────────────┬─────────────────┬───────────┐
│ src_hash │ trace_data │ MAC │
│ (1 Byte) │ (variabel) │ (2 Bytes) │
└────────────┴─────────────────┴───────────┘
| Feld | Grösse | Was ist das? |
|---|---|---|
| src_hash | 1 Byte | Wer hat die Trace-Anfrage gestartet? |
| trace_data | variabel | Sammelt an jedem Hop die SNR-Werte (Signalqualität) – wie ein Stempel an jedem Postamt |
| MAC | 2 Bytes | Prüfsumme |
Nicht verschlüsselt – denn jeder Repeater muss seine Info hinzufügen können.
Alltagsvergleich: Du schickst einen Brief los und legst fest: “Jeder Briefträger, der den Brief anfasst, soll seinen Namen und die Uhrzeit draufschreiben!”
5. Übersicht auf einen Blick
| Typ | Name | Verschlüsselt? | Payload-Aufbau |
|---|---|---|---|
0x04 |
ADVERT |  (signiert) |
src_hash + node_info + MAC |
0x05 |
GRP_TXT |  |
channel_hash + src_hash + MAC + enc(timestamp + "name: msg") |
0x06 |
GRP_DATA | |
channel_hash + src_hash + MAC + enc(timestamp + blob) |
0x09 |
TRACE | |
src_hash + trace_data + MAC |