LWT and client takeover - mosquitto broker

[kubiajir]

Hi,
we have found a new bug in mosquitto broker. When client A connects with user name 123 to broker and set LWT then another client B connect to the broker with the same user name then the LWT from client A is fired by broker but it should not be. This is regular client takeover and the broker should not sent the LWT message. Same behavior was tested with HiveMQ and the broker didnt sent LWT during client takeover.

Example:
shell 1:
mosquitto_sub -d -h localhost -t home/sensor-problems - observe here the system output

shell 2:
mosquitto_sub -d -i Subscriber123 -h localhost -t home/living-room/temperature --will-topic home/sensor-problems --will-payload "Problem with SubscriberA" -u 123

shell 3:
mosquitto_sub -d -i Subscriber123 -h localhost -t home/living-room/temperature --will-topic home/sensor-problems --will-payload "Problem with SubscriberB" -u 123

Then mosquitto_sub in shell 2 and 3 will star kicking each other in cycles. and In shell 1 will be visible
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberA
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberB
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberA
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberB
....

Tested with mosquitto version 1.5

Regard,
Jiri

[ralight]

This is an area that is not defined in the MQTT 3.1.1 standard that Mosquitto currently uses, so the two projects have interpreted the correct behaviour differently. I note that in MQTT 5, in the case that you describe the server is required to publish the LWT, so I argue that Mosquitto is giving the correct behaviour.

[ralight]

If you have some information to back up that what you describe is the correct behaviour, other than just that it is what HiveMQ does, then please let us know.

[kubiajir]

Hi,
Im not sure if you are correct as In spec 3.1.1 in chap. 3.1.2.5 Will Flag is written that the message should be sent when the connection is closed without receiving DISCONNECT packet. This explanation is a bit confusing as the connection close the MQTT broker. From my point of view it is regular closing because the client cant send DISCONNECT packet as the server ends the communication - the client dont have any way hot to send this packet. The question is if this situation can be described as protocol error - I guess not. Under this condition I dont thing that it behaving correctly. Also it doesnt make sense to send LWT when the client connects again so it is online and not dead.

The MQTT 5 specs says in chap. 3.1.2.5 Will Flag
The Will Message MUST be published after the Network Connection is subsequently closed and either the Will Delay Interval has elapsed or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) or a new Network Connection for the ClientID is opened before the Will Delay Interval has elapsed.

In this case it should not send LTW as the Client A is alive until Client B kick out the Client A.

Just for saving time here are MQTT specs:
MQTT 3.1.1
MQTT 5

[ralight]

MQTT 3.1.1 doesn't adequately cover this situation, which means it is up for interpretation. My position is that the client does not send a DISCONNECT, so it is an unexpected end to the session. I would very much want to know that this was happening, so the LWT should be sent.

For MQTT 5, I see the point that you make, but an alternative viewpoint would be that the Client B session is not active until after Client A has been removed, because it is not allowed to have two clients connected with the same client id at the same time, at which point if your Will Delay Interval is zero (which in MQTT 3 it is), then the LWT should be transmitted. Now I'm not sure I'd want to argue that in reality, but you see there is still ambiguity even version 5. Perhaps a bit of discussion with the committee would sort it out.

I'd like to close this as "won't fix" or "not a bug", because I believe this is down to interpretation of the spec, not something that is spelled out explicitly and do not want to change the existing behaviour. I will certainly be looking at it closely for version 5 though.

[kubiajir]

Hi,
I understood your idea. I have tested another brokers and they are behaved as I have described. Since client A is the same guy as Client B then sending LTW doesnt make a sense. It is a last will, but the client is still alive.

In our case we have developed mobile IoT devices (9k pcs at one place) which are mobile so they are changing their position and connecting to the broker from different places so they are kicking previous connection as it is obsolete. And this behavior are firing LWT so in this case client is alive but reconnects from new location and the old one is dead... Now multiple LWT firing by 9k each time when the device move to the new position. This product is going out next month.

I have proposal: I have created a patch which cover this situation. I can make it as compilation option. Are you interested?