It only applies if you got an LNS key - which you don’t.
We’ve answered dozens of these queries across many topics. You just have to try again.
error:pkg/deviceclaimingserver:update_cups_credentials
This indicates that the claiming process failed for a reason that’s not the user’s fault, most likely that an upstream server was not reachable by the claiming service. I need to build in some fault tolerance here so this is for me to look at.
@jpmeijers: Could you PM me your EUI? I’ll take a look.
@descartes: Do you still commonly see complaints of claiming not working the first time? Do you have a rough estimate of how frequently this happens based on your answering?
Not statistically valid, for people that it works, they don’t normally post a “it worked” message.
If it doesn’t work, some will read the threads and solve it themselves (one post says exactly that, so that’s both failure & success).
For others they will read/search, continue to fail and then post.
Others don’t read/search then post.
It’s been quiet the last few days but we were getting two/three a day for about a week.
I’m not wedded to my office TTIG, I can delete it and re-claim it to try at random times, that may reveal some hard data on the failure rate.
Mr Meijers has provided his EUI in a post above.
Thanks a lot @jpmeijers for reporting the issue. My suspicion was right in that the upstream server was flaky. This is quite a rare one (happened only twice the last 2 weeks based on the server logs) and you were the unlucky one. I’ve added some resilience to this part which will be deployed soon.
For now, unfortunately, I don’t have a better solution other than asking you to delete the gateway and retry claiming with a different ID. We have some ideas of improving this to allow claiming with the same ID but that’ll come in a future release.
Please let me know how this goes.
4 Likes
Thanks for checking @KrishnaIyerEaswaran2, it’s much appreciated.
I think I’ll wait for this. I really do want to keep my existing gateway ID, because a changed in ID will have negative effects on the TTN Mapper side.
1 Like
I had an internal server error when I tried the claim process of the TTIG the 1st time.
The gateway was registered but remained in disconnected mode even after power off/on process.
After discussing with @jpmeijers I deleted the gateway from my TTN account and made the claim process again, this time there was no error.
I power cycled the TTIG and after approx 1 minute, the gateway appeared online and now it is working well.
I hope this helps if you’re in the similar situation.
Best regards, U.
1 Like
@htdvisser Hylke, @descartes Nick, dont know if this helps your statistics gathering but a quick summary of my own TTIG V3 set-up experience so far.
As reported here Connecting TTIG to TTN V3 - #110 by Jeff-UK I set up my 1st TTIG on V3 using the claim process outlined by Hylke just over 3 weeks ago and experienced no problems, with GW quickly online after claim and power cycle. That unit was subsequently deployed for a short week near Bournmouth on the UK south coast to assist in some coverage mapping and survey work before returning to base office/lab where again it reconnected and came online no problems and then deployed for a long week down in Cornwall for similar exercise before returning to base again at the weekend. It looks stable on V3 and so will be redeployed back to original Cheshire site sometime next month.
In total I have 5 of my personal GW estate deployed on V3 so far - this included 3 TTIGs that have previiously been on V2 so my epxerience is around migration and claiming vs new deployments.
The other two were new deployments direct to V3 (Mikrotik & Tektelic Kona Micro), which again went fine.
My problem is most of my own TTIG’s and all those of clients or collaborators/colleagues I have helped deploy are remote and I dont have immediate access to Wi-Fi codes to effect migrations… more later.
On monday evening I decided to migrate the only other unit I had physical access to - TestGW037 - and so had claim code. As with TestGW036 the claim process went smoothly and again after a quick power cycle I could see it come online and start handling traffic. I remembered that one of the consequences of prior poor eyesight (before the bionic uplift 
) and small printing on the TTIG labels was I often resorted to using a magnifying glass or taking smartphone pic to zoom in and make sure I was not mis-typing EUI or WiFi codes. - a trawl through some 2 years worth of photo archives revealed I had pictures of lables, and hence the Wi-fi codes, for ~60% of deployed TTIG estate - result!
Armed with that I decided to try my 1st remote TTIG migration - based in Congleton, Cheshire (a relocation late '20 from north Manchester), where GW is none critical as site is awaiting sensor deployment next month so a low traffic/no traffic site as yet… If all went wrong I knew the site host had easy access to power-cycle, recover or return if needed. This ‘claim’ also went well with no issues. I decided to not disturb the site host to power cycle (not least as it was late night) but rather settled down to see how long it took to self refresh and complete migration. The image above reflects some 20-22hrs after claim…hence ‘disconnected’ at that time… a subsequent check after approx 25hrs (late Tues night/early Wed morning) showed it had self refreshed and was now online!
I’ve read the various comments wrt lack of LNS network key populating in the console indicating a failed claim… as can be seen from 1st claim 3 weeks back (link above) for TestGW036 there is no key shown - and yet the GW has performed admirably. TestGW037 shows a LNS key inplace:
As does the remote TestGW027:
But as stated, for TestGW036 nothing:
Though it is seeing traffic nd is connected just fine! - go figure…
TL:DR Based on experience through this week with now 3 for 3 on the TTIG’s I will be kicking off the migration of the rest of the remote estate for which I have ready access to Wifi keys starting next week (poss tonight for one of the most remote (Hamburg, DE) GW’s, otherwise that will wait till mid late Aug.)
Next problem is how to claim those where I dont have access to the Claim key? I guess I can have site hosts access perhaps half the the missing 40%, though likely needing to take them offline for a time to get to the back label, the rest I’m not sure about,…
My first try failed with an authentication error but the second try worked well!!! My TTIG is now on the V3 stack.
When I try to Claim my V2 TTIG Gateway to migrate to V3 using the instructions above provided by @htdvisser I receive the following error: “gateway with EUI 58A0CBFFFE801552 already exists and is not authorized for claiming”.
- My account is still active.
- My V2 Gateway is still active and shows up in my V2 Console as connected.
- I wrongfully registered my TTIG Gateway as a V3 gateway (Gateway ID: communipaw2) but subsequently deleted it.
- I don’t show any Gateways in my V3 Gateways Console.
Any assistance would be greatly appreciated.
and let me guess — you tried to claim it into v.3 now and you used “communipaw2” for the gateway-ID again ? Be sure that you are presenting the correct messages with ID or/and EUI to this forum - otherwise its like taking a deep look into our glas-sphere …
I’m not sure what I missed, but I can assure you I’m not trying to claim the gateway in V3 using the same Device-ID (communipaw2). I read enough comments in the Forum stating you cannot reuse a Device ID once its deleted. The error mentions the EUI ID. I tried several new Device-ID’s combined with the EUI ID of the device, but no luck.
Here is how I try to Claim my V2 Gateway in V3 (Claim authentication code masked):
Below is the Exact Error Message:
{
“code”: 9,
“message”: “error:pkg/deviceclaimingserver:gateway_not_authorized (gateway with EUI 58A0CBFFFE801552 already exists and is not authorized for claiming)”,
“details”: [
{
“@type”: “type.googleapis.com/ttn.lorawan.v3.ErrorDetails”,
“namespace”: “pkg/deviceclaimingserver”,
“name”: “gateway_not_authorized”,
“message_format”: “gateway with EUI {gateway_eui} already exists and is not authorized for claiming”,
“attributes”: {
“gateway_eui”: “58A0CBFFFE801552”
},
“correlation_id”: “1d3c7303259e4f9eb23056c70307bc40”,
“code”: 9
}
],
“request_details”: {
“url”: “/gcls/claim”,
“method”: “post”,
“request_id”: “24e74164-01cf-4b0a-a572-a5979a31c18b”,
“stack_component”: “is”
}
}
Can you confirm where/which sales channel you bought the TTIG through?
It looks like this particular gateway was indeed previously registered as communipaw2, but the collaborator (I guess you) revoked their (your) own rights, so it was orphaned. I just deleted the gateway, and you should be able to claim it now.
@htdvisser orphaning happened to me once with an application. Should it not be fundamental part of the architecture of V3 to prevent this from happening?
1 Like
A couple of tips for anyone struggling to migrate a TTIG that is remotely deployed or difficult to access short term and where you don’t have immediate record of the claiming code - aka the TTIG’s Wi-Fi password.
The code is needed when configuring & commissioning the device and logging on to the device’s MiniHub-80XXXX style WiFi SSID. On 192.168.4.1 local console.
A problem for many- me included - is that the printing of the details on the label is quite small and can easily be misread/mistyped…B & 8 being a classic that catches many out. To get round that as noted in my post above many will use a magnifying glass to read or if lucky will have taken a photo on a smart phone to zoom in for a closer look.
So Tip 1 is check old photo’s to see if by lucky accident you have made a record of the code you can now use for the migration!
Obviously to configure the device you need to have logged into the TTIG’s local console which means a compute device with a browser will have accessed the WiFi using the code.
If you used a Windows PC or Laptop then you can check the devices local WIFi cache of old connections to see if data is still stored and pull code from there. Sadly until Android 10 it is much harder on a stock smartphone and requires 3rd party tools - sometimes side-loaded and on a rooted device (not recommended from security perspective). Usually you need a way to get to the wifi_supplicant.conf file (under root) to extract details from there. Similarly with Apple iPhone, iPad and MAC devices they make life bloody difficult to get to codes you entered…despite the fact you would be the one to enter them, Dho! Though an internet search will lead you to some options where you can use a combination of tools iCloud, Keychain app and a MAC or other options to get some access in some cases with a following wind, god knows why they can’t just do the same as Windows and make the code accessible.
So Tip 2 is look at the historic WiFi cache of any device(s) used to configure the TTIG. If a Windows PC (7,8,10)… should be easy (e.g. go to network/WiFi icon on task bar, select Open Network and Sharing Center (sic), select Manage wireless networks on the controls panel, and you should then see a list of historic connections…scroll down to your MiniHubxxxxx of choice select it and check properties/ security settings where you you should see stared out version of desired WiFi pass code )
As above if you used Android or Apple devices you may not be so lucky or may have to take risks (rooting/sideloading) or just have to jump through lots of complicated hoops and over hurdles.
As I noted in post above I found around 60% of my TTIG estate from photo archives, sadly when checking WiFi cache on main Laptop PC to try and find any of the remaining TTIG codes just one MiniHub listing appears… for one one where I already had code/photo 
as I took decision a couple of years back to ‘travel lite’ when doing such in the field configs and usually use an iPad or old (Android 7 or 8) smartphone - a lot easier if up a mast/tower/working at height, and cheaper/safer if dropped!
From now on I will photo each new device label and log on with a Windows device at least once, so I don’t get caught out again. 
2 Likes
Yeah, we’ll do something about that.
I really appreciate your help @htdvisser. I was able to claim my gateway successfully in V3.
I am not sure how I revoked my own rights in V3, otherwise I would warn others NOT to do the same. I still “owned” the gateway in V2 and retained all my rights there. FYI…I purchased the TTIG gateway new in 2019.
Hallo everybody,
I have problems Claiming my Gateway.
Every time I try to Claim it I just get the Error “Claim authentication code mismatch”.
I used the EUI and the Claim authentication code (WiFi Password) from the label on the Gateway.
The Gateway is still registered in v2.
Every tip is very appreciated .