Public-Key Byte Kollision beim Routing

[l5y]

Moin Meshcore Berlin,

gibt es Resourcen, wo man nachlesen kann was es mit dem ersten Byte des Public Keys beim Routing aufsich hat?

Ich verstehe, dass ich Routen setzen kann Ae, 13, b7, usw. aber ist das lediglich kosmetisch und betrifft micht das auch als Companion oder nur die Repeater?

Was sind die Implikationen?

[Timo_V]

Grundsätzlich kümmert sich das Mesh/MeshCore selbständig um das Routing.
In der Regel geht eine Nachricht erst per Flood raus: Alle Repeater geben die Nachricht an Alle Repeater weiter usw.. Chanal-Nachrichten gehen immer nur per Flood, da sie an die unbestimmte Allgemeinheit gerichtet sind.

Für Direktnachrichten oder Roomserver und andere 1-zu-1-Verbindungen: Kennt mein Client einen Pfad zu einen anderen Client (über Repeater Ae, 13 und b7) wird er zuerst versuchen die Nachricht über diesen Pfad zu zustellen, klappt das nicht, geht die Nachricht nochmal raus per Flood. Bei erfolgreicher Zustellung wird ein neuer Pfad gespeichert.

Zum Thema Dopplungen (Da Kollision bei LoRa oft für das auslöschen Paketen verwendet wird, wenn die Wellen sich überlagern, verwende ich nicht den Begriff "Kollision): Für das Routing ist ein Problem wenn z.B. der Prefix 13 zweimal in der Nähe vergeben ist, da die Erfolgreiche Zustellung immer noch möglich ist.
Nehmen wir an
Ae = Das Brandenburger Tor
13 = Das HumboldForum
13 = Der Teufelsberg
b7 = Kladow
Ich (Alice) bin mit meinem Client in der Nähe vom Brandenburger Tor und weiß, dass ich eine Verbindung zu Bob in Kladow habe. Meine Private Nachricht beinhaltet beim ersten Versuch diese Route. Deshalb geht die Nachricht vom Brandenburger Tor Node weiter mit der Info: als nächstes ist 13 dran davon fühlen sich nun das HumboldForum und der Teufelsberg angesprochen und geben die Nachricht weiter mit als nächstes ist B7 dran, das wird erfolgreich von Kladow gehört, und auch von den Nachbarn des HumboldForums, nur dort versand die Nachricht (oder geht im schlimmsten Falls an einen weiteren Doppelten B7) weiter.
Das ist aber trotzdem weniger Traffic, als wenn alle Nachrichten von allen an alle Repeater immer per Flood weiter geschickt werden.

Der entscheidenden Punkt bei den Dopplungen ist für die Nutzenden. Bob sieht bei meiner Nachricht den Pfad (Ae, 13, b7,) und bekommt dort angezeigt, dass die Nachricht bei "13" entweder über das HumboldForum oder den Teufelsberg gegangen ist.

Im Alltag relevant sind die Pfade bei der Remote Administration von Repeater und Roomservern, da muss ich oft dne Pfad Manuel entfernden, wenn ich mit meinem Client gerade an einem anderen Standort bin...

[l5y]

Ok, aber hat das in der Praxis spürbare Nachteile? Ich verstehe das so, dass wenn 13 doppelt vorhanden es, geht es "zwei Pfade" - was zwar unnötig wäre aber erstmal auch nichts schlechtes ist, oder?

[Timo_V]

Ja, das Routing hat kein Problem, es ist nur für die Nutzenden in eindeutig was passiert.

[wirehack7]

Im #test Kanal habe ich gesehen dass ein Bot zb auch den Befehl "prefix free" unterstützt und zeigt dann "freie" Prefixe an.
Mittels https://gessaman.com/mc-keygen kann man diese dann wohl generieren.

Gibt es eigentlich ein RFC zu dem genutzten Protokoll wo man sich reinlesen kann?

EDIT: sehe gerade https://bcm.deadsec.net/topic/7/online-tools-für-meshcore, da wurde es ja auch schon erwähnt
Auf einmal so viele neue Themen hier, nice!

[scotty]

Hat irgendwer einen Überblick, ob schon ausreichend Repeater auf F/W >= 1.14 sind, um auf 2-Byte-Prefixe umzuschalten?

[l5y]

Ich weiß nicht, ob es da eine Übersicht gibt, aber erfahrungsgemäß würde ich bei sowas immer mindestens ein Jahr warten.

Das mit den Regionen wurde auch viel zu schnell überstürzt.

[scotty]

Ich habe mir mal einen Überblick an meiner Position verschafft und die Prefix-Längen der letzten 4600 hier empfangenen Pakete gezählt:

• 1-byte: 3524 (76,6%)
• 2-byte: 1035 (22.5%)
• 3-byte: 41 (0.9%)

Diese Zahlen sagen natürlich nicht viel über die Repeater-F/W aus. Und es fehlen alle nicht-1-Byte Pakete, die von "alten" Repeatern verworfen wurden.