[Feature Request]: Rebroadcast mode: Combination out of "LOCAL_ONLY" and "CORE_PORTNUMS_ONLY" needed.

[SR7673]

Platform

NRF52

Description

Hi programmers.
I'm running a ROUTER in a superior location. The mesh mostly has 80+ active nodes and i'm often getting 3...4 % AirUtilTX. Since the node must be as unobstrusive as possible, it has no solar module, just a 30 Ah accu, which lasts about 5...6 weeks...
Thus i want to limit the traffic to the most necessary stuff only. So far i choose LOCAL_ONLY since i only want to support the public channel and private messages between users but not private channels...
After upgrading to 2.6.5, i discovered the "CORE_PORTNUMS_ONLY" setting, which is a good idea and i would like to choose that but then i would allow traffic of other private channels.

So my request would be to build something that combines the limitations of "LOCAL_ONLY" and "CORE_PORTNUMS_ONLY". That would be the most vavourable option for me.

Regards...

[shalberd]

Agreed, a combination of those two would be great for
a) avoiding spam by using CORE_PORTNUMS_ONLY, recently really well-done in Meshtastic Firmware 2.7.4.c1f4f79 Alpha by using a whitelist approach https://github.com/meshtastic/firmware/pull/7487/files
b) only the public channel / channel number 0 and direct messages between users as in LOCAL_ONLY

I can completely relate to the poster's wish as we have, on EU_868, a very limited frequency situation with one frequency slot 869.525 Mhz for all modem presets ... For mountain routers, this combination of the two roles would be awesome to have.

@thebentern what do you think?

[ndoo]

+1, am admin of 2 hilltop routers serving a very busy city and I would like to deter commercial users with LOCAL_ONLY while mitigating the high ChUtil/Airtime with CORE_PORTNUMS_ONLY.

Maybe another implementation idea would be to use bitwise flags similar to position flags, to only allowlist specific portnums? Perhaps AND the flags with the core portnums to prevent accidentally killing basic functionality?

And so we could set LOCAL_ONLY (or any other rebroadcast mode) then pick the portnums to allow.

[pedjas]

I see this as wrong approach to solve clogging issues. Limiting portnums broadcasting defies very purpose of the net. Unnecessary traffic should be suppressed, not useful traffic.

[shalberd]

Unnecessary traffic should be suppressed, not useful traffic.

isn't that what whitelisting is all about?

https://github.com/meshtastic/firmware/pull/7487/files#diff-fb9b4a4da3229ad0f8213d3e55e97cb8068e71ba0225002aa050cf06788f6b8aR654

And how do you define unnecessary vs. useful?

[ndoo]

Rather than giving a rigid set of what is necessary/useful etc. flags would really be appreciated, in place of the current rebroadcast mode setting.

[pedjas]

And how do you define unnecessary vs. useful?

Unnecessary traffic is all traffic no one request for, like telemetry, position, nodeinfo etc. which just clogs mesh if it is slightly larger.

Even nodes that do not measure battery level, regularly send battery level telemetry with no data.

There should be option to turn of automatic sending of such info and sending it only on request.

[shalberd]

Does anyone else think, based on the code
https://github.com/meshtastic/firmware/blob/v2.7.15.567b8ea/src/modules/RoutingModule.cpp#L13

that the explantation of what LOCAL_ONLY does, is wrong / not 100 percent correct?

"Ignores observed messages from foreign meshes that are open or those which it cannot decrypt.
Only rebroadcasts message on the nodes local primary / secondary channels."

https://github.com/meshtastic/firmware/blob/v2.7.15.567b8ea/src/mesh/generated/meshtastic/config.pb.h#L84

The same text appears in the Android App, too.

From the code, it seems that channel 0 plays a key role in determining whether to rebroadcast or not.
And, of course, the key of channel zero being the same on the nodes rebroadcasting traffic.

My main beef is, does that not mean instead:

Ignores observed messages from foreign meshes that are open or those which it cannot decrypt.
Only rebroadcasts message on the nodes' local primary channel 0.

I mean, channel 0 is always the primary channel, and there is no OR-condition for a secondary channel ...
maybePKI has a clear selector && mp.channel == 0

@fifieldt what do you think of the text being wrong?
I always explained to users: if you select LOCAL_ONLY, only channel 0 messages that the node can decrypt and direct messages are rebroadcast.
Is channel 0 not the primary channel? Why mention secondary channels here?

[gitjusnix]

I always explained to users: if you select LOCAL_ONLY, only channel 0 messages that the node can decrypt and direct messages are rebroadcast. Is channel 0 not the primary channel? Why mention secondary channels here?

Private Channels can be configured for Index 0 / Primary Channel 0, and Public Channel on Index 1 / Secondary Channel 1