How does routing actually work?

[pr357on]

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

[costo]

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

https://meshtastic.org/docs/settings/channel#modem_config

and this:

Encryption / Secondary Channels

Some people seem to misunderstand the working of the LoRa modules used in meshtastic_nodes. These modules are usually built around SemTech chips, like SX1276 . All these chips are single frequency/channel, single spreadfactor and single coding_rate, which in meshtastic is called ‘modem_settings’. This means that the chip/module cannot read,decode or retransmit LoRa-transmissions with a different modem_setting than it has been setup for.

[jfirwin]

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)

[caveman99]

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.

[Eagle]

@caveman99

And the device will forward anything it receives on its radio channel and identified as a valid meshtastic packet

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

[mc-hamster]

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.