Setting up a Private Routing Environment

TTN Network and Services v2 Backend
41

@Oliv
The backend runs just fine on a Raspberry Pi B+ also running the gateway software. I haven’t tried a hundred nodes however…

42

@Gig Ok, I will try on a rPi at first then on another processor.

43

Hi,

I am stucked with a weird issue, my account server seems to work fine, I can user login and add/select applications but when I try to register I have the issue: “unable to parse token: Invalid Key: Key must be PEM encoded PKCS1 or PKCS8 private key”.

I checked key generated by ttn handler gen-keypair and they are EC, not PEM encoded PKCSX :confused: … What did I miss ? Thank you

ttnctl applications register test
  INFO Discovering Handler...                   Handler=mynetwork-handler
  INFO Connecting with Handler...               Handler=localhost:1904
 FATAL Could not register application           error=Could not register application on Handler: permission denied: unable to parse token: Invalid Key: Key must be PEM encoded PKCS1 or PKCS8 private key source=Wrap: /go/src/github.com/TheThingsNetwork/ttn/utils/errors/errors.go:217
44

After following the article and reading this thread i was able to get a private backend up and running. At least not errors when starting the components.
Now using ttnctl I wanted to add a new gateway to the private stack. Beeing more precise i wanted and active gateway to send to the things network as well as to the private stack. But the register through console claimed that the eui was allready taken. It actually is within the ttn stack but not within the p stack. Whats also weird to me is that i see another gateway (righfully, cause i only have rights for this one) allready showing up when i query the private stack. I assumed I would see none of the gateways registered with the ttn stack.

Is that normal behaviour?
Might I be connecting to the ttn stack through ttnctl?

heres the output of ttcntl config.

root@ttn-local64:~/ttn# ./ttnctl config
INFO Using config:

     config file: /root/.ttnctl.yml
        data dir: /root/.ttnctl

      gateway-id: dev
          app-id:
     auth-server: https://account.thethingsnetwork.org
  allow-insecure: false
    mqtt-address: localhost:1883
      handler-id: mynetwork-handler
       router-id: mynetwork-router
         app-eui:

discovery-address: localhost:1900
mqtt-password:
data: /root/.ttnctl
mqtt-username:
config: /root/.ttnctl.yml
gateway-token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ0dG4tYWNjb3VudC12MiIsInN1YiI6ImRldiIsInR5cGUiOiJnYXRld2F5IiwiaWF0IjoxNDgyNDIxMTEyfQ.obhobeREK9bOpi-YO5lZ8rpW4CkXZUSrRBRIjbFThhvAsj_IjkFmCovIVLsGlaDVEKciZmXmWnY-6ZEgUEu6H6_GG4AD6HNHXnT0o0XSPgf5_Bc6dpzuI5FCEpcELihpBMaW3vPUt29NecLo4LvZGAuOllUYKHsZi34GYnR6PFlOgi40drN_iU_8aMCxFxm6ki83QlcyHEmDAh5GAGIym0qnUDh5_L1VE_upmoR72j8_l5lSuUA2_w8CH5_Z9CrXlTKQ2XQXsQXprkhbmOKKC8rfbTjRsB_nxObu0qcTWLH9tMd4KGFkJ20mdMw38fg2Vt7eLrkU1R1kl6a65eo6LZi0JvRSsboVZFWLwI02Azkwsm903K5n1r25Wq2oiwPJpNq5vsYLdYlb-WdAPsEDnfQGLPaqxd5we8tDcHsF4C1JHTwLsKy2Sqj8WNVmLgXiFER0DNfISDgS5SYdOxd9dUf5lTlIYdJU6aG1yYLSEhq80QO

45

