"Not Authorised" error when attempting to connect to eu.thethings.network

EDIT: The issue below was caused by me. I leave this as a cautionary tale to check your own network before troubleshooting external dependencies :sweat_smile:


I have an issue with connecting to the TTN MQTT broker to retrieve uplink messages. I have followed the intstructions on the Quick Start page, using the application id as the user name, and the access key as the password, as pasted using the “copy to clipboard” button in the console UI.

I am trying to subscribe to the topic testpi1/devices/pie-one/up, where testpi1is my application id, and pie-one is my device id. The full command line is as follows:

mosquitto_sub -h eu.thethings.network -t 'testpi1/devices/pie-one/up' -u 'testpi1' -P 'ttn-account-v2.the-rest-of-the-key'

My version of Mosquitto is 1.6.7

Am I missing something obvious here? I am able to connect to other authenticated MQTT brokers, including those I have set up myself.

Thank you, and have a great day!

Hi @Zorander, the topic argument, -t, does not use quotes.


mosquitto_sub -h eu.thethings.network -t testpi1/devices/pie-one/up -u ...

I would try first using a topic of just +/devices/+/up before getting more specific.
You can also add -d to get debug info.

Hi @cultsdotelecomatgmai, and thanks for replying.
I’ve used quotes surrounding the topic argument before with other brokers, and it has worked fine. I have ommitted it for this second try, however. I also removed the quotes from the user name and password arguments, but it didn’t make any observable difference.

I made a try with the following command,

mosquitto_sub -h eu.thethings.network -t +/devices/+/up -u 'testpi1' -P 'ttn-account-v2.the-rest-of-the-key' -d 

and I got

Client mosq-nrhcio59Vb0jTkz7Dr sending CONNECT
Client mosq-nrhcio59Vb0jTkz7Dr received CONNACK (5)
Connection error: Connection Refused: not authorised.
Client mosq-nrhcio59Vb0jTkz7Dr sending DISCONNECT

It is almost as if there is something wrong with how I have set up my application. I do get application data if I look in the console, and the payload looks like what I would expect.

In which zone did you create your application? EU or somewhere else?

I created the application in the EU region. The handler is ttn-handler-eu.

Hi again @Zorander, this is probably a stupid question but can you confirm that testpi1 is the name of the application on the TTN core and that the key you are using does have access to the application and the privilege to see data.

Hi again!

The name of the application is indeed “testpi1”, and the key is verbatim as is shown on the page for that application, starting with ttn-account-v2.. It has the permissions devices and mesages.

What does “the name of the application” mean precisely?

Application overview

Are you referring to the Application ID? (You should.)

I’m wondering as well what was meant, but I’ve been using the Application ID.

Anything funny in ~/.config/mosquitto_sub (if that exists)? Did you ever have this work before, with TTN?

This file is nonesistent for me.

This is the first time I’m trying to use any of the TTN brokers. I’ve been able to connect with my own brokers that I use for other projects outside of TTN, as well as the test broker at test.mosquitto.org.

Something is up. I double checked the behaviour with test.mosquitto.org, and for some reason I’m unable to connect to any broker using Mosquitto from any of my machines. I’ll have a look to see if there’s something awry with my ISP.

1 Like

All I can say is that the following works for me, on a Mac with Homebrew’s Mosquitto:

mosquitto_sub -h eu.thethings.network -t +/devices/+/up -u haarlem-app-1 -P ttn-account-v2.dY-adpt5dsB1Py4hRaHJ5uvRf3iaiVYzAGpkBMQWNNw

Feel free to try; I’ll remove the above key, switch off the test node and edit this post later tonight. (Yes, it’s a different application ID than shown in the screenshot I posted.)

This temporary key only has access to messages. You can easily add additional keys; maybe that helps, somehow?

1 Like

Thanks for taking the time to help me. I appreciate it very much.

I found out the problem. By connecting to one of my VPS machines, I was able to access the messages for both your application as well as mine. test.mosquitto.org works fine as well.

The issue was an incorrect Source NAT rule on my firewall. It was simply connecting back to the Mosquitto server that I’m hosting on my internal Kubernetes cluster, and the credentials were of course rejected.

I’ll leave this as a cautionary tale to double check your local network before investigating external services.
Thanks again for your help, all of you. Have a nice evening!

1 Like

Ooops, my last message even had a lowercase -p, rather than the uppercase -P that I actually used after getting an error message about an invalid port number. :slight_smile:

Also, fun fact: removing a key does not invalidate existing MQTT sessions. That is: not immediately; it took about 22 minutes (about 131 messages) in my quick test for the connection to suddenly fail.