Bug: Inflight configuration is ignored. V2.0.16

[inwavetech]

Problem:

That is no supported for multiple publication where queueing message is necessary. For example, when I send multiples messages in quickly succession (QoS=2)
PS: I lost my messages... 😔

Conclusion

Inflight configuration is ignored.

Version:

2.0.16

Lines:

mosquitto/src/context.c

Lines 86 to 89 in 6113eac

	context->msgs_in.inflight_maximum = 1;
	context->msgs_out.inflight_maximum = db.config->max_inflight_messages;
	context->msgs_in.inflight_quota = 1;
	context->msgs_out.inflight_quota = db.config->max_inflight_messages;

Proposed Fix:

Use 2.0.15 code lines.

mosquitto/src/context.c

Lines 86 to 89 in b027786

	context->msgs_in.inflight_maximum = db.config->max_inflight_messages;
	context->msgs_out.inflight_maximum = db.config->max_inflight_messages;
	context->msgs_in.inflight_quota = db.config->max_inflight_messages;
	context->msgs_out.inflight_quota = db.config->max_inflight_messages;

[Daedaluz]

I haven't had time to investigate much yet, but i seem to at least hit a similar / related bug (maybe even this) having max_queued_messages 0 which causes all messages to drop (looks like).

[inwavetech]

In my case configuration is:

max_inflight_messages 1000
max_inflight_bytes 1000
max_queued_messages 32000

listener xxx
protocol mqtt
log_type all
connection xxx
addressxxx
remote_username xxxx
remote_password xxxxxx
remote_clientid xxxx
bridge_cafile xxxx
bridge_certfile xxx
bridge_keyfile xxxx

bridge_insecure xxxx
allow_anonymous xxxx
require_certificate xxx

keepalive_interval 10

cleansession false
#try_private false
bridge_attempt_unsubscribe false

topic xxxxx/# both 2

cafile xxxx
certfile xxxx
keyfile xxxx

Pseudo Code client:

publish(topic, message, qos=2)
publish(topic + "/123", message, qos=2)

First message is always ok.
But second messages is dropped (mosquitto received, but don't forward)

[karlp]

Yeah, I have max_queued_messages 0, as well, and I'm seeing alllll messages dropped until I remove that from my config. I can't even do a "mosquitto_sub -t "#" -d" test, it just hangs. Removing the max queued messages 0 config fixes things...

[inwavetech]

But in this case the configuration max_queued_messages is not 0...

max_queued_messages 32000

[ckrey]

I can confirm messages are lost if the

• receiving end of a bridge runs 2.0.16
• QOS 2 is used (no problem with QOS 1 or QOS 0)
• the bridge protocol is mqttv311 (default)

If you change to bridge_protocol_version mqttv50 the problem disappears because in MQTTv5 the inflight window size is communicated from the broker to the client in the CONNACK message

If you are using an ancient version of mosquitto on the sending end of the bridge, you can get around the problem by lowering your QOS from 2 to 1

[ckrey]

This is a really a problem I don’t know how to work around

This script:

echo "1" > mosquitto.lines
echo "2" >> mosquitto.lines
echo "3" >> mosquitto.lines
mosquitto_pub -t "test" -l <mosquitto.lines -q 2 -d -i testing151 -V mqttv5

fails with a mosquitto 2.0.16 in default configuration (max_inflight_messages default to 20)
I would expect the client respects the "Receive Maximum" transmitted by the broker in the CONNACK message

Output

Client testing151 sending CONNECT
Client testing151 received CONNACK (0)
Client testing151 sending PUBLISH (d0, q2, r0, m1, 'test', ... (1 bytes))
Client testing151 sending PUBLISH (d0, q2, r0, m2, 'test', ... (1 bytes))
Client testing151 sending PUBLISH (d0, q2, r0, m3, 'test', ... (1 bytes))
Client testing151 received PUBREC (Mid: 1)
Client testing151 sending PUBREL (m1)
Client testing151 received PUBREC (Mid: 2)
Warning: Publish 2 failed: Quota exceeded.
Client testing151 received PUBREC (Mid: 3)
Client testing151 sending PUBREL (m3)
Client testing151 received PUBCOMP (Mid: 1, RC:0)
Client testing151 received PUBCOMP (Mid: 3, RC:0)
Client testing151 sending DISCONNECT

[ckrey]

The net effect of this problem is loosing messages when using QoS 2!
Rolling back to mosquitto 2.0.14 (because 2.0.15 is not avaiable for Debian) solves the issue for the moment.

[ckrey]

The problem caused because the "Receive Maximum" property is not set properly in the CONNACK message. This causes even MQTTv5 clients cannot react to the limitation and run into the "quota exceeded" error.

In the CONNACK the "Receive Maximum" is still indicating the configured value rather than "1"

src/send_connack.c:

 63                 if(reason_code < 128 && db.config->max_inflight_messages > 0){
 64                         rc = mosquitto_property_add_int16(&connack_props, MQTT_PROP_RECEIVE_MAXIMUM, db.config->max_inflight_messages);
 65                         if(rc){
 66                                 mosquitto_property_free_all(&connack_props);
 67                                 return rc;
 68                         }
 69                 }

[Xalalau]

The proposed fix solves the issue.