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,

Announcing staging environment of TTN Back-end 1.0
Frequency plan: Brazil
Single Channel Gateway, how to check Communication to TTN
Single Channel Gateway shows "not connected"

(Chuck) #3

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

(Jac Kersing) #4

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

(Nestor Ayuso) #5

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.

(Jac Kersing) #8

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).


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

(Jac Kersing) #10

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.


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:


(Rob Brinkman) #12

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