To narrow it down the objectives would be:
- Enable multi-container for Balena flavored Basicstation
- Clean up unreliable certs
- Clean up time sync errors
- Enable basicstation > chirpstack (specifically their gateway bridge running in its own container)
To narrow it down the objectives would be:
Btw, I AM getting packets from my lora nodes successfully appearing in balena’s logs, which is very encouraging… SO close to complete
29.09.20 10:58:22 (-0400) basicstation 2020-09-29 14:58:22.091 [S2E:VERB] RX 903.9MHz DR3 SF7/BW125 snr=10.0 rssi=-75 xtime=0x9C00003DF41AEB - updf mhdr=40 DevAddr=xxxx FCtrl=C0 FCnt=210 FOpts= 01F9 mic=524311765 (14 bytes)
@barryjump what LoRa concentrator do you use?
havent’ tried chirpstack myself yet. I see their repo and this is the one we used to build our repo. I think it should work with their own TC_URI. Do you have it?
on the multi-container, what other containers would you need?
@mpous I’m using the RAK2245 on their developer gateway model (basically RPi4 & GPS included). I’ve got chirpstack about 80% configured on GCP so I think it will work like a charm, just some of their on device concentrator settings are a little confusing.
The ideal multi-container setup for me (and others maybe?) would be:
I’d consider node-red optional mostly for testing or doing edge work like filtering or local action downlinks.
All the pieces are out there and balena is INCREDIBLE so I feel like we’re so close to a click-to-deploy version of a production ready gateway, especially if you swap the RPi for a Kunbus or Fin.
@mpous also I totally missed their tc_uri setting. Good eye! I’ll give that a shot and share my progress here.
Hi @barryjump, I like the idea of the Chirpstack Gateway Bridge I will start testing it and see what comes out. Probably you’re ahead of me in that part, so any advice would be welcome.
Probably not much further, I’m juggling two projects so not moving as quickly as I’d like. But I do think it should be relatively simple to build the right compose file to run both on device. I dont know as much as i’d like about opening docker ports so they can talk to each other securely however. Chirpstacks docs would need some customization for an install like this.
what do you think?
I like that idea. Should we set up a shared GitHub and Balena apps?
@barryjump Feel free to clone the repo on your account and then you can PR on our repo!
Hi @mpous I like the idea too, I will update my fork with the updated repo and start hacking.
@mpous I took a short break from trying to get Chripstack talking to basicstation.
I’ve been playing with the things stack instead today. Was looking at your guide again for TTN & TTI.
Technically neither is exactly the things stack, but I’ve got a secured domain running TTS with a secure websocket listener. But I’m getting the following error:
From Balena logs:
14.10.20 15:37:46 (-0400) basicstation cert. version : 3 14.10.20 15:37:46 (-0400) basicstation serial number : 44:AF:[[redacted]]:86:2E:F8:40:6B 14.10.20 15:37:46 (-0400) basicstation issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 14.10.20 15:37:46 (-0400) basicstation subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 14.10.20 15:37:46 (-0400) basicstation issued on : 2000-09-30 21:12:19 14.10.20 15:37:46 (-0400) basicstation expires on : 2021-09-30 14:01:15 14.10.20 15:37:46 (-0400) basicstation signed using : RSA with SHA1 14.10.20 15:37:46 (-0400) basicstation RSA key size : 2048 bits 14.10.20 15:37:46 (-0400) basicstation basic constraints : CA=true 14.10.20 15:37:46 (-0400) basicstation key usage : Key Cert Sign, CRL Sign 14.10.20 15:37:46 (-0400) basicstation 2020-10-14 19:37:46.219 [AIO:INFO] tc has no key+cert configured - running server auth only 14.10.20 15:37:46 (-0400) basicstation 2020-10-14 19:37:46.247 [TCE:VERB] Connecting to MUXS... 14.10.20 15:37:46 (-0400) basicstation 2020-10-14 19:37:46.411 [AIO:ERRO]  WS upgrade failed with HTTP status code: 401 14.10.20 15:37:46 (-0400) basicstation 2020-10-14 19:37:46.411 [AIO:DEBU]  WS connection shutdown... 14.10.20 15:37:46 (-0400) basicstation 2020-10-14 19:37:46.411 [TCE:VERB] Connection to MUXS closed in state 3 14.10.20 15:37:46 (-0400) basicstation 2020-10-14 19:37:46.411 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
From TTS Logs:
NFO Request handled duration=13.403456ms error=error:pkg/gatewayserver/io/ws:no_auth_provided (no auth provided 0242acfffeXXXXXX
) method=GET namespace=gatewayserver/io/ws remote_addr=69.XXX.XXX.123:55906 request_id=01EMM8BXJ2REX6FRXH59ZYQFCQ status=401 uid=0242acfffeXXXXX url=/traffic/eui-0242ACFFFEXXXXX
You mention the TC_TRUST variable for connecting to TTI (the things industries). Can you elaborate? Did you paste the entire certificate.crt contents from the server?
Thanks for your message @barryjump.
For connecting to TTI you will need to point to another websocket that’s usually in another server and will need (potentially) another type of certificates.
On the tests that i did, it worked with the certificate being used on the repo, but could you please confirm that the TC_URI you are using accepts the same type of TC_CERT?
@mpous good point, I had assumed it did, but I may be wrong. Especially if since TTS (the things stack) is an open version of TTI (the things industries), it gives developers the option for where to get their certificates (I used zerossl.com for example, and in prod would actually probably use AWS Certificate Manager). So I think I have to dig a bit deeper on how to translate the private.key, ca_cundle.crt, and certificate.crt issued by them to something that can be loaded onto the gateway.
Fwiw, this is where I’m looking for some guidance: