Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howto_setup_repeater [2026/08/04 15:22] – bmke-a-2345-tdeck
+++ howto_setup_repeater [2026/08/17 17:32] (aktuell) – bmke-a-2345-tdeck
@@ Zeile 79: / Zeile 79: @@
 # Empfang --rxdelay--> Verarbeitung (dedup/regions) --rnd(txdelay)--> Senden
-set txdelay 2 # Sekunden für random delay für Flood
+set txdelay 2 # Faktor für random delay für Flood
 # Empfehlung:
 #   0.5 für kleine Rooftop Repeater
@@ Zeile 148: / Zeile 148: @@
 "set txdelay"
-Delay, wird in Sekunden angegeben. Vor dem Senden wird ein zufälliges Delay zwischen 0 und dem eingestellten Wert gewürfelt. Da in Meshcore grundsätzlich der "schnelleste" Pfad gewinnt, ist das txdelay geeignet um "teure" Knoten unattraktiv zu machen. Da jeder Node für sich die airtime rechnet, sollten daher beim Lernen eines Pfades kritischere Nodes entlastet werden. Das txdelay soll daher dazu führen, dass wenn ein Client einen Pfad (für Direct-Nachrichten) lernt nach Möglichkeit Alternativen gelernt werden. Dies soll dazu dienen die Airtime-Verbrauch von Knoten an neuralgischen Punkten gering zu halten.
+Delay, wird als Faktor der benötigten Sendezeit angegeben. Vor dem Senden wird ein zufälliges Delay zwischen 0 und dem eingestellten Wert gewürfelt. Da in Meshcore grundsätzlich der "schnelleste" Pfad gewinnt, ist das txdelay geeignet um "teure" Knoten unattraktiv zu machen. Da jeder Node für sich die airtime rechnet, sollten daher beim Lernen eines Pfades kritischere Nodes entlastet werden. Das txdelay soll daher dazu führen, dass wenn ein Client einen Pfad (für Direct-Nachrichten) lernt nach Möglichkeit Alternativen gelernt werden. Dies soll dazu dienen die Airtime-Verbrauch von Knoten an neuralgischen Punkten gering zu halten.
 Siehe https://w6hs.net/meshcore-repeater-deployment-timing-considerations-for-wide-area-networks/
@@ Zeile 168: / Zeile 168: @@
 "set loop.detect" ist eine Ergänzung zur Deduplizierung. Die Deduplizierung prüft ACKs getrennt von Messages. Bei Messages wird für die Deduplizierung ein Hash über den Content und ein Headerfeld gebildert. Aktuell werden dafür die letzten 128 dieser Hashes gespeichert ([[https://github.com/meshcore-dev/MeshCore/blob/c940ea5f305df87c4ea215d74e522b64c22c66e9/src/helpers/SimpleMeshTables.h#L9|MAX_PACKET_HASHES=128]], [[https://github.com/meshcore-dev/MeshCore/blob/c940ea5f305df87c4ea215d74e522b64c22c66e9/src/helpers/SimpleMeshTables.h#L43|hasSeen]], [[https://github.com/meshcore-dev/MeshCore/blob/c940ea5f305df87c4ea215d74e522b64c22c66e9/src/Packet.cpp#L41|calculatePacketHash]], [[https://github.com/meshcore-dev/MeshCore/blob/c940ea5f305df87c4ea215d74e522b64c22c66e9/src/MeshCore.h#L6|MAX_HASH_SIZE=8]]). Die Deduplizierung ist daher sehr leistungsfähig und mit 8 Byte deutlich kollissionsresistenter als die Loop-Detection. Die Loop-Detection kommt daher zum Tragen, wenn der Repeater 128 einzigartige Pakete gesehen hat zwischen dem Senden von dem Paket und dem erneuten Empfang oder sich Payload-Type oder Payload von dem Paket selbst ändert. Realistisch betrachtet reduziert das Setting daher als weitere Verteidigungslinie von Duplikaten falls die Deduplizierung nicht funktioniert und es werden Pfade mit zu vielen Kollissionen im Pfad unterdrückt wodurch das Debuggen erleichtert wird. Das Setting "strict" scheint bei der Menga an Kollssionen bei 1b Pfaden nicht zielführend.
-"rxdelay" das rxdelay wird über einen Faktor abhängig von der Empfangsqualtität berechnet welcher mit der Airtime multipliziert wird. Geht man daher von einem Tiering durch txdelay der anderen Devices aus, so sollten wir im worst Case ein Duplikat innerhalb von 500ms sehen. Der Faktor wurde daher so gewählt, dass Pakete die gerade noch so empfangen werden konnten (score=0,1) ein Advert (150ms airtime) mit einem delay von knapp über 500ms delayed werden. Kleinere Pakete sollten auch kein Problem sein, da txdelay gleichmäßig verteilt ist - daher sollte in der Hälfte aller Fälle ein Rooftop-Repeater der ein txdelay von 500ms konfiguriert hat das Paket bereits nach 250ms gesendet haben.
+"rxdelay" das rxdelay wird über einen Faktor abhängig von der Empfangsqualtität berechnet welcher mit der Airtime multipliziert wird. Der Faktor wurde daher so gewählt, dass Pakete die gerade noch so empfangen werden konnten (score=0,1) ein Advert (150ms airtime) mit einem delay von knapp über 500ms delayed werden.
 "password" für die Administration wird im Klartext gespeichert und sollte aufgrund der exponierten Natur mancher Repeater (bspw. könnte das Passwort ausgelesen werden wenn der Repeater gestohlen wird oder andere Software geflashed wird) sowie Fehler in der Implementierung der Kryptographie als kompromittiert betrachtet werden.