I’ve had some progress! However, not solved yet…
(This is on mPower/mLinux 5.3.0 as indirectly mentioned previously)
The main issue seems to be twofold:
For some weird reason, the TTN server (or MultiTech for all I know) decides to change the device EUI into something which does not match the actual EUI. For the purpose of the example, I’ll use the following true device EUI: 00 88 00 00 00 00 AB 99. After communicating with the TTN server, they request info from the EUI 00 00 00 88 00 00 AB 99 instead, i.e moving four zeros from the middle to front. I really don’t understand why. I even tried to manually force set the EUI in the station config and remove the eui-prefix line without any change. But okay, the solution for the time being is to change the EUI in the TTN V3 gateway settings so that it matches the one that results from the server side.
When the above is done, both CUPS and LNS configurations seem to be able to talk to the servers in my case, with their respective server certs and API keys entered correctly. The keys can without any difference be stated without the “Bearer”, but an "Authorization: " in front of the key is strictly necessary! However, the issue is now at the LNS server side where something is refused after first trying to initialise and forward the info from the station. More details follow.
I’ll (try to) attach a printout from the terminal after debugging the basic station manually over ssh. It shows that the CUPS seems to be working as it should, as it is able to collect the LNS stuff (tc.xxx) correctly. The problem seems to start at line 63 where the first error occurs:
2021-02-18 12:45:03.511 [AIO:ERRO] Recv failed: SSL - The peer notified us that the connection is going to be closed
I wonder if it has to do with the EUI issue? Then it tries again and from line 75 onwards new warnings and errors occur. This sequence repeats thereafter.
Anyone who is able to figure out what is causing this problem?
Why is the EUI ending up wrong?
What is the problem with the LNS server connection? CUPS seems to work as intended!
@tom-iotexperts I’m not so sure. The basic station can be initiated without any trouble from the AEP web UI here. The problem is that you don’t know what happens, or what goes wrong. So for debugging and figuring out how to correctly initiate it, using the terminal mLinux is superior as you say.
It would, however, be very nice if people from TTN who knows how to initiate this correctly could contribute here. After all they have managed to write a guide which obviously is lacking specific details as none of us here are able to reproduce it.
Here’s a recap so far, for anyone who might not know exactly how to do these things in terminal:
I spent yesterday testing various problems by trial and error. It looks like the certificate one uses is very critical. I ended up using the server’s own certificate, as explained by the multitech page you linked. Also when initiating the basic station from the web UI, all files are deleted/overwritten so that it starts clean everytime. But after I figured out the things mentioned yesterday, I can initiate it to the current partly functioning state (in terms of server connection at all!) from web UI. Now it remains to figure out why it cannot maintain the connection/is rejected by the LNS server…
I used the openssl command to find the certificate which would allow connection: openssl s_client -showcerts -servername eu1.cloud.thethings.network -connect eu1.cloud.thethings.network:443
This is the CUPS server for Europe (change the server to the one you’re trying to reach), and I copy/pasted the second certificate into the web UI “Server Cert” box. I found that using any of the certificates suggested by TTN did not work, which may be why you’re having trouble connecting as well? And also you should check if the EUI issue is present too!
For debugging, ssh into the mLinux and sudo -s
for root access. You need this in order to create files at the lora root directory, and it’s convenient not having to sudo with password all the time. Then stop the basic station manually /etc/init.d/lora-network-server stop
and wait for confirmation. Run it manually to get the errors out (first go to the lora service directory) cd /run/lora/1 ./station
Stop when you have what you need by Ctrl-C. Redo after making changes to the config files. You can list all present files with details by ls -l
cups.* files are used if the service is initiated in CUPS mode, tc.* files if LNS mode has been chosen (tc files will appear also in CUPS mode, but then they are gathered by the CUPS service). You can change/overwite all the cups/tc files between manual runs to test things. If you reinitiate from web UI, all these will be overwritten again, though.
To start the basic station service again permanently use /etc/init.d/lora-network-server start
and await confirmation.
Final note on the authorization issues.
You can update the cups/tc.key files in terminal by echoing to the files: echo "Authorization: NNSXS.GYGYIGHJHJHJHJHJHJHJ......FGHGH" | perl -p -e 's/\r\n|\n|\r/\r\n/g' > cups.key
The perl end-of-file addition here is strictly necessary. Simple \r\n endings as suggested by multitech will fail. The web UI does this in the initialisation, so there you only have to enter the correct CUPS/LNS API KEY in the box with the format Authorization: NNSXS.GYGYIGHJHJHJHJHJHJHJ......FGHGH
Will update as soon as I figure out anything more. Would appreciate others to do so too!
As @cjhdev pointed out I think the main reason this doesn’t work for the time being is the wrong settings being pushed from the LNS server which overrides the local station.conf. According to MultiTech the clksrc must be 0, not 1 as TTN insists on. I made a new topic specifically for this here: Any way to edit the TTNv3 gateway global_conf.json?
In the meantime, stick to mp_pkt_fwd on TTNv2, or use the default (legacy) PACKET FORWARDER mode in the AEP webUI for either TTNv3 or “legacy” gateways (EUI-mode) on TTNv2. The latter works as long as you make sure the EUI in the TTNvX matches the LORA module EUI. Router address is router.eu.thethings.network for TTNv2 and eu1.cloud.thethings.network for TTNv3 (change eu for other regions…). Ports are 1700 up/down in both cases. Gateway keys are irrelevant for the legacy forwarder.
As to @jreiss recommendation, I followed the provided CUPS guide and managed to connect the AEP Conduit to TTN V3
One thing to notice, you need to use the default station config by multitech and not the station config settings you can download from TTN. This same config works for any channel plan when using CUPS as it will get the channel plan from the LNS.
Hi @tom-iotexperts
Yes, this is a screenshot of my config. (gateway key truncated in screenshot - I tried both with, and without, “Bearer”)
The gateway is Multitech conduit MTCDT-210A with firmware 5.3.3 (latest available for download)
I noticed that the certificate in your server config doesn’t matche the one from https://letsencrypt.org/certs/isrgrootx1.pem - however, as there’s no TLS issues I don’t think the cert is the issue
Following up to myself…
After changing EUI in the TTN console from “00 80 00 00 00 00 C2 F5” to “00 00 00 80 00 00 C2 F5” CUPS actually works and continues to LNS.However, now the initialization of the radio fails.
I found this post MultiTech Developer Resources » Topic: LoRa Basics Station with USB (MTAC-LORA-1.0) Lora card - it turns out that the Lora module in my conduit is the old model (MTAC-LORA-1.0) that simply isn’t supported for basic station mode. So I either need to spend 200 dollars on the new model, or look into the UDP packet forwarder.
Anyway, the original issue with CUPS and TTNv3 seems to be solved.
Hello.
I am having MTCDT-LEU1-210A-EU-GB problem.I set up a simple station 2.0.5-1-r2.0 says RUNNING but Disconnected in TTN V3.Never seems connected in TTN V3.How can I fix?
@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?
