Hmm that’s interesting. Can you PM me your gateway ID and I’ll take a look in the server logs.
After switching to using LNS and connecting OK this way, I then switched back to CUPS and have successfully connected with this. Looking at this page:
https://www.thethingsindustries.com/docs/getting-started/server-addresses/
The examples for CUPS have the URI elements eu1 and cloud transposed and I think it may have been this that previously caught me out.
1 Like
Ah yeah some of those example were wrong. I fixed them. Thanks!
1 Like
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 to000800FFFE4A7240, 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
1 Like
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?
When I configured for CUPS after successfully connecting with LNS, it worked fine and has continued to across reboots.
1 Like
@seedteam6uav The logs (and management in general) can be accessed by ssh into the gateway from a computer on the same network.You can do so by ssh admin@192.168.178.21 (you might have to set up ssh in the web config of the gateway first). Then use sudo /etc/init.d/lora-network-server stop to stop the currently active network server. Afterwards, use sudo ./station -N -l0 from within the /var/run/lora/1 directory to run the network server again in an attached session to see logs. The -l0 flag specifies Log level.
Also have a look into the documentation here MultiTech Developer Resources » Running Basic Station on Conduit
2 Likes