@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
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
and wait for confirmation. Run it manually to get the errors out (first go to the lora service directory)
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
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
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
Will update as soon as I figure out anything more. Would appreciate others to do so too!