[Bug]: CLIENT_BASE role unwanted behavior

[peakascendr]

Category

Other

Hardware

Not Applicable

Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?

• Meshtastic UI aka MUI colorTFT
• InkHUD ePaper
• OLED slide UI on any display

Firmware Version

2.17.10

Description

config.device.role == meshtastic_Config_DeviceConfig_Role_CLIENT_BASE && is_from_or_to_a_favorited_node

I am experiencing unwanted behavior with this new role. Someone in my mesh favorited my node, they are running as CLIENT_BASE. All of my traffic for my roof node running as CLIENT is now sent to them without me having a choice in the matter. They are on the edge of the mesh so my messages died there ( or were sent back to me).

Relevant log output

[Stephan-2025]

I don´t thinks that´s a bug, it´s a missconfiguration on the other nodes side.

It is similar as another user configure his node as "router" ... so it does route your traffic primarely, i don´t have a idea how to solve that missconfiguration-issues.

[peakascendr]

A lot of messaging was needed to discourage users from choosing ROUTER role. I expect a lot of misconfigurations because this new role has the CLIENT prefix. Users need to be informed that CLIENT_BASE becomes a ROUTER for nodes they favorite.

[shalberd]

I agree with @peakascendr and disagree with @Stephan-2025

@compumike See my writeup here #7992 (comment)

This was initially about using favorites for 0 cost hops, i.e. not decrementing hops. My two main complaints are:

• CLIENT_BASE preferential routing being in the early instead of the late rebroadcast window
• both for 0 cost, non-hop-counter-decrementing hops as well as for preferred CLIENT_BASE nodes: the field "favorite" is not the right place to use for this. Favorite is just that, a favorite to keep node from rolling off the node DB. Similar to ignore node, which got its own field name, too.

@thebentern currently, this is expected behavior, yes, but the issue goes much deeper here with Client_Base, as my two main bullet points explain.

I really like that this ticket was brought up because it is foreshadowing what can and will happen should the "expected behavior" stay as-is.

[Ryu945]

@compumike

* CLIENT_BASE preferential routing being in the early instead of the late rebroadcast window

It would be better if Client_Base preferential routing was in the later half or later third of Client Window instead of Router_Late Window. You can still turn off rebroadcast of very close nodes, thus saving bandwidth, while your can still let far away nodes rebroadcast.

[compumike]

@shalberd Personally, I'm not opposed to having CLIENT_BASE use the late rebroadcast window. There are tradeoffs.

The difference here is only partially specific to CLIENT_BASE: it's more generally about "should a node suppress rebroadcasts". Any time we make changes which allow incrementally more rebroadcasts/retries (which is what moving CLIENT_BASE to the late rebroadcast window would do), the mesh will almost certainly get more reliable, at the cost of possible congestion.

It may sound different, but I see this issue as being closely related to #7994 which is about using observed SNR or RSSI (and/or the difference in SNR between the original observed packet and and the observed rebroadcast) as a heuristic for whether geographic diversity would be best served by still rebroadcasting a packet, even though we've heard it rebroadcast already. This directly goes to the heart of the:

They are on the edge of the mesh so my messages died there

issue that @peakascendr is experiencing!

If a USEFUL_CLIENT node in the opposite direction (i.e. a more useful direction) of the undesirable UNWANTED_CLIENT_BASE heard both your original transmit and the distant UNWANTED_CLIENT_BASE rebroadcast, then currently, USEFUL_CLIENT would suppress its rebroadcast. But you'd actually be better served by the mesh if USEFUL_CLIENT rebroadcasted anyway!

How do we get USEFUL_CLIENT to rebroadcast your packet? Many options:

