Open MathiasLopes opened 6 days ago
After somes tests, the last version where it's worked is the 2.0.11
@MathiasLopes can you elaborate which client software you use and the steps necessary to reproduce the proble? I cannot reproduce your problem with mosquitto_pub/sub
@ckrey I have used twos differents clients softwares : MQTTX and the other is my self implementation with MQTTnet. For the steps :
At this point, with CleanStart=false, the subscriber should retrieve every subscription (this works because if I send another message from client1, client2 receives it), but it should also retrieve missed messages, and this is not the behavior that occurs.
Thank you for your reply
This is actually my complete configuration for Mosquitto :
#GLOBAL CONFIGURATION ===================================
persistence true
persistence_location /mosquitto/data
connection_messages true
log_type all
log_dest file /mosquitto/log/mosquitto.log
persistent_client_expiration 1y
max_queued_messages 5000
per_listener_settings true
#Authentication by username/password
listener 1883 0.0.0.0
allow_anonymous true
#password_file /mosquitto/config/password_file
#TLS and authentication by username/password
listener 8883 0.0.0.0
allow_anonymous false
cafile /mosquitto/config/certs/ca.crt
certfile /mosquitto/config/certs/server.crt
keyfile /mosquitto/config/certs/server.key
#tls_version tlsv1.3
#ciphers_tls1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
password_file /mosquitto/config/password_file
#TLS and authentication by certificate only
listener 8884 0.0.0.0
allow_anonymous true
cafile /mosquitto/config/certs/ca.crt
certfile /mosquitto/config/certs/server.crt
keyfile /mosquitto/config/certs/server.key
require_certificate true
tls_version tlsv1.2
#ciphers_tls1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
#TLS and authentication by certificate and username/password
listener 8885 0.0.0.0
allow_anonymous false
cafile /mosquitto/config/certs/ca.crt
certfile /mosquitto/config/certs/server.crt
keyfile /mosquitto/config/certs/server.key
password_file /mosquitto/config/password_file
require_certificate true
I assume you are using MQTTv5 (CleanStart was defined in MQTTv5).
I cannot reproduce your problem with MQTTX, it works as expected.
In your own implementation, do you set the "Session Expiry Interval" explicitly? This is important because the default is zero, which means the session is discarded by the broker on disconnect.
If this is not the problem, please attach the relevant part of the log file /mosquitto/log/mosquitto.log
Yes I use MQTTv5 and yes when I login with the client I have set 600 for the value of Session Expiry Interval.
Here are the logs of the behavior defined above from Mosquitto with MQTTX client :
1719492741: New connection from 192.168.208.1:39964 on port 1883.
1719492741: New client connected from 192.168.208.1:39964 as Client1 (p5, c1, k60, u'admin').
1719492741: No will message specified.
1719492741: Sending CONNACK to Client1 (0, 0)
1719492745: New connection from 192.168.208.1:33122 on port 1883.
1719492745: New client connected from 192.168.208.1:33122 as Client2 (p5, c0, k60, u'admin').
1719492745: No will message specified.
1719492745: Sending CONNACK to Client2 (1, 0)
1719492745: Received SUBSCRIBE from Client2
1719492745: clean_session_false (QoS 1)
1719492745: Client2 1 clean_session_false
1719492745: Sending SUBACK to Client2
1719492756: Received PUBLISH from Client1 (d0, q1, r0, m57655, 'clean_session_false', ... (19 bytes))
1719492756: Sending PUBLISH to Client2 (d0, q1, r0, m5, 'clean_session_false', ... (19 bytes))
1719492756: Sending PUBACK to Client1 (m57655, rc0)
1719492756: Received PUBACK from Client2 (Mid: 5, RC:0)
1719492764: Received DISCONNECT from Client2
1719492764: Client Client2 disconnected.
1719492773: Received PUBLISH from Client1 (d0, q1, r0, m57656, 'clean_session_false', ... (19 bytes))
1719492773: Sending PUBACK to Client1 (m57656, rc0)
1719492782: New connection from 192.168.208.1:52304 on port 1883.
1719492782: New client connected from 192.168.208.1:52304 as Client2 (p5, c0, k60, u'admin').
1719492782: No will message specified.
1719492782: Sending CONNACK to Client2 (1, 0)
1719492782: Received SUBSCRIBE from Client2
1719492782: clean_session_false (QoS 1)
1719492782: Client2 1 clean_session_false
1719492782: Sending SUBACK to Client2
Here are the logs of the behavior defined above from Mosquitto with my client (not exaclty the same behavior because MQTTX re-subscribe topics automatically at connect) :
1719492998: New connection from 192.168.208.1:33192 on port 1883.
1719492998: New client connected from 192.168.208.1:33192 as Client1 (p5, c0, k15, u'admin').
1719492998: No will message specified.
1719492998: Sending CONNACK to Client1 (0, 0)
1719493001: New connection from 192.168.208.1:33208 on port 1883.
1719493001: New client connected from 192.168.208.1:33208 as Client2 (p5, c0, k15, u'admin').
1719493001: No will message specified.
1719493001: Sending CONNACK to Client2 (1, 0)
1719493013: Received PINGREQ from Client1
1719493013: Sending PINGRESP to Client1
1719493016: Received PINGREQ from Client2
1719493016: Sending PINGRESP to Client2
1719493028: Received PINGREQ from Client1
1719493028: Sending PINGRESP to Client1
1719493029: Received SUBSCRIBE from Client2
1719493029: clean_session_false (QoS 1)
1719493029: Client2 1 clean_session_false
1719493029: Sending SUBACK to Client2
1719493044: Received PINGREQ from Client1
1719493044: Sending PINGRESP to Client1
1719493044: Received PINGREQ from Client2
1719493044: Sending PINGRESP to Client2
1719493059: Received PINGREQ from Client1
1719493059: Sending PINGRESP to Client1
1719493059: Received PINGREQ from Client2
1719493059: Sending PINGRESP to Client2
1719493064: Received PUBLISH from Client1 (d0, q1, r0, m1, 'clean_session_false', ... (5 bytes))
1719493064: Sending PUBLISH to Client2 (d0, q1, r0, m6, 'clean_session_false', ... (5 bytes))
1719493064: Sending PUBACK to Client1 (m1, rc0)
1719493064: Received PUBACK from Client2 (Mid: 6, RC:0)
1719493079: Received PINGREQ from Client2
1719493079: Sending PINGRESP to Client2
1719493079: Received PINGREQ from Client1
1719493079: Sending PINGRESP to Client1
1719493083: Received DISCONNECT from Client2
1719493083: Client Client2 disconnected.
1719493094: Received PINGREQ from Client1
1719493094: Sending PINGRESP to Client1
1719493103: Received PUBLISH from Client1 (d0, q1, r0, m2, 'clean_session_false', ... (5 bytes))
1719493103: Sending PUBACK to Client1 (m2, rc0)
1719493118: New connection from 192.168.208.1:47546 on port 1883.
1719493118: New client connected from 192.168.208.1:47546 as Client2 (p5, c0, k15, u'admin').
1719493118: No will message specified.
1719493118: Sending CONNACK to Client2 (1, 0)
1719493118: Received PINGREQ from Client1
1719493118: Sending PINGRESP to Client1
Thank you for your help
I'm currently experiencing a problem with versoin 2.0.18. When I publish a message on a topic and the client who is supposed to receive the message is disconnected, after reconnecting he can't retrieve his message. My configuration is fine because I've tested it with other broker messages and it works. CleanSession=false Subscription=QoS 1 Send message = QoS 1 However, the subscription is recovered because if I send a message from the publisher after reconnecting the receiver, he receives the new message without having to subscribe to the topic again. What's more, with the same configuration, downgrading to Mosquitto version 1.6, the system works.
I use this image : https://hub.docker.com/_/eclipse-mosquitto