Unable to connect to MQTT server from Node-Red

Hi,

I am now stumped with what I thought would be a simple cog to implement in a bigger solution.

I am unable to connect to my TTN application using MQTT.

I first ran Node-Red within a docker container on a Pi5, which didn’t connect. I just keep getting Connection failed to broker message in the log file.

I tried with TLS and without, using tcp protocol and not, mapping app ports in docker and still nothing.

So I tried directly inside the Pi5 with Node-Red (not in a docker container) and I get the same problem.

I was thinking it might be network related, so removed all ‘iptables’ on the Pi5 (alllowing all traffic) and still no luck.

Convinced it might be my home network, I now have a Node-Red instance running in the cloud (FlowFuse) and get the same message, again using all options I can think of.

The only connection I have been able to make it using MQTT Explorer on my Mac, and using npx mqtt sub from a command line.

That got me thinking it must be the MQTT node in Node-Red, so I connected it to the free Mosquitto server, and there were no problems at all.

The server I am connecting to is eu1.cloud.thethings.industries for which I get the same IP resolution each time…

Does anyone have any other ideas or thoughts as to why this might be happening.

Does anyone know how to view detailed logs on The Things Stack application to even see if the connection is being refused?

Many thanks,

Tim

Update:

I just tested with a ‘put aside for now’ application on The Things Network (not Stack) and it has connected fine.

Maybe it is a TTS limitation issue? (Again I would like to find out how to know fir sure)

Obvious questions:

  • are you connecting to the same server with both the Mac client and node red?
  • are you using the same credentials?
  • connecting to the same port? Both the secure port? Does the node red machine trust the certificate provided?
  • are you using the same topic?

Many thanks for your reply.

Same server, same user credentials, both with and without TLS (MQTT Explorer works with and without TLS), same topic…

I have tried to keep the same where ever so that once I get a connection that works and I understand, I can re-configure it in the place I actually want it.

I was convinced it was at my [network] end, but when using FuseFlow I get the same, ruling out my network.

I am starting to think it is a resource limit

Update:

On my Mac:
Running with MQTT Explorer client - it works.
Running with MQTTX client - it works.

On Pi 5:
Running with command "npx mqtt sub… " it works

All of them at the same time, same credentials to same MQTT server etc… it works!

Perhaps the Node-Red node is the issue?

Most likely as the resource limit idea would be an issue if you tried to connect 50+ clients at the same time, but not one.

You could spin up a virtual Debian on your Mac to try out Node-RED - not exactly the same as running on a Pi but close enough as all the sources are the same.

So I tried…

Docker container with Node-Red running on my Mac - not working
Node-Red, running directly on my Mac - not working.

Every test with Node-Red doesn’t work, but other client connections do.

BUT… Node-Red connecting to Mosquitto MQTT broker, works.

Debug in Node-Red only gives me ‘Connection failed to broker’ message and nothing more meaningful.

What do you see in your application consol log?

You are limited to the amount of MQTT connections (that is from TTN)

Drop all you other connections (MAC …), make sure the connection are disconnected, and then try again.

I have dropped all other connections that I can, including user sessions listed in the CLI).

Still no luck.

I am unable to see if there are any ‘active’ MQTT sessions (as in I don’t know where to look either)

I guessed there might be a limit on MQTT connections to TTN, and have tried looking for the setting (on the cloud discovery version) but only found settings for on-premise deployments.

But then what confuses me is that I can get multiple clients connecting at the same time, all with same credentials etc and from different machines, but not the Node-Red connections.

Update: Running wareshark to capture the network traffic shows the return code as
Return Code: Connection Refused: not authorized (5)

I can also confirm that it is sending the connection request as MQTT version 3.1.1 (one thought I had was the wrong protocol version)

SUCCESS!!!

Update:
I compared the Wireshark logs between NodeRed and MQTTX to see if there were any differences.

Thankfully, the trace shows Msg length, ClientID length, User length etc…

It seems that when the user name has been copied into NodeRed, an extra space has been left at the beginning. which I have missed when I have checked all else.

It has not left an extra space in front of the password, so maybe a UI issue in NodeRed, or simply user error.
(Strange how it wasn’t return incorrect credentials user code though)

My NodeRed(s) are now all connecting with no issues.

Many thanks to those who have helped, and good luck to anyone else to find this and it helps them too.

Tim

Not, as I have a few Node-Red MQTT connection, and never had this issues

I have tested to see if there is a space in the username field for MQTT already, which remains when the username is pasted in.

The results of my test are that the space is stored in my password manager at the start of the username, so it is being copied from there.

User error, as most things can be. Sorry for wasting anyones time.

Tim

Will most probably help someone in the future, glad you found the issue.