Bridge feature not avoiding loops

[vrst37]

Background:

A few months ago I was developing an mqtt bridge (a program that would make sure two brokers see the same set of messages by subscribing to # on both brokers and forwarding data). We are not doing any topic remapping.

Description

The problem was when I subscribed to #, I got my own messages delivered back to me causing an endless message storm and loop. I wanted to be able to forward the data between two brokers using my own code without having to parse the messages. So I wanted mosquitto broker to not send me data that I published. I looked around a bit and found that mosquitto supports briding and decided to use the way they have solved the problem. @ralight described the solution here in 4th post from top. This is also explained in the try_private configuration parameter in the mosquitto documentation.

So I implemented the solution in python paho library to support bridge mode. Link is here and got it in the master.

The Bug

A few days ago Mosquitto released a new version for the ubuntu channel (Version 1.6.2) and I noticed that the bridge mode is not working. When I publish the message in bridge mode after subscribing to # on broker version 1.6.1 I get that same message back, however in many 1.5.* and 1.4.* I am not getting the same message back.

Question
Is this is a bug or has the mosquitto specification been changed?

The reason I wrote such a detailed post is so this document can also serve as information archive in the future.

Test Code
I am using paho python mqtt client version 1.4.0

import paho.mqtt.client as mqtt
from time import sleep

def on_connect(client, userdata, flags, rc):
    print("Connected with result code "+str(rc))
    # subscribing
    client.subscribe("123")
    # now publishing
    client.publish("123", "456")

def on_message(client, userdata, msg):
    print(msg.topic+" "+str(msg.payload))

client = mqtt.Client()
client.enable_bridge_mode()
client.on_connect = on_connect
client.on_message = on_message

client.connect("127.0.0.1", 1885, 60)

client.loop_start()

while True:
    sleep(5)

[ralight]

There have been a lot of changes due to the MQTT v5 work, so it is possible this has indeed broken. I'll take a look tomorrow.

[ralight]

I believe this is fixed, if you want to confirm if for yourself, please check out the fixes branch.

[goireu]

May not be the right place to ask but, I see bridging is not handled in case protocol between brokers is MQTTv5, I expect setting up a bridge will cause trouble if clients use MQTTv5 right ?

[ralight]

It shouldn't matter, although v5 properties won't be propagated of course.

[goireu]

Then I guess we should consider bridging should be avoided with MQTT5 clients. How would you rate the effort to get full MQTT5 bridging available ?