Node-Red will not connect to Mosquitto broker

General
1

Brand new install of Node-Red on a VM in a docker container. Same machine that is running the broker but Mosquitto is not in a docker container. From the mosquitto clients CLI I can connect from another VM to the broker and pub and sub no problem. I have tried using both the IP and localhost as the server address in the node setup for the broker. Nothing works. Do I need to have username/password setup in order for node-red to connect?

2

I suspect this may be due to the fact that, with mosquitto 2.0 and above, to access from a different machine (which a VM effectively is) you have to tell mosquitto to allow that. Assuming you are running Linux then create a file /etc/mosquitto/conf.d/mossy.conf (or anything_else.conf) and in there put

listener 1883
allow_anonymous true

If you also want to allow websockets access then include

listener 9001
protocol websockets

Then restart mosquitto.

3

Colin

I have all that in my config file. I can publish and subscribe to the mosquitto broker from other machines.

4

OK. If you open a terminal in the VM can you ping the mosquito IP? The same IP you use to access it from other machines?

If you can, then if you open a terminal in the docker container can you ping the mosquito IP?

If you can, then can a ping node in node red see it?

5

Yes, yes and yes.

6

Check in the mosquito log to see what it says when it attempts to connect.

7

1633963616: New connection from 143.198.31.97:61953 on port 1883.

1633963618: Client disconnected due to malformed packet.

8

Strange.
Can you export and paste an MQTT In node that attempts to use the broker please.

9 
[
    {
        "id": "f6f2187d.f17ca8",
        "type": "tab",
        "label": "Flow 1",
        "disabled": false,
        "info": ""
    },
    {
        "id": "3cc11d24.ff01a2",
        "type": "comment",
        "z": "f6f2187d.f17ca8",
        "name": "WARNING: please check you have started this container with a volume that is mounted to /data\\n otherwise any flow changes are lost when you redeploy or upgrade the container\\n (e.g. upgrade to a more recent node-red docker image).\\n  If you are using named volumes you can ignore this warning.\\n Double click or see info side panel to learn how to start Node-RED in Docker to save your work",
        "info": "\nTo start docker with a bind mount volume (-v option), for example:\n\n```\ndocker run -it -p 1880:1880 -v /home/user/node_red_data:/data --name mynodered nodered/node-red\n```\n\nwhere `/home/user/node_red_data` is a directory on your host machine where you want to store your flows.\n\nIf you do not do this then you can experiment and redploy flows, but if you restart or upgrade the container the flows will be disconnected and lost. \n\nThey will still exist in a hidden data volume, which can be recovered using standard docker techniques, but that is much more complex than just starting with a named volume as described above.",
        "x": 350,
        "y": 80,
        "wires": []
    },
    {
        "id": "c027958f309beed5",
        "type": "mqtt in",
        "z": "f6f2187d.f17ca8",
        "name": "Temp",
        "topic": "sensors/temp",
        "qos": "2",
        "datatype": "auto",
        "broker": "75052b80bc9f0b1d",
        "nl": false,
        "rap": true,
        "rh": 0,
        "x": 360,
        "y": 340,
        "wires": [
            [
                "9b75e913e79a3820"
            ]
        ]
    },
    {
        "id": "9b75e913e79a3820",
        "type": "debug",
        "z": "f6f2187d.f17ca8",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 700,
        "y": 240,
        "wires": []
    },
    {
        "id": "75052b80bc9f0b1d",
        "type": "mqtt-broker",
        "name": "Linode Broker",
        "broker": "22.29.22.192",
        "port": "1883",
        "clientid": "",
        "usetls": false,
        "protocolVersion": "4",
        "keepalive": "60",
        "cleansession": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "birthMsg": {},
        "closeTopic": "",
        "closeQos": "0",
        "closePayload": "",
        "closeMsg": {},
        "willTopic": "",
        "willQos": "0",
        "willPayload": "",
        "willMsg": {},
        "sessionExpiry": ""
    }
]
10

22.29.22.192 is a unusual ip address to be accessing a broker on. Are you going across the internet? Otherwise I would normally expect the ip to be a local network address.

Is the IP of the VM 143.198.31.97?

11

Ha ya I changed up the VM's IP before posting. But the broker and the NodeRed instance are on the same VM. I've tried going accessing across the internet(VM IP), localhost, 127.0.0.1, and the container name. None have worked. They are configured in bridge mode for the network. It is odd that the IP address is different than the VM's in the log. It is hosted on Linode.

12

What address did you use for the ping test?

13

I was pinging 22.29.22.192

14

I think maybe you need to work out why the IP in the mosquito log is apparently wrong.

15

I am still struggling a bit with working out what you are doing. Is 22.29.22.192 the address of the VM? If so then that is what you should be using in the MQTT config, so that looks right.
However 143.198.31.97 aught to be the ip of the bridge network for the container, I think, but it is actually a publicly accessible machine somewhere, so I have no idea what is going on.

16

22.29.22.192 is the VM's IP. No idea either. I have ended up running node red on another vm and it all works now. Who knows. Thanks for all the help!

17

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