Announcing staging environment of TTN Back-end 1.0

Hi,

After the update our gateway has disappeared from ttnstatus and ttnmap. Are these tools linked to the new backend or not?

Yes, all traffic is forwarded to the existing croft prototype, so they should end up on ttnstatus.org and thethingsnetwork.org/map, as before.

In a private offline network (see wiki), you can implement your own authentication mechanism. It is still token-based, but you can issue your own tokens and disable authentication on MQTT, for example.

The same frequency of Australia will be used in Brazil

Yep… And the US frequencies in South America (except Brazil) and Canada. And there are a lot more exceptions, so we’ll probably build a list where you can find the correct frequency for each country.

Ah, that was the last missing puzzle piece in my application - that the DevEUI in the mqtt topic is the DevAddr (like 02E00202) with 8 pre-pended zeros. Actually discovered it by subscribing with wildcards ( +/devices/+/up ) in nodejs, and then printing out the topic when a message came in! Working great now…

Hi @johan, could you explain me a bit more how to disable authentication on mosquitto and the token based mechanism?

I create my server using Docker with this configuration file, where I commented out these two lines

  - TTN_HANDLER_MQTT_USERNAME=yourusername        # You don't need this if you use 
  - TTN_HANDLER_MQTT_PASSWORD=yourpassword        #   the default mosquitto server
  - TTN_BROKER_ACCOUNT_SERVER=https://account.thethingsnetwork.org

However running the backend mosquitto does not fail but the broker does with this error

broker_1 | FATAL Broker has fallen… error=Invalid operation: Failed to refresh token key: Get https://account.thethingsnetwork.org/key2: dial tcp: lookup account.thethingsnetwork.org on 127.0.0.11:53: read udp 127.0.0.1:46121->127.0.0.11:53: i/o timeout

Thank you very much in advance,

I tried ttn on a private server (Docker-based deployment). It looks pretty good.
Thanks again to all involved!

Some remarks:

  • For downlink and mqtt, use (for example):
    {“payload”:“SGVsbG8gd29ybGQK”,“port”:1,“ttl”:“1h”}

    If I use (from the wiki):
    { payload: ‘SGVsbG8gd29ybGQK’, port: 1, ttl: ‘1h’ }
    it doesn’t work.

  • If I “downlink” in using (for example) port 15 (or an other) my node (RN2483 based)
    always received on the port 1.

BR

Thanks @laura, I’ll update the wiki. The only difference is the JSON formatting, right?

We’re using tokens to authenticate and authorize users and applications. The tokens are issued by the account server. You can issue your own tokens if you implement your own account server too. We did not publish specifications for that yet because it is still in development. Tokens are signed with a private key and can be validated with a public key. This public key is required in the Broker to check if the token from the client (e.g. ttnctl) is valid.

It looks like you try to get the wrong key; the Broker tries to get the public key for validating the token from https://account.thethingsnetwork.org/key. The Broker tries this on start-up. If it fails, because there’s no internet, then the cached key is used. So make sure that your start the Broker at least once with an internet connection.

1 Like

I’m really struggling to get a device registered.

I use the standard command and I’m getting the following error message. I’ve managed to get the re-configured etc.
Setup up new account and password
Setup and Application
Associate the application

./ttnctl devices register personalized 02D1DD03
INFO Generating random NwkSKey and AppSKey…
FATAL Could not register device error=rpc error: code = 2 desc = Invalid operation: rpc error: code = 2 desc = Invalid operation: Unauthorized

I’m clearly missing something obvious here!

Did you use the ttnctl applications use <AppEUI> command to activate your newly created application? See the AppEUI in the overview you get with ttnctl applications.

Yes did that. And got an affirmative result

ttnctl applications use 008000000000xxxx
INFO You are now using application 008000000000xxxx.

That is the gateway, not the AppEUI.

in the wiki could we add, it might make it a bit more clear for idiots like mw who need spoon feeding every command.

Application Management

Now create a new application with ttnctl applications create. In this example we will create an application named Hello World App. The

❯ ttnctl applications create ‘Hello World App’
INFO Application created successfully
If you work in a group, you can authorize your colleagues to manage the application with the ttnctl applications authorize command:

*Now type this to provide all the running details for you’re application. *
*> ttnctl applications *
EUI Name Owner Access Keys Valid
xxxxxxxxxxx xxx test1 test1@txxxx.xyz xxxxxxxxxxxxxxxxxxxxxxxxxxxxx= true

❯ ttnctl applications authorize 0807060504030201 john@doe.org
INFO User authorised successfully

Thats the bit I clearly missed

2 Likes

Still have to make that work :wink:

See issue #127

I guess that once it id comletely develop you would provide some guide in order to know how to interface with a private account server too right?

Then that means too that for now if I want to use the TTN backed for a private network, I have to register my nodes into the TTN devices server otherwise I won’t see any traffic from my nodes since if they are not register, the broker wouldn’t allow them have access to the network, am I right?

I did it once, and now I don get the starting error in the broker, :smiley:, thanks @johan

Yes. It’s basically OAuth 2.0.

The account server tracks user information and applications only. The devices and their security keys are registered in the handler. You can easily use TTN’s account server for private networks. Only in offline scenarios you would need a local account server.

1 Like

Hi all,

Concerning downlink and mqtt…

How is managed the downlink? Only the last request is kept (it seems the case; the node reveives only the downlink data from the last request)? The requests are queued in a fifo?

Thanks to the community and the core development team!

It is indeed a queue of size 1. We’re considering fifo and make the queue size configurable. We decided not to build it this way to keep it simple, both the handling of messages and configuration options. If you need this feature, please raise an issue on GitHub cause it’s not there yet.