New addresses for cloud services: update your gateways

As we are launching The Things Network back-end 1.0, we are provisioning the cloud services to different regions around the world.

Server Addresses

Update your gateways’ configuration to the one of the server addresses listed below.

Choose the router depending on the frequency plan used in your region. Have a look at the LoRaWAN 1.0.1 specification (still under NDA, download 1.0). This may not be the closest router in terms of latency [1]. # EU 433 and EU 863-870 # US 902-928 # China 470-510 and 779-787 # Australia 915-928 MHz

Today, these DNS records refer to the staging environment, but we will update the records to the production environment when it comes available this summer. This will be announced timely in advance. Note: the staging environment currently only supports EU 863-870.

Note: nothing will change for existing applications. All data will arrive in the good old Croft/Jolie prototyping and demonstration back-end, regardless of frequencies. The new back-end forwards all packets to Croft (this also works for other regions than EU 863 - 870).

[1] The geographical location of a server and the supported frequency plans are two different things. We are waiting for the LoRa Alliance to publish specifications for more regions so that we can deploy routers for these regions, and datacenters close to that region. We will introduce a decentralized routing mechanism as part of the production environment so that you, the community, can host routers as well. Today, we are happily supported by Microsoft Azure with lightning fast connections between their datacenters.

Staging Environment

It is highly recommended to update your gateway to the server addresses shown above. If you have test gateways that you want to force to use the staging environment and keep using the staging environment, use one of these server addresses. The staging environment will contain newer, but possibly less stable, builds of The Things Network back-end.

Note: the staging environment is completely separated from the production environment, but both forward all packets to Croft. # EU 433 and EU 863-870 # US 902-928 # China 470-510 and 779-787 # Australia 915-928 MHz

Configuring Your Gateway

In the local_conf.json (or global_conf.json if you don’t use a local file), update the fields server_address. We are still using port 1700 for serv_port_up and serv_port_down.

"gateway_conf": {
        "server_address": "<insert server address here>",
        "serv_port_up": 1700,
        "serv_port_down": 1700,

Works here, for

tcpdump -ui wlan0 host

18:26:08.001044 IP raspberrypi.local.45469 > UDP, length 241
18:26:08.184125 IP > raspberrypi.local.45469: UDP, length 4
18:26:38.001642 IP raspberrypi.local.45469 > UDP, length 241
18:26:38.188597 IP > raspberrypi.local.45469: UDP, length 4

still getting updates on the API

1 Like

For those using a MultiTech gateway, a package with updated configuration for the 868 band will be released in a few days.


LoRaWAN 1.0.1 specification (draft 3) can be readed here:

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.

This topic is no longer a banner. It will no longer appear at the top of every page.

The installer package for MultiTech Conduit has an updated configuration for the 868 frequencies using the new back-end. The poly-packet-forwarder_2.1-r3_arm926ejste.ipk package can be installed with ‘opkg install poly-packet-forwarder_2.1-r3_arm926ejste.ipk’ (after transfering it to the conduit).

1 Like

HI @kersing - just picked up your new poly packet forwarder. I’m getting an error in the lora-pkt_fwd.log - ERROR: [up] getaddrinfo on address (PORT 1700) returned Name or service not known.

I think I’ve got things configured ok - local_conf is

“gateway_conf”: {
/* you must pick a unique 64b number for each gateway (represented by an
“gateway_ID”: “008000000000A052”,
/* Email of gateway operator, max 40 chars*/
“contact_email”: “”,
/* Public description of this device, max 64 chars /
“description”: “TTN-READING-UK-001”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“server_address”: “”,
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: true,
Enter VALID GPS coordinates below before enabling fake GPS */
“fake_gps”: true,
“ref_latitude” : 51.441026,
“ref_longitude” : -0.967420,
“ref_altitude”: 61

Any ideas where I might have gone wrong?
Thanks, Mark

Hi @markstanley
You need DNS for the new package to work (as noted on the installation page on WIKI). Create a file called ‘/etc/resolv.conf’ (without the quotes) with contents ‘nameserver’ (also no quotes). Be aware this file will be removed upon reboot.
I’m working on a better solution for this.

The easy way to create it now is to log in to the conduit and copy-and-paste the next command:
echo ‘nameserver’ > /etc/resolv.conf

Restart the packet forwarder after creating the file.

BTW. I would recommend removing server_address, serv_port_up/down and forward_crc_… lines from local_conf.json. These settings are correctly defined in global_conf.json.

1 Like

Thanks @kersing the error message has gone. I found a fix on the multitech site that suggests if you add a post-up line in /etc/network/interfaces you can fix the vanishing resolv.conf problem.

Add the post-up line as follows to /etc/network/interfaces:

# Wired interface
auto eth0
iface eth0 inet static
post-up echo ‘nameserver’ >/etc/resolv.conf

Thanks for your help, now onto the next hurdle in the upgrade… :smile:



It’s also possible to add the desired action(s) in a separate file, for example: /etc/network/if-pre-up.d/dns

#! /bin/sh echo "nameserver" >> /etc/resolv.conf echo "nameserver" >> /etc/resolv.conf



I’m new to the ttn and the lora environment. I don’t now if this is the right place to post my problem. If not i hope one of you could help me in the right direction.

I work for a hotel on the island of Aruba and would like to add a lora gateway to the ttn. This way I can use the applications of ttn to collect data form the resort and use it to make energy saving decisions.

I bought a few nodes and a gateway from china. The brand is USRIOT. I got the nodes to communicate with the gateway. What i miss is to connect the gateway to the ttn. The gateway has the option to connect with MQTT. In the following picture you can see the fields that needs to be filled to connect to ttn. fields

Can somebody help me where can i find the following information to be filled in the fields.

1.Server IP Address/Domain name
2. Server Port
3.MQTT Client ID
4.Pub subscription theme
5.Sub subscription theme
6.MQTT Server Account
7.MQTT Server Password

TTN mqtt is for client use, not to connect your gateway. You need to select something like UDP or Semtech in the dropdown.


Thank you for answering.
I have the UDP option available.
Please see picture:
Screen Shot 2020-04-16 at 2.58.50 PM

What do i need to fill in the:

  1. Server IP Address/Domain name
  2. Sever port
  3. Local port


Ports use 1700, server domain use the existing value but replace cn with your region. For instance eu for Europe. # EU 433 and EU 863-870 # US 902-928 # China 470-510 and 779-787 # Australia 915-928 MHz

What server should be used for RU864 region?

Use the, US is generally flaky, but the eu router works. Also uses a frequency similar band.