Setting up a Private Routing Environment

Now I can’t perform OTAA activation:

D:\Projects\lora\TheThingsNet>“D:\Projects\lora\TheThingsNet\src\\TheThingsNetwork\ttn\ttn.exe” broker --config “.\broker\ttn.yml”
Using config file: .\broker\ttn.yml
INFO Initializing The Things Network Auth Servers=map[ttn-account-v2:] ComponentID=vitaly-broker Description= Discovery Server Address=localhost:1900 Monitors=map[]
INFO Initializing Broker Announce=localhost:1902 DeduplicationDelay=200 NetworkServer=localhost:1903 Server=
INFO Starting
DEBUG Connected to gRPC server Address=localhost:1900
INFO ttn: Got public keys for token validation
INFO ttn: Announced to TTN discovery
DEBUG Connected to gRPC server Address=localhost:1903
INFO Prefix found in Discovery DPrefix=26000000/20 NSPrefix=26000000/20
DEBUG Start stream CallerID=vitaly-handler CallerIP= Method=/broker.Broker/Publish
DEBUG Start stream CallerID=vitaly-handler CallerIP= Method=/broker.Broker/Subscribe
DEBUG grpc: Server.Serve failed to complete security handshake from “”: EOF
DEBUG Start stream CallerID=vitaly-router CallerIP= Method=/broker.Broker/Associate
DEBUG Connected to gRPC server Address=localhost:1904
WARN Could not dial handler for Activation AppEUI=70B3D57EF0000023 AppID=counter_app DevEUI=0088444D571864EB DevID=local_dev GatewayID=eui-a75c3affffe606e0 NumHandlers=2 error=x509: certificate signed by unknown authority (possibly bec
ause of “x509: ECDSA verification failure” while trying to verify candidate authority certificate “serial:279521433737929252104238787983170638246”)
DEBUG Connected to gRPC server Address=localhost:1904
DEBUG Forward Activation AppEUI=70B3D57EF0000023 AppID=counter_app DevEUI=0088444D571864EB DevID=local_dev GatewayID=eui-a75c3affffe606e0 HandlerID=vitaly-handler NumHandlers=2

Thanks @vitalypru, the thing it’s that I am using another “user” to sign the certificate, so I used

$ ttn discovery gen-cert conf-discovery --config ./discovery/ttn.yml

Did you run your private network in a docker container as well?

As I understand, during certificate creation you point name of server, which can be verified using this certificate,
Not user, name, but server name:

DEBUG Connected to gRPC server Address=localhost:1900
FATAL Could not start client for gRPC proxy error=x509: certificate is valid for conf-discovery, not localhost

I think you need include the same server name in the certificate, as you set as server-address in discovery configuration.

I’m not using the docker container. I’m trying to start ttn backbone under windows, building it from github source code.

You are right, my server-address discovery looks like

id: discovery
debug: true
key-dir: "./env/discovery/"
ttn-account-v2: ""
#ttn-account-preview: ""
local: "file:///root/env/discovery/"

tls : true
redis-address: redis:6379
**server-address: discovery**
- ttn-account-v2
- local

Here I change the name just to discovery, for sake of clarification, I regenerate the certificates with discovery as name of my server

$ ttn discovery gen-cert discovery --config ./discovery/ttn.yml

After doing so, starting up the server, I still get the error x509. In my case I am using docker, maybe it is related to the fact that the docker has to know the certificate that I am using as well :grimacing: ( which I have tried as well wihtouth success)

I think you can try opposite solution:
remove “server-address” line from conf file. Assuming localhost for server.
And generate cet using:
$ ttn discovery gen-cert localhost --config ./discovery/ttn.yml

Also note, that there are typo in line
Need to be corrected to

Also note, that during cert generation you use config in ./discovery folder while your key folder is .env/discovery.

1 Like

I just published a new article explaining how to deploy your private routing environment with Docker-Compose. For all Docker and Docker-Compose questions, please use the forum topic for that article.


I am running a private TTN backend, I have a gateway that was registered on I can’t get the gateway status, when I use ttnctl (ttnctl gateways status eui-0000024b080e100b or 0000024b080e100b), output error “can not find GatewayID”. Cuold I get those access auth-tokens with the command ttnctl components token for router, broker ? and set server-address-announce to a public IP, how to registe gateways to both my private and public TTN back_end?

Hiya, thanks for the guide - it’s really helpful!

Ok so I have got everything set up and it is almost all working - but I’m not able to see packets being sent from my device to the app.

I am running ttnctl subscribe - and I can see a successful join:
> INFO Connecting to MQTT… MQTT Broker=tcp://localhost:1883 Username=
> INFO Connected to MQTT
> INFO Subscribed to activations
> INFO Subscribed to uplink
> INFO Activation
> AppID: priv-test
> DevID: priv_pi
> AppEUI: 70B3D57EF00043A4
> DevEUI: 00333E8BE219B599
> DevAddr: 26000769

…so I thought I was ready to party, but unfortunately I don’t see any subsequent packets coming through - ttnctl subscribe stays silent.

Any ideas?


I’m trying to setup a private routing server on my Debian 8 VM.

I’m following your post. But i strand at the same point as Vitalypru mentioned on dec 1st. 2016.
So i took de /develop/ download. And i still run in to it.

