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

Zorander · December 1, 2019, 11:46am

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

Hello!

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!
/Fredrik

cultsdotelecomatgmai · December 1, 2019, 2:22pm

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

Try:

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.

Zorander · December 1, 2019, 3:03pm

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.

kersing · December 1, 2019, 6:22pm

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

Zorander · December 1, 2019, 6:49pm

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

cultsdotelecomatgmai · December 1, 2019, 7:10pm

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.

Zorander · December 1, 2019, 7:23pm

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.

arjanvanb · December 1, 2019, 7:28pm

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

Application overview

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

Zorander · December 1, 2019, 7:35pm

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

arjanvanb · December 1, 2019, 7:36pm

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

Zorander · December 1, 2019, 7:46pm

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.

Zorander · December 1, 2019, 7:52pm

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.

arjanvanb · December 1, 2019, 7:55pm

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?

Zorander · December 1, 2019, 8:01pm

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!

arjanvanb · December 1, 2019, 8:09pm

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.

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.