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.
TLDR: Connecting manually with LNS first seems to be mandatory
Long Version:
After changing the EUI to the generated value 000800FFFE4A7240 as @jreiss suggested I manged to get as far as @9600 with CUPS and got the error
2021-09-15 22:32:48.392 [any:VERB] Failed to retrieve TCURI from CUPS: (401) Unauthorized
(Note that the EUI in the Web GUI did not change to 000800FFFE4A7240, even after a factory reset)
URI has the correct value
https://eu1.cloud.thethings.network:443
My Gateway CUPS Key has all permissions and looks like this:
Authorization: NNSXS.E…63Q
I didn’t manage to get things working with CUPS this way. However, I got the Gateway working with the new EUI and manually configuring LNS (had to remove tx_freq_min and tx_freq_max form the global_conf.json file provided by TTN Interface). I used the LNS Gateway key formatted as “Authorization: NNSXS.5GTBW…Q” (note the missing Bearer. I don’t know whether that change is mandatory). The Gateway was happily interfacing with TTN
After this success I tried CUPS again and it actually just worked I don’t know what exactly changed when I was connected via LNS but there certainly had to be some communication…
If everything works as expected your logs should look like this (CUPS only mode)
admin@mtcap:/var/run/lora/1$ sudo ./station -N -l0
2021-09-15 23:13:02.128 [SYS:INFO] Logging : stderr (maxsize=10485760, rotate=3)
2021-09-15 23:13:02.129 [SYS:INFO] Station Ver : 2.0.5(mlinux/std) 2021-02-19 22:26:41
2021-09-15 23:13:02.131 [SYS:INFO] Package Ver : (null)
2021-09-15 23:13:02.132 [SYS:INFO] proto EUI : 0:8:4a:7240 (/sys/class/net/eth0/address)
2021-09-15 23:13:02.133 [SYS:INFO] prefix EUI : ::1 (builtin)
2021-09-15 23:13:02.133 [SYS:INFO] Station EUI : 8:ff:fe4a:7240
2021-09-15 23:13:02.134 [SYS:INFO] Station home: ./ (builtin)
2021-09-15 23:13:02.134 [SYS:INFO] Station temp: /var/tmp/ (builtin)
2021-09-15 23:13:02.134 [SYS:WARN] Station in NO-TC mode
2021-09-15 23:13:02.336 [CUP:INFO] Starting a CUPS session in 0 seconds.
2021-09-15 23:13:02.337 [CUP:INFO] Starting a CUPS session now.
2021-09-15 23:13:02.337 [CUP:INFO] Connecting to CUPS ... https://eu1.cloud.thethings.network:443 (try #1)
2021-09-15 23:13:02.342 [any:INFO] ./cups.trust:
cert. version : 3
serial number : 91:2B:08:4A:CF:0C:18:A7:53:F6:D6:2E:25:A7:5F:5A
issuer name : C=US, O=Internet Security Research Group, CN=ISRG Root X1
subject name : C=US, O=Let's Encrypt, CN=R3
issued on : 2020-09-04 00:00:00
expires on : 2025-09-15 16:00:00
signed using : RSA with SHA-256
RSA key size : 2048 bits
basic constraints : CA=true, max_pathlen=0
key usage : Digital Signature, Key Cert Sign, 2021-09-15 23:13:02.343 [AIO:INFO] cups has no cert configured - running server auth and client auth with token
2021-09-15 23:13:02.451 [CUP:VERB] Retrieving update-info from CUPS https://eu1.cloud.thethings.network:443...
2021-09-15 23:13:03.151 [AIO:XDEB] [3] http_read state=4
2021-09-15 23:13:03.220 [AIO:XDEB] [3] http_read state=4
2021-09-15 23:13:03.221 [CUP:INFO] TC URI updated: wss://eu1.cloud.thethings.network:8887
2021-09-15 23:13:03.222 [AIO:DEBU] [3] HTTP connection shutdown...
2021-09-15 23:13:03.223 [CUP:INFO] CUPS provided TC updates (uri)
2021-09-15 23:13:03.223 [CUP:INFO] Interaction with CUPS done - next regular check in 1d
To be honest this had crossed my mind also and I cannot be certain that I had domain parts swapped. I have another two gateways to migrate and will see how I get on with those, but may be a few weeks until I have opportunity to look at these.
Bypassing CUPS and performing LNS connection will create the tc.uri, tc.trust and tc.key files that CUPS is supposed to download.
When you configured for CUPS again did you still see a 401 response?
The connection info may not have been updated from the server. Does it still work after a save and restart?