• Make it harder to accidentally favorite. If it's an "unintentional adversary", this may work cleanly. As you suggest, maybe don't use "favorites" as the driver for CLIENT_BASE; maybe make a new flag that is more explicit and harder to set.
• Move CLIENT_BASE to the late rebroadcast window. Moving UNWANTED_CLIENT_BASE to the late rebroadcast window would help in this example, because USEFUL_CLIENT wouldn't hear any other rebroadcasts, so it would rebroadcast before the late window. (Downsides: latency, congestion, doesn't entirely solve the issue of multiple CLIENT_BASE favoriting your node, such as your own and one adversarial one.)
• Make some "rebroadcast anyway even if I heard a rebroadcast" rules. I see Don't cancel rebroadcast if we hear a rebroadcast with bad snr #7994 as a possible route. (Downsides: more theoretical at this point, but could be more generally useful.)

Pros/cons of early vs late window for CLIENT_BASE:

• Early window:
  • 👍 lower congestion
  • 👍 lower latency
  • 👎 vulnerable to "adversarial favoriting" (this issue)
• Late window:
  • 👎 higher congestion
  • 👎 much higher latency
  • 👍 higher reliability with "adversarial favoriting" (described above)
  • 👍 higher reliability even without "adversarial favoriting" (because it doesn't suppress other clients so much)
  • 👍 might also be configured to act as ROUTER_LATE for incoming broadcast packets

The original CLIENT_BASE proposal was a compromise to get something out there that was close enough to what existed (reusing favorites, etc) so it could be built and merged fast.

If others support the tradeoffs of the late window... it's not crazy at all.

[shalberd]

If others support the tradeoffs of the late window.

yes, definitely for Client_Base priorizized nodes

As you suggest, maybe don't use "favorites" as the driver for CLIENT_BASE; maybe make a new flag that is more explicit and harder to set

ja / yeah / yes / oui / si :-)

[jschrempp]

With the current applications I thought when you DM a node it gets automatically set as a favorite. The lesson would be: don't DM a CLIENT_BASE node. Or does this only happen when you reply to a DM? Then the rule is don't DM from a CLIENT_BASE node.

[jschrempp]

When moving a node to the CLIENT_BASE role it keeps all the existing favorites. When I moved one of my nodes to CLIENT_BASE I did not reset the NodeDB. So I'm doing this right now to people. (I'll go reset my favorites).

Perhaps changing to CLIENT_BASE should reset the NodeDB, while retaining as favorites and node that is used for remote admin.

[shalberd]

With the current applications I thought when you DM a node it gets automatically set as a favorite.

three things:

• wow, I was not aware of that, and I bet a multitude of users are not aware of that.
• let us please use a field other than favorite from Nodeinfo is_favorite for that

The lesson would be: don't DM a CLIENT_BASE node. Or does this only happen when you reply to a DM? Then the rule is don't DM from a CLIENT_BASE node.

• infrastructure nodes like Client_Base, Router, Router_Late should automatically have the user field is_unmessagable set to true

a) 0 cost hop node marking
b) client_base trusted / prioritized clients

This shows to me once more, I am only saying in terms of use cases, the unintended consequences of using that favorite field for something it was not designed for.

Your engineering effort in firmware 2.7 is amazing, I am just trying to hint early at side effects. Good thing on alpha testing, isn't it?

@fifieldt what do you think about @compumike's comments on this? He did a great job summarizing the isssues, pros and cons, I think.

When moving a node to the CLIENT_BASE role it keeps all the existing favorites

yeah ... i bet the same happens when moving a role from Client to e.g. ROUTER_LATE and Router as well. 0 cost hop chaos potentially ;-) Seriously, let's reconsider / re-think the use of the favorite field / Nodeinfo is_favorite for the two use cases prioritized Client_Base devices and 0 cost hops from certain infra nodes.

[jschrempp]

With the current applications I thought when you DM a node it gets automatically set as a favorite.

I heard - and I'm no expert on this - that this was intended to keep nodes that you DM with from being rolled out of the NodeDB. Keeping them in the NodeDB prevents someone from spoofing their identity by keeping. Again, I could be completely bonkers on this.

[fifieldt]

That's right. However, isn't the whole idea here that you need a client base since your client that you actually use is inside your house? So, one probably shouldn't be connecting to the client base to send DMs that often ....

[jschrempp]

