[Feature Request]: Make mandatory-rebroadcast roles only possible to enable via remote admin

[erayd]

Platform

Cross-Platform

Description

I would like to see mandatory-rebroadcast roles only be possible to enable via remote admin.

Users deploying infrastructure roles in inappropriate locations is a well known problem, leading to significant congestion and suboptimal hop behaviour in many areas (and ultimately the removal of the ROUTER_CLIENT role). By putting the ROUTER / ROUTER_LATE / REPEATER mandatory-rebroadcast roles behind a remote-admin requirement, it will ensure:

• That the users who enable these modes have put in some effort to understand the platform (rather than clicking the shiny option in the menu and not realising the consequences)
• That users who deploy these things in locations that then cause problems will be guaranteed to have a way to remotely fix the issues they cause without needing physical access to the device.

[VideoFX]

Makes sense for ROUTER, and maybe REPEATER, but not for ROUTER_LATE. ROUTER_LATE won't be the same as a ROUTER deployment by its design, and thus wouldn't need it behind remote admin.

[erayd]

@VideoFX Can you expand on your reasoning a bit? ROUTER_LATE is still a mandatory-rebroadcast role, and thus still contributes to congestion. Congestion caused by users who don't know better is what this suggestion is intended to help solve.

[Talie5in]

@erayd At best it'll curb the chance of just "click happy" users, however, it wont reduce those that think they know better anyway.

But I am a +1 for this change in the hopes to reduce the click happy nature of causing mesh network issues.

[erayd]

...however, it wont reduce those that think they know better anyway.

Yeah, agree with you on that point. But there is no barrier that we could put in the way that will stop sufficiently determined stupidity 🙂

This is more about trying to do something that would reduce the impact of "ooh, router, shiny, I need one of those!" when scrolling through the settings, plus ensuring that people have the ability to undo mistakes they leave on the roof of a building they don't have regular access to, etc. I'd be all for hiding it behind a warning screen as well.

[b8b8]

...however, it wont reduce those that think they know better anyway.

Yeah, agree with you on that point. But there is no barrier that we could put in the way that will stop sufficiently determined stupidity 🙂

This is more about trying to do something that would reduce the impact of "ooh, router, shiny, I need one of those!" when scrolling through the settings, plus ensuring that people have the ability to undo mistakes they leave on the roof of a building they don't have regular access to, etc. I'd be all for hiding it behind a warning screen as well.

Based on the number of people that got mad when bluetooth was removed from the router role, i think this is a fair assessment. If they are really using the misplaced roof router as a real router they would have admin setup and not notice the missing role choices. I think we all know what happened was people were just bluetoothed to their router in their house.

This is a really balanced solution that does not lock or gatekeep anything behind a custom firmware download, nor requiring the user to build their own. People can and will still misuse the router, but it should make them stop and think a bit.

[Talie5in]

Just to Clarify, just based on some commentary on Discord, Is the idea..

1. You cant enable router/repeater/router_late unless an admin key is set first.
   or
2. You can only set it over remote admin (which, obviously requires and admin key is set).

[erayd]

@Talie5in The proposal is that the role can only be enabled (set) via remote admin. That way it ensures that remote admin is actually working.

[GUVWAF]

I like the idea.

The most challenging part would probably be letting client apps only show the ROUTER/ROUTER_LATE/REPEATER options for remote admin, or somehow give feedback that it didn't work using the normal way.

[b8b8]

Makes sense for ROUTER, and maybe REPEATER, but not for ROUTER_LATE. ROUTER_LATE won't be the same as a ROUTER deployment by its design, and thus wouldn't need it behind remote admin.

I agree that while the deployment of router_late will not be the same as regular router, router_late is still not meant to be just put on anyone's house roof instead.

[garthvh]

I would like to see router late not be client connectable like the other router roles, the inability to use it with a phone client does more to force careful adoption than anything else.

[wehooper4]

While this sounds like a good idea to raise the barrier of entry, for those of us that do actual field deployments can this remain something settable via CLI? The two scenario this will impact are:

1. Bench setting nodes before taking them out for deployment
2. Pi/Linux nodes on towers administered over SSH

Your average problem user isn't going to be messing with the CLI anyway, so it will still filter out the low hanging fruit.

[b8b8]

While this sounds like a good idea to raise the barrier of entry, for those of us that do actual field deployments can this remain something settable via CLI? The two scenario this will impact are:

1. Bench setting nodes before taking them out for deployment

2. Pi/Linux nodes on towers administered over SSH

Your average problem user isn't going to be messing with the CLI anyway, so it will still filter out the low hanging fruit.

1. You should really set it to client while doing the settings at home anyway, and use remote admin to change to router once mounted. that's the only change required before deployment.

2. Makes sense.

I think we can all agree that yes, CLI should still be allowed. Only the client apps would have this "restriction".

[afourney]

Makes sense for ROUTER, and maybe REPEATER, but not for ROUTER_LATE. ROUTER_LATE won't be the same as a ROUTER deployment by its design, and thus wouldn't need it behind remote admin.

I agree that while the deployment of router_late will not be the same as regular router, router_late is still not meant to be just put on anyone's house roof instead.

I was under the impression that roof nodes were exactly what it was designed for: #5603 (comment)

[erayd]

I was under the impression that roof nodes were exactly what it was designed for: #5603 (comment)

Nope. ROUTER_LATE has always been intended as an infrastructure role to fill coverage holes and work around problematic terrain. It's not intended as a roof role.

With that said, if you must run a roof node, then this is the role that is best suited for that purpose - but bear in mind that any mandatory-rebroadcast role, including ROUTER_LATE, will contribute to congestion on the channel. So if you do run a roof node, keep a close eye on the channel utilisation. If it gets too high, you may need to yield the airtime in order to avoid adversely impacting the mesh in your area.

[GUVWAF]

Indeed, my comment was for roof nodes in small meshes (like my own 11-node mesh), to serve CLIENT_MUTE nodes in the house. I would not recommend using it on roofs in dense meshes.

[afourney]

I was under the impression that roof nodes were exactly what it was designed for: #5603 (comment)

Nope. ROUTER_LATE has always been intended as an infrastructure role to fill coverage holes and work around problematic terrain. It's not intended as a roof role.

With that said, if you must run a roof node, then this is the role that is best suited for that purpose - but bear in mind that any mandatory-rebroadcast role, including ROUTER_LATE, will contribute to congestion on the channel. So if you do run a roof node, keep a close eye on the channel utilisation. If it gets too high, you may need to yield the airtime in order to avoid adversely impacting the mesh in your area.

We've got 500+ nodes in our mesh, and weekly Net's on Mondays. We're lucky if any two non-neighbors can hear each other (we coordinate on Discord, so we know what active participation looks like). The terrain is not friendly. General feeling is to optimize first for delivery THEN utilization (which is actually already very low because.... terrain).

[nmaq-dev]

Our mesh is 99% problematic terrain full of holes. I have a node on the rooftop of a townhouse in the gully of the side of a hill. The difference in delivery between rooftop vs living room is insane.

Keep router_late for rooftop deployments. At least until we have a better sense of what will work for reliable delivery in this large mesh.