Here is my migration experience:
-TTIG bought off amazon.de … most presumably also from iotshop
-Claiming did only work successfully after the 3rd attempt
-none of the previous attempts did report any errors (always got GW listed in V3, but “disconnected” … several power cycles or “patience” did not help)
2 Likes
-Claiming did only work successfully after the 3rd attempt
What error did you get?
always got GW listed in V3, but “disconnected” …
What’s the status of of the LEDs? Please check their status to determine if they are connected to the WiFi network which seems to be a common cause of disconnection.
The LED States are documented here; https://www.thethingsindustries.com/docs/gateways/models/thethingsindoorgateway/
It worked for him, nothing to fix here!
Security question:
Given that the claim code (Wi-Fi password) is on the label of the gw, can a malicious person that has physical access to the gw re-claim the gw to themselves once I’ve claimed it in V3 once?
Once a gateway is claimed, it would need to be authorized for claiming in order for someone else to be able to claim it. See also Make a Gateway Claimable | The Things Stack for LoRaWAN.
1 Like
I did not get any error - just a new GW in V3, which had been listed “Disconnected”, while the V2 version did received packets. The Led used to be solid green. … but as mentioned by McCloud → the third attempt of claiming was successful and there is nothing to be fixed here.
Just wanted to share my experience with others.
1 Like
the third attempt of claiming was successful
Thanks for your feedback. I would really like to work the first attempt. What went wrong in the first two attempts that we can improve for others?
Better documentation?
From what I understood, nothing actually went wrong; the gateway just didn’t show up as online immediately, so perhaps the last step
sometimes takes a bit longer?
I’ve another TTIG I can try and I need another one to butcher for solar / external antenna so I can try that.
But reading in between the lines from the varying reports, it would seem that the four settings required don’t appear (see my post above for a screen shot) so it seems best to delete & retry.
Is there any caching going on in the process such that after any delays in retrieving the claim from external services (pre-processing by TTI, transit or the other ends processing), the subsequent try has all the data to hand and so runs faster?
TTIG claiming is meant to work the first time. If you power cycle your gateway and it’s not connecting, please mention that here with your EUI and I’ll take a look. If there’s a bug somewhere, that should be fixed. Don’t delete and retry as that is not necessary.
Erm, sorry Krishna, it is. Numerous people aren’t getting the settings first time and they can’t wait on you picking up & investigating their case. We’ve found a work around that does the job for the majority and I’m happy to run tests with you, but we have to find a good old fashioned compromise and for now, that seems to be it.
Ok then let’s fix this so that more people don’t have to do that. If I can get a couple of EUIs where
- Claiming was successful and the gateway was created in V3.
- Users waited for 24 hours (for non-reachable gateways) or power cycled (reachable gateways).
- Gateways were able to connect to the internet properly and the LED shows solid GREEN (not blinking).
- The Gateway is still shown as disconnected in the V3 console.
If your case checks all the above boxes, please either paste your EUI here or send it to me via a private message and I’ll take a look.
Again, sorry not sorry, but the issue we are trying to fix is that people go through the claim process, it doesn’t show an error, they aren’t aware that the LNS key & attributes haven’t been setup because they don’t know to look for them so they come to the fair assumption that it’s all done but in fact nothing happens.
Once pressed to correctly answer (which is somewhat of a lottery on here) with the screenshot I made a few days back, they find those fields aren’t setup, delete & retry and after one or more additional goes, it works.
I’ve not yet seen a successful claim that included those fields that hasn’t subsequently connected.
I have seen 10+ posts where people have deleted & retried until it was worked and 5+ posts where people have checked for the 4 fields, they’ve been missing, they’ve deleted & retried. Along the way we have to steer them past the panic attack of EUI vs ID vs not being able to reuse their ID.
@Jeff-UK calls me the independent v3 tester, I suspect he will tag me as the independent support desk soon. To that end I’m inclined to knock up a PDF and close down all these different threads so we can start one thread to concentrate on, as we are split over two at present.
-
Attributes: That’s not right. Those attributes are extracted from the gateway when it first connects and not from the Claim command on the console. So when you successfully claim, it expected that you don’t see the attributes until the gateway actually connects.
-
LNS Key: The LNS Key is always created during a successful claim. If that field is empty in the console, that’s most likely related to a console bug reported here; Gateway console field 'LoRa Basics Station LNS Authentication Key' is empty after recovering from "An unknown error occurred" · Issue #4335 · TheThingsNetwork/lorawan-stack · GitHub.
That can be cross checked with the CLI.
Although trying multiple times might get the job done, I would really rather find out why and fix it. If there is a case(s) that we haven’t accounted for somehow, we need to find that and having debugging information is helpful.
I completely get you that the signal to noise ratio for debugging info is far from ideal. If we need to close all these threads and start a new single thread where we can solicit specific debugging information, let’s do that. I’ll leave that your expert mod judgement 
And I’d know this how? Please try to remember we are doing much of this blind - but now I know, good to know.
It is however a good indication that it is connected!
Ditto, plus if it’s missing, it wasn’t successful. I only read the GitHub issues list once a week (!!!)
God yes, that’s the end goal here, don’t think for a minute debugging TTIG claims is a fulfilling part of my life, it’s driving me insane but I must be insane already because I just can’t help myself from answering queries.
1 Like
I get an error when trying to claim my gateway:
{
"code": 10,
"message": "error:pkg/deviceclaimingserver:update_cups_credentials (could not update CUPS credentials)",
"details": [
{
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"namespace": "pkg/deviceclaimingserver",
"name": "update_cups_credentials",
"message_format": "could not update CUPS credentials",
"correlation_id": "491b2a837ae04039bbb76252d69ad78a",
"cause": {
"namespace": "pkg/deviceclaimingserver/gateways/semtechrjs",
"message_format": "Internal Server Error",
"code": 2
},
"code": 10
}
],
"request_details": {
"url": "/gcls/claim",
"method": "post",
"request_id": "deddb20a-17bd-4dfa-89c5-60ffc02701b0",
"stack_component": "is"
}
}
And when I try again I get:
{
"code": 6,
"message": "error:pkg/deviceclaimingserver:gateway_already_exists (gateway with ID `eui-58a0cbfffe80049a` already exists. Please try using a different ID)",
"details": [
{
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"namespace": "pkg/deviceclaimingserver",
"name": "gateway_already_exists",
"message_format": "gateway with ID `{id}` already exists. Please try using a different ID",
"attributes": {
"id": "eui-58a0cbfffe80049a"
},
"correlation_id": "4666f2fe82b3453aa7c74b29ed188176",
"code": 6
}
],
"request_details": {
"url": "/gcls/claim",
"method": "post",
"request_id": "a4e32f03-85db-4845-8746-36c420091dab",
"stack_component": "is"
}
}
The gateway does however show up on my TTSv3 console, but it does not come online, neither on V2 nor on V3.
Looking at the gateway on the V3 console I see the EUI and the LNS Key are empty. The attributes are also empty.
What do I do now? Maybe we should update @htdvisser’s original post to include any new steps.
@KrishnaIyerEaswaran2 58A0CBFFFE80049A
[moderator-mode-on]
Don’t flag posts because you want them editing with things you don’t know exist. Please use search and read other posts & topics like the rest of us.
[moderator-mode-off]
We don’t yet know why, but sometimes it takes a few goes for all the data to be collected. As you can read in the post directly above yours, if there is no LNS key, it’s not worked.
The second error message should be self-explanatory and is a common question, so common that both me & @KrishnaIyerEaswaran2 are now entitled to a free counselling session.
Getting it to work first time is on the to do list, but at present you may have to try several times before all the parts sync up.
The above thread contains a lot of contradictory info. And to be honest, I trust @KrishnaIyerEaswaran2’s post much more than yours. So I did what he said, posted the errors, described what I’ve seen, provided my EUI. Also because the checklist that was provided by him was ran through.
Cheers, but if you take some time, you’ll see that I was asserting the opposite situation - LNS Key yes = success, I was highlighting no LNS key, not successful.
You weren’t successful, criteria not met.
No evidence to say you waited 24 hours - which would be foolish to do - criteria not met.
Everyone else has to combine the current info. And don’t you think that @KrishnaIyerEaswaran2 would correct any erroneous entries that quote him?
It’s simple. It didn’t work. Delete it and try again with a new ID. Yes, it should work first time. But currently it doesn’t, something that’s being worked on.
