I have very strange connectivity problem with a LTE backhaul.
I’m using Multitech Conduit AP gateways successfully for years with a different Network Server than Chirpstack. The connectivity is always very good.
In the same configuration and in the same locations, all the gateways on which Chirpstack Gateway Bridge is installed (10 devices) have losses of connectivity from time to time, and it takes sometime more than 1 hour to reconnect.
Does the Gateway Bridge have its own “keep alive” feature that could conflict with the one integrated in the conduit?
I’ve spent a good amount of time with both Multitech and Tektelic gateways on LTE backhaul and have not run into this. The Gateway Bridge uses its MQTT client library’s keepalive, which by default is 30s and configurable in the .toml file (we usually ran it at 45 or 50s for bandwidth considerations). I recall the Multitech having its own keepalive/ping settings for cellular, but I don’t think I ever needed to do much with it.
I have 10 gateways on site. They do not communicate between them.
They send their stats packets every 60 seconds. When I restart a gateway, let’s say it starts to send the packet at 12:34:12. So for a couple of hours, every check is at XX:YY:12.
But, in all cases, every time, after a long period (but less than 12 hours), all the gateways seem to be “synchronized” (=> XX:YY:12 for the first and XX:YY:43 for the second becomes for instance XX:YY:02 for all).
Would you mind doing some testing with the ChirpStack MQTT Forwarder? It should be pretty easy to migrate from the GW Bridge. The big difference with the ChirpStack Gateway Bridge and the MQTT Forwarder is that the first will subscribe and unsubscribe based on incoming UDP data. I have observed some cases where also internal communication (UDP Packet Forwarder → GW Bridge) was blocked, until the cellular back-haul was restored. This would cause the GW Bridge to unsubscribe as the gateway was no longer available. I did refactor quite a while ago to fix some potential race conditions so also validate if you are using the latest version.
The MQTT Forwarder is a lot simpler, it retrieves the Gateway ID on startup, and it keep the MQTT subscription during the lifetime of the MQTT Forwarder process. A lot of the (re)subscribe/unsubscribe complexity has been removed that was needed in the GW bridge.
Thanks for your help. Looks like a potential explanation (I’m using last version of the Gateway Bridge). The only reason why I’m not using the MQTT Forwarder is the lack of NetID filter, to avoid uncontrolled data volume on LTE.