That's true, although sometimes I'm trying to figure out why I'm not getting into the mesh and might send a DM from my CLIENT_BASE node. This is a limited case brought about by the auto-favoriting function.

[compumike]

That's right. However, isn't the whole idea here that you need a client base since your client that you actually use is inside your house? So, one probably shouldn't be connecting to the client base to send DMs that often ....

I have to confess, when I wrote CLIENT_BASE I didn't know about clients doing auto-favoriting! 😅

@shalberd for now, would the vast majority of concerns be alleviated if the CLIENT_BASE behavior were gated on something other than is_favorite? Seems like it might be.

[Ryu945]

Turning off auto favorites should also be done. Things should not be done automatically.

[shalberd]

@fifieldt @thebentern what do you think about @compumike summary on the issue and his thoughts?

#8367 (comment)

[fifieldt]

Left field idea: what about if we severely limit the number of favourites a Client Base node can have? In theory, just enough for your collection of half a dozen nodes that live inside your house ...

[shalberd]

I donno, that does not solve the problem really. @thebentern With is_ignored nodes, we set those as is_favorite, it seems (when I add a node to the ignore list, after putting that to true, it also adds it to the favorites, at least in the android app, is_favorite is shown as true). I only put a node to be ignored, and it became a favorite without my checking it as favorite... uggh

However, the nodes are then not seen in the Android app under favorites, only under filter criterion "ignored nodes show".

@compumike Are we currently checking both for is_favorite and !is_ignored not ignored?
@fifieldt I am unsure about whether when a node is added to the ignore list by field is_ignored, it correctly also becomes is_favorite. If yes, this is another edge case we need to be aware of, right?
The possibility to ignore nodes with an own field was added in Nov 2024 #5319

https://github.com/search?q=repo%3Ameshtastic%2Ffirmware+is_ignored+is_favorite&type=code

Android App 2.7.3, firmware 2.7.12 I only set the node to ignore ... not to favorite, yet after I return to the menu, it is shown as is_favorite as well.

a search here shows that an is_favorite: true node could also be is_ignored: true, meaning that to be ignored nodes are also set as favorite nodes ... making @compumike change possibly even more problematic. Same for the 0 cost hop topic ...

https://github.com/meshtastic/firmware/blob/master/src/mesh/NodeDB.cpp#L1917

We could have similar logic maybe with a third field "is_client_base_preferred".

[jschrempp]

It seems like is_favorite is being used to keep nodes from rolling out of the NodeDB. They may not actually be "favorites".

[shalberd]

It seems like is_favorite is being used to keep nodes from rolling out of the NodeDB

correct

https://github.com/meshtastic/firmware/blob/master/src/mesh/NodeDB.cpp#L1916

Now I am only trying to find the place where, when a node is marked as ignored, it sets is_favorite to true ...

[shalberd]

I have to confess, when I wrote CLIENT_BASE I didn't know about clients doing auto-favoriting!

and I today got myself thinking about to be ignored nodes .. is_ignored: true ...
Seems like we can have a situation NodeInfo field-wise where we have favorites, yes, but they are also marked as is_ignored: true.
For context, both for this use case as well as for 0 cost hops: We often have to resort to setting 2-5 malplaced router nodes to is_ignored: true ...

for now, would the vast majority of concerns be alleviated if the CLIENT_BASE behavior were gated on something other than is_favorite

looks like it, but you'd have to discuss this more with the other core maintainers. Similar to how a separate field was added for nodes that are to be ignored during routing / forwarding. What puzzles me is that when I set is_ignored on a node, it also becomes an is_favorite ...

Wow :-)

[shalberd]

still doesn't fix the unwanted behavior of being added to a CLIENT_BASE without consent.

agreed. Same issue for infrastructure nodes to be set as originators for 0-cost hops. Someone could tag any node they see without the others having any control over it.

I'd propose to leverage direct messaging and PKI as an authorization flow for client_base_preferred_routing_node = true

