The Case for Expanding Repeater IDs Beyond 1 Byte #1613
Replies: 17 comments 19 replies
-
|
I agree, this is like the IPv4 to IPv6 transition. Better to do it now and be able to scale than to wait and have it become more and more painful to fix. |
Beta Was this translation helpful? Give feedback.
-
|
I agree too, even with only about 20 repeaters in our network we've had two randomly share the same first two characters, only to be discovered after deployment. Until 1.12 it was a pain to have to pull the repeater and change them. Additionally we have four neighboring regionals that we are close to establishing connections with. So yes. I would kike to see the limitation expanded, and the earlier the better. |
Beta Was this translation helpful? Give feedback.
-
|
See #1614 to vote :) |
Beta Was this translation helpful? Give feedback.
-
|
I agree something needs to be done about it sooner rather than later. Hopefully with as much backwards compatibility as possible |
Beta Was this translation helpful? Give feedback.
-
|
Hello I have built a mesh grid for our regions to co-ordinate, it exposes a major clash issue and the real effect of the clashing has been the inability to evaluate the performance of interregional routing efficiently. New comers don't know about the prefix flash's or implications yet.. and onboard clashing. By increasing the prefix to two bytes this will largely mitigate this issue in growing networks. It's easier to suggest a change to a minority then a larger number of conflicting users. Would be best to make these changes now before we grow to big, it will be a case of just doing ... Split the mesh and get the job done. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
We're definitely seeing this impacting us pretty hard in Ireland. LetsMesh shows 240+ repeaters observed in BHD mesh in the last 24 hours. Without trying we can get 100km+ between Slieve Croob in Northern Ireland with Skiddaw Mountain - we like being able to communicate across to the mainland and are also expanding south, but being stuck to just one byte namespace is already causing collisions. Transmitting from Slieve Croob also gives us a huge reach to rest of the Island, so we don't want to have lower transmission performance. Given the range we're seeing now, if the trade off is halving the number of max hops of a packet, we're currently reaching Scotland in two hops. Edge Repeaters or Bridge firmwares could be created to handle if someone needs to intentionally make a packet go further (the only time I've seen a packet with > 14 hops has been either a software error or a fluke of atmospheric conditions). As for a transition - personally we're actively rolling out repeaters right now, coordinating a cutover between the handful that we have now will be a lot easier than having to wait until there are 100s of them. Given the newness of MeshCore, I'd rather agree upon what V2 packets will look like and let v1 companions and repeaters alert when they start seeing those packets, to nudge people to upgrade, than trying to implement 100% perfect seamless migration or interoperability, which only draws out people from upgrading devices. Maybe V2 repeaters firmware can support running in either 2byte or 1byte IDs (but not at the same time), which would allow for people to roll out repeaters supporting v1 packets today, when they hit critical mass of updating repeaters, flip the switch to v2 packets. Similarly companions would then alert "hey it looks like it's all v2 packets, switch me to v2 mode". So the v2 packet format doesn't have to be backwards compatible if the software can detect which one is active and let the user switch to it. |
Beta Was this translation helpful? Give feedback.
-
|
I feel as through MeshCore has gained much traction in Canada, and the ability to observe and plan installations without duplicate IDs hampering would not only be beneficial, but critical. |
Beta Was this translation helpful? Give feedback.
-
|
Speaking as an enthusiast, most people are excited to connect more and more cities and regions, that's part of the fun. Like others have said, the best time to fix it is now, especially before more non-tech people get devices and don't know how to upgrade them.
From a theoretical perspective this is true, but in practice it does matter. If we don't have good network planning tools, then the functionality of the mesh won't be as good as it could be, because deployments and maintenance will be more difficult. |
Beta Was this translation helpful? Give feedback.
-
|
I agree we need to change this limit as it is very annoying seeing duplicate repeats on the trace view. |
Beta Was this translation helpful? Give feedback.
-
|
The only problem is this by default would limit us to 32 hops? |
Beta Was this translation helpful? Give feedback.
-
|
Someone mentioned the idea of reserving a block of repeater IDs that would only be assigned via explicit CLI specification. I think this is a fantastic approach, as it would ensure inter-city links always maintain distinct, identifiable paths. We've actually implemented something along these lines already in Ottawa. We've reserved the C-block IDs ( You can see our full system documented here: https://ottawamesh.ca/deployment/repeaters-intercity/ With 2-byte IDs opening up a pool of 65,536 possible values, reserving even 20-30 for interlink use would be a negligible cost for a significant operational win. Having firmware-level support for reserved ID blocks would formalize this pattern and make it much easier for other regions to adopt. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: It requires the repeaters being traced to be updated to at least Unfortunately it's possible for repeaters on older firmware to jump in and reply to trace requests as they don't understand the path size flags that were added. It has been in the firmware since 21st November 2025. For meshes established after this time, it won't matter, but for older meshes it's highly recommended to update to avoid this issue. This is available now in the web app: https://app.meshcore.nz Path Trace Examples: If this proves to be successful, a similar method could be used in normal packets, although instead as a breaking change to avoid this issue described above. The manual trace screen has a dropdown form field to select path segment size. Very interested to hear any feedback on this :) |
Beta Was this translation helpful? Give feedback.
-
|
Howdy all! 👋 I understand there's been a lot of community demand for this change, and it's something that's been requested for a long time now. There hasn't been much movement in the space of fixing this, as we have been trying to avoid a breaking change, where clients need to be rewritten to understand new packet formats etc. However, after a solid few days of staring at binary bit flags, packet structures and existing firmware code, I think we might have something that could work without the need for a v2 protocol rewrite. After writing updated documentation for the existing v1 packet format, I started writing a proposal for a v2 packet format. I made a few changes to the structure to allow for adjustable path segment sizes, such as 1-byte, 2-byte and 3-byte etc along with a few other nice to haves. However, when it came to actually looking at writing some code, I noticed there was no packet version check after reading the header, and instead the packet version check happened in Mesh::onRecvPacket(...), which happens after the firmware already parsed the path length, transport codes, wrote logs to serial, and in the case of bridge firmware, sent the packet across the bridge. If we were to make any changes to the packet structure, the v1 firmware check to drop v2 packets wouldn't kick in right away, and we could potentially crash old firmware. I don't think this would happen, but I don't like the idea of passing unexpected data further down the logic chain if it's unexpected. At first this looked very unfortunate, I wasn't going to be able to roll with a new v2 packet format, as I didn't like the idea of potentially causing issues for the massive existing meshes currently running v1 firmware. Having read through all the comments on these GitHub issues/discussions:
I came across this one: It looked very interesting. So I dug into it a bit further. And then it hit me... v1 firmware will drop all packets if the path length is greater than 64. So, we can hit two birds with one stone. Setting the upper two bits of the path length results in an integer value greater than 64, so we can force v1 firmware to drop the packet, while at the same time storing a flag that would allow newer firmware versions to know that the path includes multi-byte path segments. Instead of storing the full 64 byte path length in the path_length byte as is done for the existing 1-byte path segments, we can just store how many hops we are up to, that way we don't need as many bits to represent how many bytes exist in the path buffer. We can instead calculate this by multiplying with the path segment size from the upper two bits. (This may not actually be needed now, since further down I talk about 63 hops). Below is an overview of how I believe this will work:
The lists below show the raw binary notation, what it equals as an integer, and how many hops per segment size we get: 1-byte path segments
2-byte path segments (v1 firmware drops packets where path_length is greater than 64)
4-byte path segments (v1 firmware drops packets where path_length is greater than 64)
Upper 2-bit flags:
This is still very early days. So some things may be adjusted. After some discussion with @ripplebiz: Originally I was looking to use However, we decided it is probably worth dropping the 1 extra hop, to keep it simple and allow for an extra segment size. This would allow us to also have 3-byte segment sizes, which could prove very useful. It allows for more unique IDs than 2-byte path segments, while allowing more hops than 4-byte path segments.
Going forward: We are interested to hear some feedback on this. At the same time, we are looking into how to integrate this into the firmware side. It's easy to say the path length field now includes the segment size, but we still need to look at refactoring some firmware logic to ensure its used as expected in other places. Such as replies to newer packets. As noted, older firmware would drop these packets, so if users were to select 2-byte or more segment sizes, they'd be limiting themselves to repeaters that have updated, and older companions would not receive messages from newer packets. The way I see this happening, is this would get implemented in the firmware, we add a dropdown in the apps/clients to select the segment size you want, but we default to 1-byte which would be backward compatible, until firmware has been around for some time. After some undetermined duration, we could look to bump the default if this is something that's wanted. We will also look to add an earlier firmware check for the packet version, so this isn't an issue further down the line when we eventually do want a v2 ;) Hopefully this update comes across well. 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
We've been discussing this 'problem' for over a year already - and even a year ago people were saying 'let's just make this breaking change now and get it over and done with before the mesh expands too much'... yet here we are a year later and still discussing it. If there is genuinely no way to increase the unique identifier from 1 to 2 (or more) bytes without breaking the existing mesh then so-be-it ... but if it is going to be a breaking change then it needs to be extremely well planned and people need to know it's happening in advance. Pick a date for a V2 release and tell people in advance - a YT video from Andy will suffice giving as much advance warning as possible... rather than throwing a new V2 protocol release out without telling anyone it's happening, lighting the blue touch-paper and running for the hills ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Good explanation Liam 👌🏼 |
Beta Was this translation helpful? Give feedback.
-
|
Adding my vote to make it the best that we can, as soon as we can. Even if that means a breaking change. |
Beta Was this translation helpful? Give feedback.
-
|
For 3-byte paths, there's one spare byte (64 = 21*3+1) which might be useful to be reserved for extended flags. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
As MeshCore networks grow and cities start connecting to each other, the 1-byte repeater ID (00–FF) is becoming a real pain point. This isn't a theoretical future problem, it's something communities are actively fighting right now. I wanted to open a discussion on why this matters and what the appetite is for addressing it.
To vote, please see #1614
1. Coverage mapping is fundamentally broken by duplicates
Tools that visualize mesh coverage, trace message paths, and track network statistics, like MeshMapper, LetsMesh, Home Assistant MeshCore integrations, and others, can't accurately do their job when duplicate IDs exist. If two repeaters share ID
3A, there's no way to attribute the data to one or the other, the data becomes ambiguous. Some regions have so many overlapping IDs that per-repeater coverage analysis has had to be disabled entirely or ignored. The data is there, but it's unusable.A common counterargument is that unique IDs would make repeaters easier to locate, but that ship has already sailed. With noise floor and SNR data alone, which is readily available to anyone listening on the mesh, you can already pinpoint the approximate location of every repeater in an area quite easily. Mapping tools like MeshMapper have actually had to mask some of this signal data for exactly this reason. Keeping repeater IDs short and ambiguous doesn't meaningfully protect location privacy when the RF characteristics already give it away.
Take a guess where the below repeater actually is and that's just based on noise floor data
2. People want to understand their mesh
One of the first things people ask when they receive a message is "what path did it take to get here?" I understand that from a pure functionality standpoint it doesn't matter, if the message arrived, the mesh is working. But knowing which repeaters are carrying traffic is incredibly valuable for network planning. If a repeater is never involved in routing a message, should it even be there? Could it be repositioned somewhere more useful? With only 256 possible IDs and duplicates across regions, you often can't answer these questions because you don't know which repeater with that ID actually handled the packet.
Let's be honest, increased observability is one of the top reasons MeshCore has gained the traction it has. Many communities switched to MeshCore from other protocols specifically because of path visibility. People like understanding their network, reasoning about topology, and having clues for why one message made it through and another didn't. That advantage erodes as ID collisions grow.
3. Duplicate IDs cause real routing problems
This one is functional, not just analytical. If two repeaters with the same ID are within range of each other, they can both attempt to repeat a direct message instead of only the intended one. This wastes airtime and gets worse as the mesh grows. More repeaters in a region means more collisions, which means more wasted transmissions on an already bandwidth-constrained medium.
This also makes remote management a nightmare. When something goes wrong and you're trying to remotely manage a repeater, you have no idea whether one of the several repeaters sharing that ID in your management path is the problem, or whether your own repeater is actually down. Troubleshooting becomes guesswork.
One mesh with 2,000+ repeaters across a ~100km radius reported their entire network going down, and with 10+ people investigating, nobody could pinpoint the issue because too many duplicate IDs were in the same area. That's not a UX inconvenience, that's an operational failure that better observability would have potentially helped resolved in minutes instead of days.
4. Communities are going to extraordinary lengths to work around this
In Ottawa, we maintain a full registry of all 256 repeater IDs, coordinating assignments across the community to avoid duplicates. We've documented this publicly:
This works, but it's significant coordination overhead that doesn't scale. Not every community will have the organization or desire to manually manage a 256-slot ID registry. And even with perfect coordination within a city, the moment two cities connect, you're almost guaranteed overlapping IDs in the path.
The pain extends to deploying new repeaters too. Imagine you're at a prospective repeater site, you send out a test message, and you hear 7 repeats, 5 of which share the same ID. You can't accurately gauge how reliable the location will be, whether you'll introduce unnecessary hops by hitting a repeater 100km away with the same ID as one 10km away, or whether you're even extending the mesh from the intended point. This can add hours to the process of determining whether a site is viable, sometimes days if there's too much uncertainty and you just have to drop the node in and see what happens.
5. 256 IDs isn't enough for where this is heading
A single active metro area can easily consume 50–100+ IDs. As MeshCore adoption grows and more cities come online and interconnect, the 1-byte ceiling becomes a harder constraint. Communities will increasingly have to choose between accepting broken analytics and routing ambiguity, or investing heavily in manual coordination systems that fundamentally don't scale.
What would help
Even expanding to 2 bytes (65,536 IDs) would dramatically reduce collision probability and eliminate most of the coordination overhead communities are currently shouldering. The discovery protocol already uses full 32-byte public keys, proving that longer identifiers work at the protocol level.
I'd love to hear from the community and maintainers:
Is there interest in a protocol-level change, or is the preference to keep solving this at the community/application layer? I think there's a lot of interest in fixing this. MeshMapper alone has grown to almost 300 members in its Discord across 55 different mesh regions worldwide in just a few days. That's 55 meshes who want to visualize their network and understand real-world coverage, and they will all eventually hit the same wall if they haven't already today. I'd love to hear from everyone on what their thoughts are.
What would backward compatibility look like for existing deployments? And if it's not possible, that's okay too. Speaking for the Ottawa community, we'd have zero issue with a breaking change. We'd rather deal with it now while the network is smaller than later when it becomes a much bigger pain point with far more infrastructure to migrate.
The network is still young enough that a change like this is feasible. The longer we wait, the harder it gets.
For reference:
#1083
https://github.com/meshcore-dev/MeshCore/issues/562s
Beta Was this translation helpful? Give feedback.
All reactions