Meshcore firmware 1.14.0 has been released and introduces the new multi-byte path hash feature. What follows is a quick dump of information I have gathered directly from the developers.
A description of this feature can be found here Multi-byte paths
The sender decides what path hash size it wants to use and the repeater will respect that. If messages originates from the repeater it also gets do define the path hash size to use for the message (for example a flood advert)
Compatibility looks like this
v1.13.0 and older will forward 1-byte packets
v1.13.0 and older will drop 2-byte packets
v1.13.0 and older will drop 3-byte packets
v1.14.0+ will forward 1-byte packets
v1.14.0+ will forward 2-byte packets
v1.14.0+ will forward 3-byte packets
Using multi byte hash’s will decrease the hop count for your message.
1-byte = ~64 hops
2-byte = ~32 hops
3-byte = ~21 hops
So at the end of the day this feature is partly cosmetic and useful for getting a much better picture of the route, via repeaters, a message takes but it will also reduce some “duplicate” traffic to the extent where we have repeaters close to each other with the same first byte in their public key.
It is also being used in the new message loop detection feature which was rolled out in 1.14.0 but I am not sure we have seen this phenomenon here in Switzerland yet. My understanding is that its related to a mis-behaving or modified repeater.
Ich habe bereits seit es vor einigen Wochen im multibyte-paths Branch verfügbar war damit herumgespielt und finde dies eine supercoole Sache. Die Kollision des 1 Bytes hat ja praktisch verunmöglicht die Pfade des Verkehrs zu analysieren. Leider wird dies wohl nie komplett verschwinden.
Es war ja lange die Diskussion ob es als Breaking Change in einer V2 der Spec implementiert werden sollte oder so wie jetzt einigermassen Rückwärtskompatibel.
Das Problem momentan sehe ich in der Anforderung dass alle Repeater auf dem Pfad dies unterstützen müssen. Erfahrungsgemäss dauert es sehr lange bis alle Repeater auf v.1.14+ upgraded sind. Und auch dann werden Companions noch immer 1 Byte als Default Einstellung verwenden. Die Entscheidung als neuen Default 2Byte in der FW und APP zu setzten wird vermutlich leider nie getroffen werden. Einerseits weil nie ganz klar ist ob alle Repeater dies bereits unterstützen und auch weil diffuse Privacy Anforderungen dagegen sprechen.
Damit werden wir in Zukunft weiter mit dem 1Byte Overlap leben mĂĽssen.
Irgendwie sollt ein Verfallsdatum in der FW implementiert werden, so dass verhindert werden könnte dass alte FW Releases beliebig lange in Betrieb verbleibt.
I just want to mention that for the moment DO NOT update remote or had to access Repeaters. There are some bugs in 1.14 which can break OTA, Remote Admin and some other stuff…
Meine laufen aktuell noch auf 1 Byte, glaube das braucht noch etwas Zeit bis wesentlich mehr Repeater auf 1.14.1 laufen und man umstellen kann. Viele Repeater sind im Winter schlecht zugänglich.
Repater die Firmware 1.14.0 oder neuer haben wiederholen alle Packete, egal wieviel Byte.
Die Einstellungen “set path.hash.mode 2” hat nur einen Einfluss auf den Advert welcher der Repeater sendet. Somit hat das eigentlich keinen Einfluss auf die Funktion beim Weiterleiten von Nachrichten.
Grundsätzlich würde ich auf 2 Byte umstellen, halte das aber aktuell noch zu früh, wegen der min. Version von 1.14. Keine Ahnung wieviele Repeater auf der neusten version sind, nicht das wir da ausversehen das Mesh fragmentieren. Deshalb habe ich meinen noch nicht angepasst.
So richtig interessant werden 2Bytes Hashes erst sobald viele Repeater v.1.14 haben und dies auch fĂĽr Channel Messages verwendet werden kann.
Mich ärgern die Überlappungen der Repeater welche es verunmöglichen den Pfad welcher der Verkehr genommen hat zu visualisieren.
Ob der Repeater selbst Adverts mit 2Bytes sendet ändert an seiner Funktion nichts, er leitet weiterhin alle Pakete, egal ob 1,2 oder 3Byte Hash weiter.
Lediglich die eigenen Adverts werden von alten Repeatern nicht weitergeleitet. Aber Repeater Adverts hat es eh zu viele. Die Gefahr einer Fragmentierung besteht eigentlich nicht.
ich sehe bei mir bereits einigen Trafik mit 2Byte Hashes ankommen, noch nicht sehr viel aber die Adoption von v1.14 geht voran.
Schade dass der Entwickler des analyzers keine Zeit hat Support fĂĽr Regionen und Multibyte Path Hashes einzubauen.
I think it would be wise to wait a little longer. Personally I think 1.14.x is riddled with bugs so personally I would wait for a more stable release before migrating any difficult to access nodes to a newer version.
I am running a different Meshcore analytics package which has support for tracking multibyte traffic. Its only connected to my own observer so it does not see everything but you can have a look here https://console.swiss-mesh.pro to get an idea.
If I got everything right, the one and only negative impact when setting “set path.hash.mode 1“ on a repeater is that the 2-byte adverts it is sending out are not getting forwarded by repeaters which are running a firmware older than 1.14.0.
Other than that it has no impact, the repeaters will still forward all packages no matter with how many bytes the messages were sent. Receiving repeater adverts is purely cosmetical, it has no impact on the messaging functionality.
I agree on the companion part, it is way to early to start sending messages with 2-Byte pathing.
@ssozonoff How do you mean “1.14.x is riddled with bugs“? So far I am aware of only one in 1.14.1 which is easily fixed.
I believe thats correct and as you say not a huge issue.
I have had power related issue with 1.14.1 on alternate chemistry, obscure crashes which were only fixed by doing a full erase followed by a new flash, as you mention their is also the rxgain flag being flipped to off.
Speaking with the community around here others have reverted back to 1.13 after experiencing various issue as well. It just feels like 1.14 was rushed out the door before it was ready for prime time.
Its not a criticism but simply a “warning” for those wanting to upgrade hard to reach devices. I have been up a tree twice in the last 48 hours. I believe 1.15 is just around the corner.
Criticism is totally fine, I don’t mind. And I also did not mean to say that you said something wrong. I just saw a few users reverting back to 1.13.0 and I am trying to understand a bit better why that is and what to watch out for.
My three repeaters on 1.14.1 seem to run fine and they were all OTA updated, but I also skipped 1.14.0.
Oh yeah and as an important reminder 1.14.x also has the broken power management with the boot lock settings which affect at the very least nRF based setups using alternate chemistries like LTO and Sodium-ion
You can fix this by building your own FW with PWRMGT_VOLTAGE_BOOTLOCK = 0. The meshcore EVO firmware already has this set to off.
In den einschlägigen Kanälen ist erkennbar, dass bereits einige auf 2 Bytes umgestellt haben. Wohl ohne sich der Konsequenzen dieses Tuns bewusst zu sein. Und ja, bei uns laufen noch Repeater mit 1.13 weil mir das Risiko des Upgrades auf eine nicht stabile Version zu gross erschien. Ich bin froh um Einschätzungen wann ein Upgrade risikoarm durchgeführt werden kann.
Also ich habe meine Repester auf 2-Byte umgestellt, senden tue ich aber nach wie vor 1-Byte. Auch Repeater die auf 2-Byte gestellt sind wiederholen 1-Byte packet, nur die eigenen Adverts welche die senden sind dann 2-Byte. Hat also eigentlich kaum negative Konsequenzen, zumindest soweit ich das verstehe.
Das Einstellen vom richtigen Duty Cycle hat da wohl fast mehr Einfluss.
Wie schon erwähnt sind meine Erfahrungen mit 1.14.1 nicht all zu schlecht, aber andere hatten da Mühe mit Bugs. Meinen gut zugänglich Repeater zu Hause aktualisiere ich immer sofort, wenn der dann ein paar Wochen gut läuft mache ich auch die auf dem Jura..
Es sind bereits zaghafte Versuche auszumachen aber bis man dies fĂĽr Channelmessages verfĂĽgbar verwenden kann braucht es noch deutlich mehr Repeater welche dies unterstĂĽtzen.
.