Subscribed Topics not published anymore after one PubAck is missing from Client (Outgoing messages are being dropped to a client)

[NaCkhaYeD]

Dear Support,

i have three clients connected to a mosquitto mqtt broker. One of the client is the "master". There is also the mqtt server running.
The other two clients are "slaves". Between the "master" and the "slaves" is a control word request/response implemented to register disconnects (two topics, interval one second).
The "master" also checks the mqtt server by subscribing the $sys.broker.uptime topic. It is only looking for a change.

If i switch of the two "slaves", there is a time comming, i will see inside the log "Outgoing messages are being dropped". That is correct, i understand.
But nearly at the same time, i will not receive anymore the $sys.broker.uptime topic, even if the two clients come back.

Is this a bug, or a normal behaviour?
I think it is a bug. Even if the outgoing messages are droped, i should receive the stats from the server. There are different topics, isn´t it?

The machine, where the mqtt server is running, is a Win10 IoT LTSB 2019. The running version of the mqtt server is 2.0.20, but it happens also with earlier versions.

with regards
Thomas

[ckrey]

What is your server configuration especially regarding max_queued_messages?
Which QoS do you use for the subscriptions?
Do you use different clientIDs for the 3 clients?
The "Outgoing messages are being dropped" should be affecting only the corresponding off-line client.
Can you recreate the problem with mosquitto_sub and mosquitto_pub? I tried, but the uptime messages continue to be received.

[NaCkhaYeD]

Dear all,

it is not only the "$Sys" message.

I now analyzed my traffic with wireshark.
As long the mosquitto mqtt server received a puback message after publish a topic everything will be fine.
Due to the moment, exactly one published topic will not answered by a puback message from the client, the client will not receive any topics during the existing session.

The client itself, can publish topics and they will be answered by the server.
Also other sessions with different clients will not be affected.

To came out of this situation, I have to restart the mosquitto service, or the disconnect and connect the client again.

I definitly think, this is a bug. A not answered message can happen all the time.

Attached you will see a short time frame of my wireshark. The problem will be at No. 67076.
MQTT Fault.zip

Mosquitto version is 2.0.20, but this issue was also seen on 2.0.18.
mosquitto.conf.txt

max_queued_messages is default 1000
I only use Qos 0. Fire and Forget

Yes, I use different ClientIDs, but it happend also with exactly one client.

[ckrey]

Sorry, but if you only use QoS 0, there is no PUBACK as a response to a PUBLISH.

The attached .zip file is corrupt. But anyhow, mosquitto seems to work according to the standard definition Flow Control.

Why does your client not answer the PUBLISH with a PUBACK? Which client library do you use?

[NaCkhaYeD]

Sorry,

my mistake. I subscribed with QoS1 , thats why an puback is coming.
Anyway, why does the server not publishing to client if one puback is missing?

There should be at least a request to Reset (i think thats not in the protocoll), or a forced disconnect.

[ckrey]

Well, this is the way MQTT is defined:

• mandatory PUBACKs, no timeouts other than for keepalive
• in order message transmission
• no retransmission during a connection
• reset by disconnect/reconnect.

If your client is not able to send PUBACK, it should disconnect and reconnect. All not PUBACKed messages will be resent by the broker