Using config file: ./discovery/ttn.yml
INFO Initializing The Things Network Auth Servers=map[ttn-account-v2: local:file://discovery/] ComponentID=larosnet-discovery Description= Discovery Server Monitors=map
INFO Initializing Discovery Database=localhost:6379/0 HTTP Proxy= Server=
INFO Starting
INFO ttn: Got public keys for token validation
FATAL Stopping because of panic panic=runtime error: invalid memory address or nil pointer dereference stack=goroutine 1 [running]:
/go/src/ +0x64
panic(0x8828580, 0x8e35588)
/usr/local/go/src/runtime/panic.go:489 +0x22a
sync/atomic.StoreUint64(0x19460c4c, 0x0, 0x0)
/usr/local/go/src/sync/atomic/asm_386.s:190 +0xb*Component).SetStatus(0x19460c00, 0x0)
/go/src/ +0x39*discovery).Init(0x19395b80, 0x19460c00, 0x2, 0x2)
/go/src/ +0x63, 0x19458500, 0x0, 0x2)
/go/src/ +0x327*Command).execute(0x8e3c2a0, 0x19458420, 0x2, 0x2, 0x8e3c2a0, 0x19458420)
/go/src/ +0x1af*Command).ExecuteC(0x8e3c840, 0x19659f94, 0x19659f90, 0x194ea320)
/go/src/ +0x28b*Command).Execute(0x8e3c840, 0x895a59c, 0x85626f3)
/go/src/ +0x21
/go/src/ +0x41
/go/src/ +0x116

I used your config file.

What am i missing.

73 de PD5WL

Are you by any chance on a 32 bit machine? In that case, this is fixed in the develop branch of our code. Will be incorporated in the next release

yep, 32bit Debian 8.

I did download the “” version.

I just switch to an 64bit machine. Seams like i had a server laying around after all…

Some times i just can’t keer track.

onward with the installation. ThanX so far.

Still trying to figure out why my private backend isn’t quite working. ttnctl subscribe shows activations, but doesn’t show messages from my device.
I can see the message appearing on lora-gateway-bridge:

INFO[1035] gateway: rxpk packet received addr= data=“QDQsASaAAAABa4mwRxqg26nIsaliN2ALza2hL2AabxKI6bjBIw==” mac=008000000000a052

but all the other services don’t seem to show anything, whereas they all display stuff during the activation.

I noticed the network server showed it was using the public ttn as the Discovery Server, so I have added discovery address: "localhost:1900 to its ttn.yml - so it now points to the local discovery server but that hasn’t made any difference:
> INFO Initializing The Things Network Auth Servers=map[ttn-account-v2:] ComponentID=mynetwork-networkserver Description= Discovery Server Address=localhost:1900 Monitors=map
> INFO Initializing Network Server Database=localhost:6379/0 NetID=19 Server=
> INFO Starting
> INFO Using DevAddr prefix 26000000/20 (otaa,abp,world,local,private,testing)
> INFO ttn: Got public keys for token validation

Can anyone help me solve this?
Many thanks, Mark

The deafening silence from the forum forced me to start again.

This time it worked, but I can’t say with certainty what the cause of the problem was. I think I probably screwed up the various security keys somewhere - it is fiddly and looks easy to mess up. There is now uplink activity in the handler as well as the bridge logs, and the uplink message appears in ttnctl subscribe.

1 Like

Hellol. I’ve set up my private TTN backned instance following this article []. Everything seems to work right. All components seems to work. Using ttnclt i can register a device, create an app and simulate an upload message that is published in its corresponding MQTT path. BUT when I try with a real deployment (a Kerlink GW and a SoluM LoRa mote, Gateway seems to work, JOIN requests from the mote are accepted but when I try to send data from the mote to the MQTT server, nothing appears. The router debug prints: NO BROKERS TO FORWARD MESSAGE TO

Here is the the Debug line printed by the router:
e[90m DEBUGe[0m No brokers to forward message to e[90mAppPayloadSizee[0m=16 e[90mCodingRatee[0m=4/5 e[90mCountere[0m=1 e[90mDataRatee[0m=SF12BW125 e[90mDevAddre[0m=26000F60 e[90mDownlinkOptionse[0m=2 e[90mFCnte[0m=1 e[90mFrequencye[0m=867300000 e[90mGatewayIDe[0m=eui-0000024b080306b5 e[90mModulatione[0m=LORA e[90mPayloadSizee[0m=29 e[90mPorte[0m=2 e[90mRSSIe[0m=-25 e[90mSNRe[0m=9

Any suggestion??
Thanks in advance!!

I think you forgot the step ttn broker register-prefix 26000000/20 --config ./broker/ttn.yml.

1 Like

I have also installed my private TTN backend following
I will rely on The Things Network community account server ( so I can use my TTN account to manage the devices on my local network.
Locally everything seems to work right, but on the console of The Things Network I can only view the application and not the devices locally registered.

TTN Console does not connect to your private servers, so you’ll need the ttnctl command line tool:

(Same goes for the application you apparently see in TTN Console; I don’t think that’s related to your own private environment?)

Perfect!!! now it works perfectly.
Thanks a lot!

Hello guys.

I have just set up a private routing environment following Hylke’s guide from (the non-docker version)
I have started all components and tried to register a gateway to my local environment. Although the ttnctl config file seems to point to localhost, the gateway is registered to the TTN web console environment. I have also tried to bypass the config file by configuring the various components using the command arguments. If I have understood correctly, a gateway could be registered to the public TTN or the private exclusively.

Am I missing something?

When I start the local discovery server I get the following:

./ttn-linux-amd64 discovery --config ./discovery/ttn.yml
Using config file: ./discovery/ttn.yml
INFO Initializing The Things Network Auth Servers=map[ttn-account-v2: local:file://discovery/] ComponentID=mynetwork-discovery Description= Discovery Server Monitors=map
INFO Initializing Discovery Database=localhost:6379/0 HTTP Proxy= Server=
INFO Starting
INFO ttn: Got public keys for token validation

I am suspecting there is an issue with the discovery server address setting there.