Das ist alles vollkommen nachvollziehbar. Ich unterstelle hier kein böses Blut oder Miesepeterei. Deshalb war meine Kernfrage auch, welche technischen Lösungen es gibt, aus purem Unwissen mal folgende Fragen, die sich in meinem Kopf wälzen:
Notfallnetze bewusst auf einer eigenen Frequenz betreiben? Oder ein Emergency QoS Mode im Protokoll.
Linkstrecken für sehr gut positionierte Repeater als Backbone, zum Beispiel auf einer eigenen Frequenz, mit Bridge in lokale Meshes. Einem Pinger würde es zum Beispiel reichen, wenn er weiss, dass er die Landesbackbone erreicht und einen Status erhält, dass die Landesbackbone in Ordnung ist?
Generell mehr Segmente, die untereinander zwar föderieren, aber den Traffic lokal halten, ohne dass jemand aus Rücksicht nur innerhalb der Region senden muss?
“Bessere” Firmware-Defaults, die das Netz vor Dummheiten schützen?
Definierte Gateways statt Voll-Mesh, also wenige, gut geplante Übergänge zwischen Regionen statt jeder mit jedem. Diese könnten z.B. auch über Wi-Fi Richtstrecken realisiert werden, wie es z.B. https://www.arednmesh.org/ oder HAMNET verfolgt.
Ein Experimentierfeld muss niederschwellig bleiben. Hier kommt mir auch nix in den Sinn. «Dä Füüfer und s Weggli» geht einfach nicht überhein
Ich interessiere mich für technische Lösungen & finde euren Input sehr lehrreich und bin Dankbar für so ausführliche Darlegungen!
Echt cool, da kommt so viel Tolles, Spannendes zusammen und ich finde es sehr wertvoll, dass wir mit Respekt aufeinander zugehen - zusammen einen Weg gehen wollen, um mit kleinen Radios etwas ganz Grosses zu machen.
MeshCore ist ein Projekt einer kleinen Gruppe, auf der Welt verteilter Menschen, Scott Powell hat sie mit seiner Idee/Philosophie von MeshCore begeistert. Hier der Link zu seinem ‘Jahresrückblick’. Er führt dort auch die engsten Kollegen auf. Die Kommunikation mit den Entwicklern ist sehr einfach/flach über Discord.
Bisher hat das Entwicklerteam über die Vorschläge der Benutzer diskutiert und viele wurden in die Roadmap aufgenommen später in Firmware-Updates eingebaut. Auf Rückmeldungen wird bei kleineren Bugs sofort reagiert und die Korrekturen erfolgen oft schon innerhalb einer Woche.
Auch wir haben uns im letzten Jahr entwickelt. Interessierte haben sich gefunden. Jeder probierte aus. Lernte das System und seine Tücken kennen. Wir probierten aus, wie sich Repeater im Gelände verhalten, wo wir sie platzieren müssen, wie stabil Verbindungen sind, wie sich Nutzer verhalten, etc.
Dabei erkannten wir Schwachstellen, ‘Bedrohungen’ und lernen mit bescheidenen technischen und menschlichen Ressourcen zu arbeiten.
Wir haben zwei wesentliche Veränderungen moderiert: Umstellung auf Narrow und aktuell Einführung ‘Region-Scope’
Wir sind also etwa dort angelangt, wo es um die Abwägung von Bedürfnissen, um gemeinsame Werte und um die Unterscheidung vom Möglichen und vom Machbarn geht. Dafür bauen wir grad eine Diskussionskultur auf..
Wir müssen klar formulieren können:
welche Bedürfnisse (allgemeine/partikuläre) MeshCore in der Schweiz abdecken soll.
welche Tools wir bereits (Repeater, Companion, Roomserver) haben und wie wir diese wirkungsvoll einsetzen können.
wie wir das Netz auf Grund unserer bisherigen und zukünftigen Erfahrungen bauen und stetig weiterentwickeln wollen.
was unsere Anliegen sind, die durch die Entwickler softwareseitig implementiert werden sollten.
und…
und…
Dies alles kommt zum alltäglichen ‘Geschäft’ dazu. Aber wir haben auch ganz starke, eigene Ressourcen! Und wir sind Menschen mit unterschiedlichen Fähigkeiten, Kenntnissen, Talenten und Beziehungen. Vieles ist da - brauchen wir es!
Vielleicht sollten wir die Sache öffnen und hier im Forum unter einem neuen Thema weiter diskutieren? Was denkt ihr?
Fände ich gut. Fände es sehr sinnvoll, wenn wir Vorschläge nicht nur zum Protokoll, sondern auch zur Firmware, zur Infrastruktur sowie zu praxisnahen und bedürfnisgerechten Guidelines gemeinsam erarbeiten. Wichtig wäre dabei, dass wir die Themen sowohl fachlich fundiert als auch aus der Nutzerperspektive breit diskutieren, strukturieren und weiterentwickeln. Sodass auch mit den verschiedensten Hintergründen und auch sehr unterschiedlichem technischen Wissensständen eine gemeinsame Stossrichtung entsteht, welche wir in Richtung globaler Community weitertragen und formulieren.
Auch wenn das Forum noch klein ist, sollten schon ein guter Teil der Interessen am Netz vertreten sein. Zumindest der Leute, die Bereit sind sich einer Diskussion zu stellen und sich nicht direkt zum Rückzug entscheiden.
Ein möglicher erster Aufhänger könnte die Frage sein, warum es aktuell so viele Ping-Pong-Messages gibt. Könnte das ein Hinweis auf eine architektonische Schwäche im nationalen oder im internationalen Meshcore Netz sein? Wie skaliert man sowas richtig? Wenn wir hier gemeinsam die Ursachen analysieren, lassen sich daraus vermutlich konkrete und belastbare Verbesserungsvorschläge/Lösungen ableiten welche dann anstelle von Dokumentationen vom Status Quo sich auch kompakt und verständlcih formulieren lassen.
Wie ihr aus obigen Beiträgen entnehmen könnt, möchten wir in der Community einen Platz um über Analysen, Massnahmen, Planungen bezüglich Netzausbau, Wünsche an die Entwickler, etc. zu diskutieren. Der Platz sollte öffentlich sein.
Dafür wäre m.E. eine neue ‘Kategorie’ anzulegen, welche wir nach Bedarf mit Themen strukturieren können.
Guten Abend zusammen
Danke für eure interessante und in Neudeutsch “unaufgeregte” Diskussion. Es ist gut zu sehen, dass die Argumente beider Seiten aufgenommen werden und man gemeinsam versucht Lösungen zu finden. Der Ansatz mit den Regionen kann ja vielleicht schon eine Entlastung bringen.
Dazu eine Überlegung:
Gestern brachte ich ein Paket zur Post. Ich musste eine Adresse angeben, denn ich will ja nicht, dass dieses Paket von Poststelle zu Poststelle quer durch Europa geschickt wird und niemand weiss so recht, für wen es eigentlich ist.
Also: Wäre es abwegig, als letzte Lösung - falls wirklich nötig - eine Softwareveränderung vorzunehmen, bei der nur Messages MIT Scope angenommen werden. Jeder muss sich dann überlegen, wie weit - oder in welchem Raum - er die Message senden will. Das müsste auch für Pings und Direktmeldungen gelten. Auch die Abfrage des eigenen Repeaters müsste so geregelt werden. Ein Ping-Freund könnte so immer noch Europaweit seine Pings versenden, jeder Repeaterbetreiber könnte aber Weiterverbreitungen nach Bedarf einschränken. Das wäre die konsequente Weiterentwicklung des Regionengedankens und würde jeden User zwingen, zuerst nachzudenken, wohin er seinen Post senden will.
Vielleicht habe ich aber Wesentliches übersehen, da ich die Komplexität des Systems nicht immer ganz erfassen kann.
Hallo Frazo,
Ich stimme Dir voll und ganz bezüglich architektonischer Schwäche zu. Aus meiner Sicht ist das Regionenkonzept ein zunächst vernünftig aussehender Ansatz mit dem man nun versucht etwas nachzubessern woran man ursprünglich nicht gedacht hat.
Ich bin klar der Meinung, dass Regionen und Filter grundsätzlich gewissen Datenverkehr einschränken kann. Das aber meist mit einem gewissen Trade-off, der nicht immer akzeptierbar ist.
Ich denke, dass bei einem Funkmesh solche Konzepte wie man sie von Kabelbasierten Netzen her kennt (Domain, Sub-Domain, IP-Netze und Sub-Netze) gestützt durch einen Namensservice (DNS) grundsätzlich nur beschränkt funktionieren können. Im Gegensatz zu Kabelnetzen werden gut gelegene und inkorrekt konfigurierte Teilnehmer immer regionenübergreifend das Konzept untergraben. Insbesondere in der Schweiz, wo wir sehr hoch gelegene Repeater haben (werden) und in Grenzgebieten wird Funkverkehr im Rahmen der Reichweite eines Nodes generiert wo er eigentlich nicht sollte. Dann hängt die Weiterpropagierung vom Verhalten eines Nodes ab. Leitet dieser alles weiter, wird erneut (im Rahmen der Reichweite des repetierenden Nodes) das Signal weiter verbreitet und belastet unnötig in seinem Gebiet das Netz.
Wenn dies mit konfigurativen Massnahmen verhindert werden soll, endet das Mesh unweigerlich in einem Plan-Mesh (im Sinne von geplant bis ins letzte Detail). Ich denke, dass dies ohne ein organisatorisches Vehikel wie ein Verein, Verband oder sonstige Organisationsform nur schlecht umgesetzt werden kann. Sobald aber eine Organisation ins Leben gerufen wird, hängt der Erfolg von freiwilligen Teilnehmern und Helfern ab. Wenn ich sehe, wie wenig Leute in diesen Zeiten noch Verantwortung in einem Verein übernehmen wollen und dann noch möglichst unparteiisch agieren sollten, gebe ich diesem Vorgehen eher geringe Erfolgschancen. Dass Behörden solch zentral-planerische Arbeiten übernehmen würden viele auch nicht wollen. Es soll ja möglichst ein freies sich selbst-organisierendes Mesh sein.
Mit anderen Worten, ich denke nicht, dass man ein Funknetz mit einem kabelbasierten Firmen-LAN, WAN oder auch nicht mit dem Internet vergleichen kann und ähnliche Vorgehen darin erfolgreich umsetzen kann. So gesehen, hat Meshtastic in diesem Punkt mit der selbst-auferlegten Beschränkung von 7 Hops vielleicht die Problematik in ihren Simulationen schon lange erkannt.
Ein mehr- (um nicht zu sagen viel-) versprechenderes Vorgehen könnte in Zukunft künstliche Intelligenz sein, die den Meshverkehr selbständig analysiert. Dazu würden aber wohl stärkere Geräte mit höherem Stromverbrauch benötigt. Weiss jemand wo solche Software-Architekture-Diskussionen geführt werden und nachgelesen werden können?
Herzlich willkommen in der Community. Danke für deinen Beitrag. Funknetze werden bei uns von der Swisscom betrieben. Es gibt eine Karte, welche die bestehenden Richtfunkverbindungen zeigt: Maps of Switzerland - Swiss Confederation - map.geo.admin.ch
Ich nehme sie zur Hand, wenn ich Standorte für Repeater auskundschafte. Aufgepasst: Den 868MHz-Repeater muss man in einer gewissen Entfernung der Antennenstandorte der Swisscom platzieren.
Ich denke, @HB9DTZ, Christoph (er betreut das Netz der Amateurfunkergruppe HB9BG und hat zusammen mit @Rolfy-HB9ODI die TRANSALP - Verbindung über das Jungfraujoch realisiert) kann dir deine konkreten Fragen bezüglich der Auslegung von Funknetzen beantworten.
Eine Backbone ist in Funknetzen keine Besonderheit, kein Bezug zu Kabelnetzten etc.. Siehe z.B. im “kleinen Scale”, resp artverwandt als Beispiel: IEEE 802.11s
Will sagen. Backbone auf eigner Frequenz, Mesh bleibt wo es ist, aber Repeater der Backbone bekommen z.B. eine besondere Gateway Rolle. Habe im Firmware Source Code auch gefunden, dass es bereits die Möglichkeit für Briding zwischen Repeatern gibt. Alles denkbar und machbar.
Hallo Paul,
Vielen Dank für deine Infos. Ich habe statt einem (zentral verwalteten) Funknetz eigentlich ein Meshnetz gemeint. Ich hätte mich da genauer ausdrücken sollen. Ich würde acuh nicht so weit gehen und ein Eiinbezug von Funknetzbetreiber oder Beörden vorschlagen. Viel mehr bin eigentlich an einem freien Ad-Hock-Mesh interessiert, in dem sich die Teilnehmer entweder möglichst selber organisieren oder dies soweit möglich vom System automatisiert wird.
Aber dennoch vielen Dank.
Frank
ich hatte kürzlich im #chtest geantwortet wie man sehen könnte welche Region gesetzt ist. In meiner Antwort hatte erwähnt dass dies im RX LOG ersichtlich ist.
ich habe mich dabei nicht 100% korrekt ausgedrückt.
Was ich sagen wollte: im RX log sind Transport Codes enthalten wenn eine Region gesetzt ist, dann wird dies auch als “Transport_Flood Group_TEXT gelistet, anstelle Flood Group_Text.
Der Transport Code wird aus einem Transport_Key und dem Messageinhalt gerechnet, deshalb ist dieser für jede Message unterschiedlich, auch wenn derselbe Channel und dieselbe Region genutzt werden. Mann kann deshalb nicht einfach auf die genutzte Region schliessen sondern sieht lediglich ob irgendeine Region gesetzt ist.
Der Repeater welcher genau die verwendet Region konfiguriert hat, hat jedoch genügend Informationen um zu prüfen ob der verwendete Scope in der Message in seiner Regionstabelle enthalten ist.
Why Transport Codes Change Each Time - THE ANSWER!
The transport code is calculated using HMAC-SHA256 with:
The Region Key (16 bytes, derived from region name like “us-ca”)
Packet Payload Type (1 byte, e.g., PAYLOAD_TYPE_TXT_MSG)
The Entire Packet Payload (variable length - THIS IS THE KEY!)
This is why you see different transport codes for the same scope:
The payload contains:
Message content (different each time)
Timestamps (different each time)
Nonces/random data (different each time)
Encryption data (different each time)
So even with the same region/scope, each message produces a different transport code because the payload is different!
How Region Keys Are Generated
For a region like “us-ca”:
cpp
void TransportKeyStore::getAutoKeyFor(uint16_t id, const char* name, TransportKey& dest) {
// For auto hashtag regions (most common case)
SHA256 sha;
sha.update(name, strlen(name)); // e.g., "#us-ca"
sha.finalize(&dest.key, sizeof(dest.key)); // 16-byte key
}
The region key = SHA256(“#us-ca**”)** (first 16 bytes)
How Repeaters Match Transport Codes
When a repeater receives a packet:
Extracts transport code from packet header: packet->transport_codes[0]
For each configured region, recalculates what the code SHOULD be:
cpp
uint16_t expected_code = transport_key.calcTransportCode(packet);
```
3. **Compares**: If `expected_code == packet->transport_codes[0]`, it's a match!
4. **The magic**: Both sender and repeater use:
- Same region key (SHA256 of "#us-ca")
- Same packet payload (received packet data)
So they calculate the **same transport code**, even though it's different for each message!
### Complete Flow Example
**Sender (with scope "us-ca"):**
```
1. Region key = SHA256("#us-ca") → [16 bytes]
2. Create packet with payload = "Hello, timestamp=12345, nonce=..."
3. Calculate: transport_code = HMAC-SHA256(key, payload_type + payload)
4. Result: transport_code = 0x3A7F (example)
5. Put 0x3A7F in packet->transport_codes[0]
6. Transmit packet
```
**Repeater (with region "us-ca" configured):**
```
1. Receive packet with transport_codes[0] = 0x3A7F
2. For region "us-ca": key = SHA256("#us-ca") → [same 16 bytes]
3. Calculate: expected = HMAC-SHA256(key, received_payload_type + received_payload)
4. Result: expected = 0x3A7F (same!)
5. Match! → Forward packet
```
**Next message with same scope:**
```
1. New payload = "Hi there, timestamp=12399, nonce=..."
2. Calculate: transport_code = HMAC-SHA256(key, new_payload)
3. Result: transport_code = 0x8B21 (DIFFERENT!)
4. But repeater can still verify it using same process
Why This Design is Brilliant
Security: Can’t replay old messages (code tied to exact payload)
Privacy: Region name not visible in packet (just a derived code)
Verification: Only repeaters with correct region key can verify
No collisions: Each message has unique code (from unique payload)
Hierarchical: Same mechanism works for parent/child regions
Summary
Your observation is correct: Same scope produces different transport codes each time.
The reason: Transport code = HMAC(region_key, payload), and the payload changes with every message.
How it still works: Repeaters recalculate the code using the same algorithm with their stored region key and the received payload data, so they can verify the code matches their configured region even though it’s different for every packet!
