Always Zero-Hop MQTT traffic #8636
Conversation
|
This has moved into a space where users have zero control and anyone who needs to actually allow hopped MQTT where an MQTT bridge is necessary is FORCED to build firmware. |
This is how it really needs to be. I've seen this on two very congested networks in the US South East where people plugged into private MQTT's and were flooding packets out without care of the impact on overall congestion. In the use cases where there is a good use case, those users are sophisticated enough to do custom firmware builds. |
We're saying the same thing. Framing it differently; This enforces "I know what I am doing, even if it's a bad idea". Taking easy control of this from the common user is a feature not a bug. |
|
Sensible defaults and user toggles are the best course of action. Allow users and administrators to perform these actions via CLI toggles and apps to decrease user friction |
The issue is the friction needs to be extremely high. Even a "I'm not a jerk" warning or whatever wont prevent people turning in on in congested meshes as they think they are doing a cool good thing. Have it as a build-time only flag that one can set to turn it off is the only way that would prevent this traffic from jamming up routers in the European and metro US meshes. |
|
I agree with Xaositek’s assessment, and I want to add some operational context from our regional network. In deployments like ours, node owners, especially those who operate routers, repeaters, or other backbone infrastructure, intentionally control whether their hardware will pass MQTT traffic. That control is part of how we design and manage the network. Removing or restricting that ability in stock firmware would force groups like ours to either redesign our networks or maintain custom firmware builds, and that is not sustainable long term. Our mesh relies heavily on MQTT bridged/rf traffic to reach areas where we do not have internet connected nodes. Much of our regional traffic originates on MQTT and is delivered over RF through these infrastructure nodes. We have a main private channel, almost all traffic is MQTT sourced. We keep the primary channel RF only unless a remote user needs to send telemetry. This configuration has been stable and reliable for nearly 60 active users. Getting everyone to change device profiles or channel settings would create significant operational issues. We also maintain a private RF only channel for sensitive or isolated operations, and this depends on the ability to choose, per node and per channel, what traffic should be bridged. In summary, the ability to decide whether a node participates in MQTT passthrough is a fundamental decision for the network operator. Removing this flexibility would negatively affect established regional networks that rely on mixed RF and MQTT infrastructure. Preserving the current behavior, while improving safeguards or defaults if needed, keeps compatibility intact without forcing community groups to manage their own firmware builds. Cheers! |
|
The issues is the meshes with 100's of active users (Europe, US cities). Just blocking it on the routers isn't enough, as user nodes trying to send it still eat router RX airtime and create packet collisions even if they are blocked at the router. People enable MQTT downlink because they think they are doing a good thing, even is it's very detrimental to the mesh. No amount of warning is going to prevent the RF impact from it. |
|
I understand the intent behind this PR, but right now it is doing the bluntest possible thing by replacing p->hop_limit = e.packet->hop_limit with p->hop_limit = 0, which forces every MQTT originated packet to be zero hop with no option for configuration. Zero hop as the default is absolutely reasonable and it directly addresses the very real problem of casual users unintentionally flooding public meshes with downlink traffic. That part makes sense. The concern is that some networks intentionally rely on limited hop MQTT for linking segments, running backbone paths, or supporting automated services. Removing all configurability forces those deployments into custom firmware and creates fragmentation within the ecosystem. A more balanced solution would preserve the zero hop default while still providing a deliberate, high friction override for advanced administrators who need it. One approach would be adding explicit configuration options such as network.mqtt_downlink_max_hops and network.mqtt_downlink_allow_override, both defaulting to zero and false. These options could be available only in the CLI or in an advanced section of the UI so they are not casually changed. Another protective layer would be allowing hopped MQTT only on specific channels that have downlink enabled while leaving all other channels strictly zero hop. This maintains safety for typical users while still offering an official, controlled path for experienced operators who have legitimate use cases for limited hop MQTT without requiring forked firmware. |
|
Is there a way to make this a setting on the node side rather than the mqtt side that defaults to zero hop but can be changed? As in a separate setting than the downlink option. That way, operators who want to use mqtt as a crutch for not having real rf coverage can enable it on individual nodes, but the average user who just connects to a private mqtt server that doesnt zero hop packets without knowing all the details doesnt accidentally spam the airwaves? |
5 participants
Always zero hop packets that originate from MQTT (Downlink).
This allows users to continue to use MQTT on node, while leaving the precious airwaves alone.
Changing this behavior should be extremely high friction (modify and compile your own firmware, not a standard config) as it's risk for abuse (intentional or accidental) is extremely high.
The Meshtastic Public MQTT, as well as many private-mesh-group MQTT servers are Zero-Hopped for this reason (high abuse potential). Let's end this madness everywhere.
🤝 Attestations