MQTT not connecting over LAN

I have a device that hosts node-red and my mqtt broker. I'm working on transitioning the node-red to a different host with more memory and I'm running into difficulties connecting to the mqqt broker on my original device. Both devices are on my local network, so I'm using the IP address of the device hosting the mqtt broker instead. However, it's simply not connecting and I'm wondering if somebody can assist me with troubleshooting steps. I have included some screen shots that might better illustrate what I'm working with.

When I do a trace route from my new node-red host to the mqtt broker, there's a single hop between the two devices.

I opened ports 1883 and 8883 on the firewall of both devices, so I'm assuming the firewall is not the issue.

I can connect to the mqtt:// on my new node-red host device.

Thanks for any help!!


Can you ping the other device where the broker is running?

If you can, then perhaps that broker is only bound to localhost (it may be a setting in that broker)

Failing that, install mosquito or anther broker as a test.

You could even try the node-red-contrib-eades MQTT broker inside node-red.

Looks like your broker device is an embedded industrial unit?

Have you checked their support for help?

You are right, it is an industrial unit and the broker is installed on the unit. I have worked with their support personal, and they said it should work but they are not very good at helping with troubleshooting.

Yes, I can ping the other device when the broker is running.
The vendor where I bought the unit from, said it is not bound to localhost only...supposed to work across a network.

I will try to install the node-red-contrib-eades MQTT broker inside node-red and see what I find.

Can you connect to the broker from the command line using mosquitto_sub?
Or mqtt_explorer?

Hi Colin, I'm very new with Node-Red. Can you give me more details how I should do this?

He's trying to get you to figure out where your issue is.
Download mqtt explorer to you pc and enter the IP of your broker - see if that connects.

Do that from the other pc (where you're trying to get node-red connecting to the broker)

Ps, did you try pinging the broker IP from the node-red machine as I suggested earlier? Did it work? It will at least prove IP connectivity.

Edit. Just realised you can ping. Is that from the node-red machine to the broker box?

Thanks for the help Steve-Mcl. As you suggested, I tried to connect to my broker with the app using its IP address and it could not connect. I was able to connect to two test brokers with the app. So the issue seems to be my broker??

I can ping the broker box from my Node-Red machine. That seems to work fine.

It does indeed seen to be the broker from what you've said. Get back in touch with support - or - switch it off and use your own (mosquito or the node for node red I mentioned earlier)

Quick question: What machine is the MQTT host and what machine/s are you using?

I chirp in my thoughts.

I thought I was the only person who didn't use DHCP for IP allocation.

I'm taking it your devices are fixed IP addresses?

Because if they aren't there's a whole lot of problems there.

However, I agree with the suggestion of getting MQTT-explorer.

@Colin suggested you try it from the CLI / Terminal.
You have to install some of the MQTT stuff, and sorry I can't name them off the top of my head.

But basically you open a CLI / Terminal on a remote machine and see if the MQTT works.
Nothing to do with node-red.

But installing the MQTT broker on a RasPi is not hard at all. I did it and it works.

Good luck.

I ended up having to install a third party broker on my machine running node-red and it instantly connected. Seems like the broker on my original unit is bound to localhost, even though their support claims it should work.

That isn't necessarily 100% definitive mind.

Remember, your new broker is local to your node red install (same situation as you had originally) & therefore it works (LAN is taken out of the scenario)

There could still be a number of factors preventing communication across LAN.

machine 1 could have a simple setting to enable/disable LAN access.

machine 1 might have a firewall and require port 1883 to be open on ETH0 (out whatever interface it uses)

Machine 1 firmware might require update.

Machine 2 firewall might be preventing 1883 outbound

Router might not be permitting port 1883


That all said, if you are happy with your current solution then all is well.

I'm not totally satisfied with this solution, but I'm relieved that it's finally working after spending tons of time try to find the problem. Will probably have more time to troubleshoot sometime later....

Having it bound to by default is obviously better for security - so I would also do that if I was shipping a generic product. It is probably a configuration option somewhere to change that to (ie all interfaces)

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.