-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combination of max_inflight_messages 1
and max_queued_messages 0
causes "Bad socket read/write" error
#3088
Comments
Yep. The problem from 6113eac is here:
I am not brave enough to patch it to:
Since it may be harmful to prevent CVE-2023-28366 from happening again. Another option is to change documentation and make max_queued_messages=0 equals to max_queued_messages=1000, which is the default. @ralight could shed some light on this matter |
Not having the option to have unlimited queued messages does not enable reliable in-order delivery, though. (I realise this isn't achievable in many settings for other reasons but it is in some, in particular mine ;)). Thanks very much for looking into this! |
fixes eclipse#3088 Signed-off-by: Flávio Tapajós <[email protected]>
Mosquitto v2.0.17 - v2.0.18 (latest at time of writing)
Since mosquitto v2.0.17, or more specifically, commit bfb373d ("Fix
max_queued_message 0
stopping clients from receiving messages."), when the following configuration is used:Sending two QoS 2 PUBLISH messages from a client in quick succession produces a "Bad socket read/write" error and disconnects the client.
Full mosquitto output (click to expand)
The following minimal
paho-mqtt
based Python client can be used to reproduce this issue:repro.py
script (click to expand)Run using:
It is the combination of both
max_*
options which triggers this bug -- remove either one and the client can connect and publish successfully.Similarly, if a lower QoS than 2 is used, the bug does not manifest.
Likewise, don't send the two PUBLISH messages in quick succession and the problem goes away too. For example, just send one or put a
time.sleep(1)
between them and the bug does not manifest.Mosquitto 2.0.16 (related, earlier bug)
Though the bug above was first released in mosquitto 2.0.17, the configuration shown also breaks mosquitto 2.0.16 due to a different bug introduced in commit 6113eac ("Fix for CVE-2023-28366"). This bug caused all messages to be dropped when
max_queued_messages 0
is used with the log message "Outgoing messages are being dropped".Full mosquitto 2.0.16 output (click to expand)
In this case, the bug is entirely caused by the
max_queued_messages 0
option and prevents clients from even connecting.It appears that the fix for this bug -- the commit bfb373d ("Fix
max_queued_message 0
stopping clients from receiving messages.") mentioned at the top of this report -- may have been some way incomplete since it introduced a compatibility issue with themax_queued_messages 0
option.Mosquitto 2.0.15 and earlier (works)
Mosquitto 2.0.15 works correctly with both
max_inflight_messages 1
andmax_queued_messages 0
.Other details
I have tested this on Arch Linux using Mosquitto binaries built directly from the repository with default settings. (The same bug does, however, appear in Arch's packaged versions).
The commits identified in this report were found using
git bisect
rather than an exhaustive scan! It is possible (though hopefully unlikely) I've identified the wrong changes. Sorry I haven't had the time to dig any deeper!In case it is relevant, the reason for my use of both
max_inflight_messages 1
andmax_queued_messages 0
is that my application requires guaranteed, in-order delivery of messages, even during bursts of messages. (Naturally, all clients are trusted and any bursts in messages are strictly bounded -- I'm aware of the caveats of using these options!).As ever, thank you so much to everyone for all the hard work in making and maintaining mosquitto!
The text was updated successfully, but these errors were encountered: