Intermittent Disconnections Between IoT Edge Module and Mosquitto MQTT Broker

[shourikasa]

Environment:

• app1: IoT Edge module (C#, .NET 8) running on RedHat server
• mqttbroker: Mosquitto 2.0.17 running on a separate RedHat server
• Connection: Certificate authentication (TLS), using MQTTnet managed client (MQTTnet v4.3.7.1207 NuGet package)

Problem:
We are experiencing intermittent disconnections between app1 and the mqttbroker. The managed MQTT client is expected to handle reconnections automatically, and this works reliably in local development. However, in production, the following issues occur:

• Disconnections happen sporadically without any errors logged in our try-catch blocks.
• When a disconnect request is not initiated by app1, we only log the event and avoid explicit disconnects.
• After avoiding the disconnect, topics are still unsubscribed and attempts to resubscribe do not succeed or throw errors.
• The only workaround is to restart the app1 module, which restores connectivity and subscriptions.

MqttClient Options:

 MqttClientOptionsBuilder builder = new MqttClientOptionsBuilder()
     .WithClientId(IotEdgeConstants.ModuleId)
     .WithTcpServer(_configuration.MqttServerAddress, _configuration.MqttServerPort)
     .WithProtocolVersion(MQTTnet.Formatter.MqttProtocolVersion.V500)
     .WithKeepAlivePeriod(TimeSpan.FromSeconds(60));

ManagedMqttClientOptions options = new ManagedMqttClientOptionsBuilder()
    .WithAutoReconnectDelay(TimeSpan.FromSeconds(60))
    .WithClientOptions(builder.Build())
    .Build();

options.ConnectionCheckInterval = TimeSpan.FromSeconds(60);

Logs (from initial connection):

[04:17:11 INF] Starting managed mqtt client with options {"MqttServerAddress": "abcd.com", "MqttServerPort": 1884, "CertificateCaPath": "/etc/ssl/certs/RootCA.der.crt", "AuthenticationCertificatePath": "/certs/local/abc.pfx", "WithTls": true, "IgnoreRemoteCertificateNameMismatch": true, "$type": "MqttClientWrapperOptions"}.
[04:17:11 INF] Unsubscribe from topics: .
[04:17:11 INF] Subscribe to topics [{"NoLocal": false, "QualityOfServiceLevel": "AtMostOnce", "RetainAsPublished": false, "RetainHandling": "SendAtSubscribe", "Topic": "inputextensiontopic", "$type": "MqttTopicFilter"}, {"NoLocal": false, "QualityOfServiceLevel": "AtMostOnce", "RetainAsPublished": false, "RetainHandling": "SendAtSubscribe", "Topic": "abc/topic7", "$type": "MqttTopicFilter"}].
[04:17:11 INF] Connected to server: {"ConnectResult": {"ResultCode": "Success", "IsSessionPresent": false, "WildcardSubscriptionAvailable": true, "RetainAvailable": true, "AssignedClientIdentifier": null, "AuthenticationMethod": null, "AuthenticationData": null, "MaximumPacketSize": 0, "ReasonString": null, "ReceiveMaximum": 20, "MaximumQoS": "ExactlyOnce", "ResponseInformation": null, "TopicAliasMaximum": 10, "ServerReference": null, "ServerKeepAlive": 0, "SessionExpiryInterval": 0, "SubscriptionIdentifiersAvailable": true, "SharedSubscriptionAvailable": true, "UserProperties": null, "$type": "MqttClientConnectResult"}, "$type": "MqttClientConnectedEventArgs"}.

Troubleshooting Steps Taken:

• Added extensive logging; no exceptions are thrown during disconnects.
• Implemented logic to avoid disconnecting unless explicitly requested from inside app1.
• Attempted to resubscribe to topics after explicitly stopping disconnect, but subscriptions do not recover.

Questions:

• Has anyone encountered similar issues with MQTTnet managed client and Mosquitto?
• Are there known issues or recommended solutions for reliable reconnection and topic resubscription in production environments?
• Any suggestions for further diagnostics or configuration changes?

Temporary Solution:

• Restarting the app1 module restores connectivity and subscriptions.

Any help or insights would be appreciated!

[hannasm]

Have you tried attaching an IMqttClientDisconnectedHandler to The MqttClient.ClientDisconnected event handler and checking the DisconnectReason? There may be some other useful clues about what is happening in the MqttClientDisconnectedEventArgs as well

[qyzhaovisionnav]

Has this issue been resolved in MQTTnet version 5.1.0?