When setting up a private backend this way you are still using TTN’s authentication server (auth-server: https://account.thethingsnetwork.org). EUID, certificates, etc. are delivered by this component, so the gateways you are seeing are the ones you’d also see on console.thethingsnetwork.org.

If you want a fully autonomous backend, you’ll need your own authentication server. You can either make your own (the API specification is somewhere on the wiki) or strike a deal with TTI.

46

Thanks Gig for the clarification.
It dawned to me after going through the config and rereading the backend article. I’ll take a look at the API. Maybe I can come up with something.

47

Hi @htdvisser,

I’m not using TLS in my case, but it shows me this error anyway:

brk.1 | FATAL Could not initialize broker error=x509: certificate has expired or is not yet valid

Do I have to set up or change anything?

Thanks

48

Sounds like the networkserver certificate is expired. Are you on the latest develop?

49

Well, I think so. I’ve been on vacation the last weeks, and I month ago approximately everything worked correctly. What do you suggest me to do?

50

A simple git pull should solve this

51

Once I do the git pull it shows “Already up-to-date”.

  • Next, if I check the configuration, I can see that the port used is 1883, so it means I am not using TLS, although I have certificates in all components. Am I right?
  • Apart from that, I can’t find the mqtt-ca.pem file, so could you tell me where it is?
  • Finally, if I have to download a new certificate, where should I locate it? (In all components or just the network server…)

Thank you so much!
(Sorry for my lack of knowledge, I’m just a student, and it is my first time handling this)

52

The error you’re seeing does not have to do with MQTT but with the connection between the Broker and the Networkserver components. Without information about how you set up your backend, I can’t say much about how to solve this.

53

Well, I’ll try to set up everything again, because I don’t know where the error could come from. I just followed the steps in this link: https://github.com/TheThingsNetwork/ttn

Could you tell me if I should follow this link again? (because I’ve found other links like this: https://www.thethingsnetwork.org/article/setting-up-a-private-routing-environment , and maybe it is old)

55

Hi I was trying to setup lora network server locally using setting-up-a-private-routing-environment guide.
Can you please elaborate the ttn binary installation step?
I am getting “bash: ttn: command not found” error after I tried installing ttn-linux-arm on PI-3.

Thanks in advance

56

Solved after installing from https://github.com/TheThingsNetwork/ttn

57

Hi @htdvisser,
How to see uplink data in ttnctl?.
ttnctl subscribe API just displaying the activation info for me, but no data info is shown.
ttnctl subscribe API log :
INFO Activation
AppID: lopygw
DevID: node1
AppEUI: 70B3D57ED0007DCE
DevEUI: 0099BB0DE752DC64
DevAddr: 260003C2

In my lora bridge , I can see rxpk data recieved. But somehow not reaching till application.
I have a lopy module acting as a nanogateway, pointing to my TTN private lora server.
Another lopy configured to act as node, which will transmit bytes data.

Below are my configurations:
1. .ttnctl.yml
discovery-address: localhost:1900
router-id: dev
handler-id: dev
mqtt-address: localhost:1883

2. ttnctl config
INFO Using config:

     config file: /home/sercer/.ttnctl.yml
        data dir: /home/server/.ttnctl

         app-eui: 
     auth-server: https://account.thethingsnetwork.org
      gateway-id: dev
          config: /home/server/.ttnctl.yml
   mqtt-username: 
      handler-id: dev
    mqtt-address: localhost:1883
   mqtt-password: 
       router-id: dev
  allow-insecure: false
            data: /home/server/.ttnctl
   gateway-token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ0dG4tYWNjb3VudC12MiIsInN1YiI6ImRldiIsInR5cGUiOiJnYXRld2F5IiwiaWF0IjoxNDgyNDIxMTEyfQ.obhobeREK9bOpi-YO5lZ8rpW4CkXZUSrRBRIjbFThhvAsj_IjkFmCovIVLsGlaDVEKciZmXmWnY-6ZEgUEu6H6_GG4AD6HNHXnT0o0XSPgf5_Bc6dpzuI5FCEpcELihpBMaW3vPUt29NecLo4LvZGAuOllUYKHsZi34GYnR6PFlOgi40drN_iU_8aMCxFxm6ki83QlcyHEmDAh5GAGIym0qnUDh5_L1VE_upmoR72j8_l5lSuUA2_w8CH5_Z9CrXlTKQ2XQXsQXprkhbmOKKC8rfbTjRsB_nxObu0qcTWLH9tMd4KGFkJ20mdMw38fg2Vt7eLrkU1R1kl6a65eo6LZi0JvRSsboVZFWLwI02Azkwsm903K5n1r25Wq2oiwPJpNq5vsYLdYlb-WdAPsEDnfQGLPaqxd5we8tDcHsF4C1JHTwLsKy2Sqj8WNVmLgXiFER0DNfISDgS5SYdOxd9dUf5lTlIYdJU6aG1yYLSEhq80QOcdhCqNMVu1uRIucn_BhHbKo_LCMmD7TGppaXcQ2tCL3qHQaW8GCoun_UPo4C67LIMYUMfwd_h6CaykzlZvDlLa64ZiQ3XPmMcT_gVT7MJS2jGPbtJmcLHAVa5NZLv2d6WZfutPAocl3bYrY-sQmaSwJrzakIb2D-DNsg0qBJAZcm2o021By8U4bKAAFR
          app-id:

discovery-address: localhost:1900

  1. Lora server bridge log :
    FO[3024] gateway: rxpk packet received addr=10.42.0.77:49154 data=“AM59ANB+1bNwZNxS5w27mQB8ZzkvCL0=” mac=11223344aabbccdd
    INFO[3024] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PushACK
    INFO[3029] backend/thethingsnetwork: message received gateway=11223344aabbccdd
    INFO[3029] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PullResp
    INFO[3029] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PullACK
    ERRO[3029] gateway: could not handle packet: gateway: unknown packet type: PullACK addr=10.42.0.77:49154 data_base64=“AgAABBEiM0Squ8zdeyJ0eHBrX2FjayI6IHsiZXJyb3IiOiAiTk9ORSJ9fQ==”
    INFO[3029] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PullData
    INFO[3029] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PullACK
    INFO[3030] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PushData
    INFO[3030] gateway: rxpk packet received addr=10.42.0.77:49154 data=“QKcLACYAAQACIGn/gxCkxA==” mac=11223344aabbccdd
    INFO[3030] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PushACK
    INFO[3034] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PushData
    INFO[3034] gateway: stat packet received addr=10.42.0.77:49154 mac=11223344aabbccdd
    INFO[3034] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PushACK
    INFO[3035] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PushData
    INFO[3035] gateway: rxpk packet received addr=10.42.0.77:49154 data=“QKcLACYAAgACoUn+s7btUug0” mac=11223344aabbccdd
    INFO[3035] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PushACK
    INFO[3054] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PullData
    INFO[3054] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PullACK
    INFO[3055] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PushData
    INFO[3055] gateway: rxpk packet received addr=10.42.0.77:49154 data=QKcLACYAAwACcjCRKHz31sZQ mac=11223344aabbccdd
    INFO[3055] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PushACK
    INFO[3075] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PushData
    INFO[3075] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PushACK
    INFO[3075] gateway: rxpk packet received addr=10.42.0.77:49154 data=QKcLACYABAACNzEuqBR4c2cm mac=11223344aabbccdd
    INFO[3079] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PullData
    INFO[3079] gateway: sending udp packet to gateway addr=10.42.0.77:49154 protocol_version=2 type=PullACK
    INFO[3094] gateway: received udp packet from gateway addr=10.42.0.77:49154 protocol_version=2 type=PushData

  2. LoPy node and nano gateway codes taken from:
    https://docs.pycom.io/chapter/tutorials/lopy/lorawan-nano-gateway.html

58

Hi all
It failed when I use broker register, please help!
sudo ./ttn-linux-amd64 broker register-prefix 26000000/20 --config ./broker/ttn.yml
Using config file: ./broker/ttn.yml
INFO Initializing The Things Network Auth Servers=map[ttn-account-v2:https://account.thethingsnetwork.org] ComponentID=mynetwork-broker Description= Discovery Server Address=localhost:1900 Monitors=map[]
ERROR Could not register prefix Prefix=26000000/20 error=permission denied: Discovery:Token type router does not correspond with announcement service type broker

61

Hello @tony_xing and @htdvisser, I am getting same error when I do in Ubuntu 16.04 VM. Did you find the answer?
Thanks for reply

62

This sounds like you have the wrong auth-token in ./broker/ttn.yml. The one you currently have in there seems to be the one that authenticates the router component, not the broker. I recommend you to generate new tokens with the steps described in the article.

63

@htdvisser, yes, It worked perfectly.