How does routing actually work?

I’m not quite sure if I understood the concept right. If I have 10 nodes, 2 are on channel “xxx” and 8 on channel “yyy” - will the route use all 10 nodes for messages on channel “yyy”?

I ask because it would be great to have a wider coverage for disaster/offgrid communication. But if you are limited to the known members of your own channel it would be some kind of private micro grid.

I hope you can help me understand it :sunny:

All nodes need to share the same modem_settings. Otherwise they do not see each other.

and this:

1 Like

When you share a channel url/qr code it includes all channels set up on the device. If my device has “xxx”, “yyy” & “zzz”, when I share that url with someone it gives them access to all three channels. We can’t cherry pick and give a radio just “xxx” & “yyy”, and have another user only have access to “zzz”

So the modem_config settings must match as @costo mentioned, and the encryption settings must match too. (The url/qr code includes the channel details and a random 256-bit key for encryption)

I guess I now understand more the way it works. So if I wan’t to have a wider coverage and reach more people, they all need to be on one channel. No way to just let foreign channel packets beeing forwarded.

So I could make as many people as possible join a public channel in my area/city to have a wide coverage mesh. I’m thinking of disasters or help in case of emergencies. Limit would be the memory in the device itself that could allow 32ish? meshed nodes.

Thanks for your explanations!

2 Likes

The new firmware 1.3 will have a higher NodeDB limit, either 64 or 80 - we’re still testing. And the device will forward anything it receives on its radio channel and identified as a valid meshtastic packet. So if you have the SAME radio parameters but DIFFERENT encryption keys it will still forward the encrypted packet. routing info is in a plaintext header.

1 Like

That’s great to hear. As far as my technical knowledge goes, this is exactly what I was thinking of. Sounds like a great way for everyday and emergency usage.

I’m still new to meshtastic but feels like a system I’ve been waiting for a long time!

As a feature suggestion, I would love to have a setting to allow only a list (a whitelist) of talk groups (aka encrypted “secondary channel”) to be forwarded. This would be useful to have better control on tx time for my nodes, in order to increase battery life and reduce radio congestion.
The way to declare this whitelist is to be determined, according to encryption features available on meshtastic. The optimal behavior would be to drop the message as early as possible to save power.

Cheers

Please open the feature request for this in our Github. This would be a good feature for a first time contributor to implement.

It would be both a combination of a change to the router and a very lightweight plug-in.