@ElectronicallyE
hey you did a very nice summary of the setup in your post, you forgot to mention in there the LNS KEY creation which is part of the process.
also seems that TTN updated the documentation on this step and now you can add this LNS API key in the GW General Settings page
where before this was done only with the CLI tool
question: can this LNS key be created once for all the GWs in the Personal API keys or in Org keyst, or does it have to be created per gateway?
another comment: if you are using The Things Industries or the things stack, do use this command to grab the cert: openssl s_client -showcerts -servername au1.cloud.thethings.network -connect au1.cloud.thethings.network:443
It does that for data caught by a V2 GW coming through PacketBroker into V2 applicationsā¦so one would suspect your GW was/still is registered in V2 and not yet on V3? (If so DONāT delete from V2 just in case - just change key to stop it being picked up in V2 via console)
Thank you Jeff, The Gateway was deleted but the sensor was registered on V2ā¦but I think this is not related to the fact that the GW is in a disconnected state, No?
Can this LNS key be created once for all the GWs in the Personal API keys or in Org keyst, or does it have to be created per gateway?
Keys must be created for each gateway.
another comment: if you are using The Things Industries or the things stack, do use this command to grab the cert: openssl s_client -showcerts -servername au1.cloud.thethings.network -connect au1.cloud.thethings.network:443
For some reason, the ISRG Root X1 pem 7 certificate was working for a couple of days then the gateway went offline. I tried rebooting the unit and had still had no luck. After reseting the gateway and using the above command to get the certificate (itās the second one printed in the output), the gateway connected.
Iām deleting and reposting my procedure to reduce confusion.
Server Cert
In a terminal, enter the command openssl s_client -showcerts -servername au1.cloud.thethings.network -connect au1.cloud.thethings.network:443 which is mentioned in MultiTech Developer Resources Ā» Running Basic Station on Conduit . Copy the second certificate printed (starting with -----BEGIN CERTIFICATE-----):
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
CERTIFICATE
-----END CERTIFICATE-----
Gateway Cert
Leave blank
Gateway Key
Authorization: Bearer CUPS_API_KEY
Get the key by creating an API key in The Things Stack with the following permissions:
View gateway information
Retrieve secrets associated with a gateway
Edit basic gateway settings
Click āSubmitā (bottom of page) ā āSave and Applyā (left)
Click āCommandsā ā āRestart Deviceā (gateway must be completely rebooted for it to connect to the network)
I did not need to adjust the gateway EUI in The Things Stack (moving four zeros from the middle to the front of the EUI).
Iāve studied this thread numerous times, read the TTN LBS documentation and that supplied by Multitech, but still no further getting a Conduit connected via Basics Station and would appreciate any suggestions for things to try.
H/W + F/W: MTCDTIP-L4E1-266A Firmware 5.3.3
Connecting to EU1. If I run station with sudo I get:
admin@mtcdt:/var/run/lora/1$ sudo ./station
Password:
2021-09-10 15:35:15.820 [SYS:INFO] Logging : stderr (maxsize=100000, rotate=3)
2021-09-10 15:35:15.821 [SYS:INFO] Station Ver : 2.0.5(mlinux/std) 2021-02-19 22:27:11
2021-09-10 15:35:15.822 [SYS:INFO] Package Ver : (null)
2021-09-10 15:35:15.822 [SYS:INFO] proto EUI : 80:0:a000:8232 (station.conf)
2021-09-10 15:35:15.822 [SYS:INFO] prefix EUI : ::0 (station.conf)
2021-09-10 15:35:15.823 [SYS:INFO] Station EUI : 80:0:a000:8232
2021-09-10 15:35:15.823 [SYS:INFO] Station home: ./ (builtin)
2021-09-10 15:35:15.823 [SYS:INFO] Station temp: /var/tmp/ (builtin)
2021-09-10 15:35:16.025 [TCE:INFO] Starting TC engine
2021-09-10 15:35:16.027 [TCE:ERRO] No TC URI configured
2021-09-10 15:35:16.027 [CUP:INFO] Starting a CUPS session in 0 seconds.
2021-09-10 15:35:16.028 [TCE:INFO] Router rejected or retry limit reached. Invoking CUPS.
2021-09-10 15:35:16.028 [TCE:INFO] Terminating TC engine
2021-09-10 15:35:16.028 [CUP:INFO] Starting a CUPS session now.
2021-09-10 15:35:16.029 [CUP:INFO] Connecting to CUPS ... https://eu1.cloud.thethings.network:443 (try #1)
2021-09-10 15:35:16.034 [any:INFO] ./cups.trust:
cert. version : 3
serial number : 82:10:CF:B0:D2:40:E3:59:44:63:E0:BB:63:82:8B:00
issuer name : C=US, O=Internet Security Research Group, CN=ISRG Root X1
subject name : C=US, O=Internet Security Research Group, CN=ISRG Root X1
issued on : 2015-06-04 11:04:38
expires on : 2035-06-04 11:04:38
signed using : RSA with SHA-256
RSA key size : 4096 bits
basic constraints : CA=true
key usage : Key Cert Sign, CRL S2021-09-10 15:35:16.034 [AIO:INFO] cups has no cert configured - running server auth and client auth with token
2021-09-10 15:35:16.495 [CUP:INFO] Interaction with CUPS failed - retrying in 1m
2021-09-10 15:35:16.495 [TCE:INFO] Starting TC engine
2021-09-10 15:35:16.496 [TCE:ERRO] No TC URI configured
2021-09-10 15:35:16.497 [TCE:INFO] Router rejected or retry limit reached. Invoking CUPS.
2021-09-10 15:35:16.497 [TCE:INFO] Terminating TC engine
2021-09-10 15:35:16.497 [CUP:INFO] Starting a CUPS session in 60 seconds.
2021-09-10 15:36:16.498 [CUP:INFO] Starting a CUPS session now.
2021-09-10 15:36:16.498 [CUP:ERRO] No CUPS-bak URI configured
2021-09-10 15:36:16.498 [TCE:INFO] Starting TC engine
2021-09-10 15:36:16.499 [TCE:ERRO] No TC URI configured
2021-09-10 15:36:16.499 [TCE:INFO] Router rejected or retry limit reached. Invoking CUPS.
2021-09-10 15:36:16.500 [TCE:INFO] Terminating TC engine
2021-09-10 15:36:16.500 [CUP:INFO] Starting a CUPS session in 60 seconds.
I could only recreate your error by using a key with the wrong permissions.
Can you run with the -l0 logging option? It will probably show a 401 Unauthorized HTTP response which is expected when using a key with wrong permissions.
CUPS requires an API key for your gateway with the following rights:
View gateway information
Edit basic gateway settings
Retrieve secrets associated with a gateway
The CUPS key will go into the Conduit AEP UI Gateway Key field with HTTP header info prefix āAuthorization: Bearerā.
Authorization: Bearer NNSXS.AAA.BBB
LNS requires an API Key with the following rights:
Link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink
The LNS key will go into the TTN UI Gateway Settings LNS Authentication Key field
For sanity check you could enable all permissions for both keys then it would not matter if you have them flipped. This is NOT recommended for actual deployment.
@jreiss The mPower UI shows the Gateway EUI: 00-80-00-00-00-01-42-76 which I used to register the Gateway with on TTN (working in v2 and packet Forwarder Mode for v3). I didnāt use 8:ff:fe4a:7240 yet. Iāll try to register another v3 gateway with that ID and let you know how that goes.Thanks for the hint.
Since basic station generated an EUI value I assume the default placeholder was removed from the station.conf.
There should be a routerid field in the JSON input into the UI. I the placeholder is used, any value between angled brackets, such as ā<WILL-BEā¦>ā then the init script will replace this with the Gateway EUI shown in the UI.
In addition to what @jreiss said, if you still get a 404 error, the other possibility is that the gateway does not have a frequency plan configured on The Things Stack.