I like that idea, as I am a big fan of public/private key encryption as a general concept.
The only issue with using DM / direct message for this answer back is: we can only direct message a node that in user config is set as, in node DB, as owner.is_unmessagable = false
As soon as the user, which is common in the case of an infrastructure type node like CLIENT_BASE, sets owner.is_unmessagable = true, the direct message approach fails.

Still, I think it is the best shot we have here, for consent in terms of 0-hop-cost from-nodes as well.

Another verification step aside from the direct message channel I could think of:

• what about using a verification code on the device screen? On the to-be-marked node. Then, the verification code would need to be entered at the CLIENT_BASE node. Then again, there is no way to sync that without a second factor type channel ...

[jschrempp]

I'm new to this, so maybe a bad idea ... CLIENT_BASE node sends DM to the to-be-marked node. Contents of message is verification code that is good for a few minutes.

[jschrempp]

A slightly different random idea.

For a CLIENT_BASE node to set additional preferred routing nodes it must be messagable. This lets the owner of the CLIENT_BASE node control when it will accept new dependent nodes; it will be a window but the time that window is open is under the control of the node owner.

When that CLIENT_BASE node is messagable, a node that wants to get preferred routing from the CLIENT_BASE node sends a DM to the CLIENT_BASE node with the text contents "BASE ME" (or something better thought out).

When the CLIENT_BASE node receives a "BASE ME" DM it checks that the sending node is 0 hops away and then adds it to the preferred routing list.

This scheme protects both the CLIENT_BASE node since it is only open to remote change when the messagable window is open (which the owner could leave open all the time if they want). And the dependent node is protected because only it can initiate preferred routing. And since the dependent node has to be 0 hops away for the config to happen, it is safe from distant spoofing.

[shalberd]

@GUVWAF @jamesarich this idea here is about the adding of trusted other nodes, with a kind of approval process via direct messaging,
for adding

• preferred client_mute device to device with role CLIENT_BASE
• other infrastructure type nodes of type Router, Router_Late, Router for 0 cost / no-hop decrementing hops
  Both cases have the potential for great misuse and being detrimental to the mesh of someone can add nodes they have no control over as preferred / trusted / special rule types of nodes

[dzid26]

Here is my idea that would use shared private channels #8762

[fifieldt]

Left field idea 2: client base should only be router for nodes that can remote admin it (i.e the 3 pubkeys that are set in remote admin)

[shalberd]

we don't really use much remote admin so far ... not trusting the process and mechanism too much either

[shalberd]

client base should only be router for nodes that can remote admin it (i.e the 3 pubkeys that are set in remote admin)

if we use that idea, that would be great for from-nodes designating in case of 0 cost hops #7992 (comment)

@fifieldt what do you think of the idea posed earlier to not use the early rebroadcast window here?
#8367 (comment)

[korbinianbauer]

IMO Client_Base is supposed to serve as a gateway for a bunch of nearby nodes (e.g. in the house), which might definitely be more than 3. The impact of "malicious favoriting" could also be reduced by only acting as a Router for CLIENT_MUTE nodes though.

[shalberd]

IMO Client_Base is supposed to serve as a gateway for a bunch of nearby nodes (e.g. in the house), which might definitely be more than 3

no, originally, the MR owner made the request for CLIENT_BASE as a use case for a home node, indoors, in a multi-floor-building and maybe a portable node in the city trenches between blocks.
He said in his issue that lead to the PR #7863
"Due to managed flooding SNR prioritization, my mobile node’s outgoing packets are usually picked up and rebroadcasted by a relatively weak (probably indoor) neighbor node elsewhere in my town" --> shalberd note: improperly placed CLIENT nodes that should really run on mode CLIENT_MUTE.
That is the issue Meshtastic should stress over and over again. https://meshtastic.org/blog/choosing-the-right-device-role/
Maybe simply sticking to Client is in fact not such a safe bet and Client_Mute should be used more in dense meshes, Client_Mute as the new default ... I think there is not even such a thing as multi-select dropdown default in the device roles, I might be wrong, though.
In any case, I don't think it is enough that The Comms Channel only is stressing that, it should be default
https://youtu.be/htjwtnjQkkE?t=273

