meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
2.98k stars 714 forks source link

[Bug]: MQTT messages not going to private server #4212

Open valzzu opened 2 days ago

valzzu commented 2 days ago

Category

Other

Hardware

Heltec V3

Firmware Version

2.3.13.83f5ba0

Description

My base node is connected to the public server and i have my heltec connected to my private mqtt server.

I found out that mqtt messages coming from my base are not sent to my private server. I made a nodejs script so i could send data logged to discord but then i found it out. Using json output.

Relevant log output

No response

ianmcorvidae commented 2 days ago

Some discussion of this in discord -- it's happening here: https://github.com/meshtastic/firmware/blob/469ae0ff846944be12f293023954aad917e4ffcf/src/mqtt/MQTT.cpp#L481

When the MQTT server the packet originally went over and the one configured on a given node are two different servers, the restriction on all via_mqtt packets not being sent back to MQTT doesn't make the most sense, but I don't know if there's a good way to detect it and still not spam the public MQTT.

two thoughts I've had: a.) can/should the conditional only apply to packets that came from MQTT on this node (or are those already excluded elsewhere?), rather than all via_mqtt packets? b.) should we have some features deliberately built for the data-export use case of MQTT, as opposed to the mesh-bridging use case? This conditional works reasonably okay for mesh bridging (though it would mean you need everyone in an area on the same MQTT server, since you can't have two MQTT links on different servers within the same packet path)

Talie5in commented 1 day ago

This is what MQTT Bridging is for, the idea would be Node <-> Private MQTT Broker <-> Bridge <-> Public MQTT Broker Ideally, not allowing MQTT tagged packets to then be pushed to MQTT (eg, MQTT <->Node 1 <-> Node2 <-> MQTT) again would be to stop potential MQTT data loops.