Skip to content
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

Bridge feature not avoiding loops #1263

Closed
vrst37 opened this issue May 7, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@vrst37
Copy link

commented May 7, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

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 ralight added this to the 1.6.3 milestone May 23, 2019

@ralight

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

@goireu

This comment has been minimized.

Copy link

commented May 29, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

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

@goireu

This comment has been minimized.

Copy link

commented May 31, 2019

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 ?

@ralight ralight closed this in cd3877e Jun 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.