That special behavior is definitely not intended to be used for more than 2 nodes. So, maximum a couple of, not "a bunch" of.

. The impact of "malicious favoriting" could also be reduced by only acting as a Router for CLIENT_MUTE nodes though

no, especially in dense mesh networks, CLIENT_MUTE has long been the role for portable nodes on the move and indoor nodes for a long time. CLIENT is the role that intended to be used for nodes reachable from all sides and elevated in e.g. a city or on a small hill. So, to summarize, if people adhere to that, we have a large number of CLIENT_MUTE nodes in range of a CLIENT_BASE node, as well as a small number of CLIENT nodes.

The entire original PR on CLIENT_BASE, especially when used without to-be-favorited client verification and with early rebroadcast ROUTER-like behavior is suboptimal. Client_Base as it is now is a little like excessive use of antibiotics to kill an infection, while leading to unintended side effects ;-) cause it might not be a bacteria causing the problem, but a virus ...

@fifieldt @compumike FYI

"Due to managed flooding SNR prioritization, my mobile node’s outgoing packets are usually picked up and rebroadcasted by a relatively weak (probably indoor) neighbor node elsewhere in my town"

@GUVWAF I am not sure whether just placing those nodes on the ignore list would have been a better approach, rather than trying to override them with Router-like behavior. Then again, maybe not :-) Google KI says "ignore list
prevents your device from receiving its messages and also stops your device from forwarding or repeating its messages"

Device verification remains my favorite approach for adding nodes as relevant to

• 0-cost hops
• Router-like forwarding by CLIENT_BASE devices

That and a separate field than is_favorite, similar to is_ignored, for both features.

We can modify CLIENT_BASE also to just work by only allowing devices with role CLIENT_MUTE for preferred early broadcast window retransmit, but that is not the core of the issue, only icing on the cake.

Larger context: we are using about 300 - 500 active nodes in Switzerland, very happy with MEDIUM_FAST and recommending Client role to users with locations that can really contribute to the mesh in terms of optimal forwarding, Client_Mute to all other users, and Router_Late to mountain node operators.

[CL0SeY]

Maybe the terminology should be more about "prioritising" nodes...

So for a CLIENT or CLIENT_MUTE, for what we call their CLIENT_BASE

• allow this neighbour node to prioritise my traffic (with potentially a slider of effectiveness, so highest priority will mean early router phase, lower priority would be late stage). This would send a message to the other node with its preference, and the ACK would confirm it.

And on the "CLIENT_BASE"

• prioritise this node's traffic

I feel like you could do away with the CLIENT_BASE role then - the trigger for performing client base activities is having the linkage set up, so you can have your own hierarchy of nodes configured in a peer to peer style.

[thenoahcomputer]

Not sure if it's possible, but perhaps should only have CLIENT_BASE act as a ROUTER for a favorite if the other node also has the CLIENT_BASE marked as a favorite?

That would prevent a person running CLIENT_BASE from acting as a ROUTER for nodes without the other node's consent.

I think limiting the special treatment for favorites by CLIENT_BASE to only apply to CLIENT_MUTE devices is a good idea.

[dzid26]

A bit similar to my idea #8762 In both cases there would need to be some handshaking needed to check if the CLIENT has favorited the CLIENT_BASE. yikes

[shalberd]

Not sure if it's possible, but perhaps should only have CLIENT_BASE act as a ROUTER for a favorite if the other node also has the CLIENT_BASE marked as a favorite

And if that is not possible, at least a number-of limit, say 2-3, for the favorite nodes on Client_Base, Router, Router_Late ...
Plus, yes, for this feature here, applying router-like early rebroadcast window behavior to Client_Mute role devices, is a good idea, I agree.

[dzid26]

Is it expected for the message from CLIENT_BASE to my favorite CLIENT_MUTE with good a SNR to be routed by some external node? Because of that the messages often fail and I am in the same building.

I doubt that external node has favorited my node CLIENT_BASE. But I also can't check because I don't see it on the node list!