It’s the WiFi password - see the docs and further up this thread plus forum search, web console is far simpler.
I have exactly the same problem with my TTIG gateway - 58a0cbfffe800bc8 - like @hardwario
About “token”.
Of course I used WiFi Password (NrEnxyz) as a Token, unfortunately without success. That’s why I asked the question.
C:\Users\jacek\Downloads\ttn_cli>ttn-lw-cli gateways claim authorize eui-58a0cbfffe800bc8 NrEnxyz
error:cmd/ttn-lw-cli/commands:no_gateway_id (no gateway ID set)
correlation_id=98ba919c53374511b8e26e43af2229c3
C:\Users\jacek\Downloads\ttn_cli>ttn-lw-cli gateways claim authorize eui-58a0cbfffe800bc8 --api-key NrEnxyz
WARN Finished unary call {"duration": 0.1583, "error": "rpc error: code = Unauthenticated desc = error:pkg/identityserver:invalid_authorization (invalid authorization)", "error_correlation_id": "0cf98606bd4b431f9d59c920a2349f6c", "error_name": "invalid_authorization", "error_namespace": "pkg/identityserver", "grpc.method": "ListRights", "grpc.service": "ttn.lorawan.v3.GatewayAccess", "grpc_code": "Unauthenticated", "namespace": "grpc", "request_id": "0407e45d-355a-49f3-b22a-5122134fbee1"}
error:pkg/identityserver:invalid_authorization (invalid authorization)
correlation_id=0cf98606bd4b431f9d59c920a2349f6c
My deepest apologies, I made a huge mistake, I thought you wanted to know where to get the token for claiming, I am a bad person.
Have you tried using the web console?
If I could use the web console to move an existing TTIG from V to V3 then I would not use CLI.
OKAY.
Let’s start from the beginning.
Step 1 Web console
Step 2 CLI
C:\Users\jacek\Downloads\ttn_cli>ttn-lw-cli login
INFO Revoking the old OAuth token...
INFO Opening your browser on https://eu1.cloud.thethings.network/oauth/authorize?client_id=cli&redirect_uri=local-callback&response_type=code
INFO After logging in and authorizing the CLI, we'll get an access token for future commands.
INFO Waiting for your authorization...
INFO Successfully got an access token.
C:\Users\jacek\Downloads\ttn_cli>ttn-lw-cli gateways claim authorize eui-58a0cbfffe800b**
INFO No API Key provided. Creating one
WARN Finished unary call {"duration": 0.0955, "error": "rpc error: code = PermissionDenied desc = error:pkg/auth/rights:no_gateway_rights (no rights for gateway `eui-58a0cbfffe800b**@ttn`)", "error_correlation_id": "eaaa40db2dee47498cc20fb4c9a44fb9", "error_name": "no_gateway_rights", "error_namespace": "pkg/auth/rights", "grpc.method": "CreateAPIKey", "grpc.service": "ttn.lorawan.v3.GatewayAccess", "grpc_code": "PermissionDenied", "namespace": "grpc", "request_id": "b71d7bdf-932d-4362-a232-935f496c6d23"}
error:pkg/auth/rights:no_gateway_rights (no rights for gateway `eui-58a0cbfffe800b**@ttn`)
uid=eui-58a0cbfffe800b**@ttn
correlation_id=eaaa40db2dee47498cc20fb4c9a44fb9
Why has the authorization for the claim failed?
Can you help me?
Is eui-58a0cbfffe800b** a gateway that you have already registered in v3 and is that the correct ID?
ID eui-58a0cbfffe800bc8 of gateway is correct. I used this gateway in V2 (and it is still working in v2). Now I try move it to V3.
You have a good line in sarcasm which isn’t engendering any enthusiasm to help and I don’t want to dilute my TTIG registration success rate but I will press on.
And if I was going to respond in a similar fashion, I might say that you can’t use the CLI either, but that would be unkind.
The link you provided says nothing about v2 and is all about transferring a TTIG on TTS which v2 is not.
The CLI command you are issuing is to tell TTS (aka v3) that the TTIG is OK to be claimed by someone else in the LoRaWAN universe. As it is not registered on TTS yet, it fails, because it doesn’t know about your TTIG.
Some may say that I should have spotted this earlier, but I haven’t had cause to authorise a TTIG for claiming on TTS yet, so despite having a good handle on the CLI, the juxtaposition of your trying to claim and the information supplied didn’t quite raise an alert that there was something up.
And in my defence, you caught out @KrishnaIyerEaswaran2 as well and in his defence, he is still recovering from earlier attempts by others trying to subvert the claim process.
I trust you are aware that you put the WiFi password aka Claim authentication code in an earlier post, but the red squiggle on the screen shot is nice.
If you have the TTIG close by, I’d do a @Jeff-UK and take a picture of the details on the back because the web console message implies that the EUI you have entered is wrong OR by some unlucky chance, someone else has registered a gateway with that EUI.
The first potential problem you can act on by enlarging the image and checking that the letters and numbers match up - B’s & 8’s are known issues.
The second potential problem you can act on by using the API to look up the existing gateway EUI to see if it yields any clues as to it’s owner.
There is a third possibility that we have recently come across and that is that you or someone else in your organisation has already registered it but not told you.
…and looking at this quote and the picture you posted (partial red squiggle) where it looks like at least one character is different between the two I would guess mis-typing the code is not beyond reason (look carefully at you own posts and as Nick suggests take a decent pic and enlarge to check which if any is correct… 
Obviously realise you are joking with the xyz to obscure…
But you should check that as well as the EUI just in case - we cant review it for you…
If in the past, I registered and used TTIG in TTN v2, I had to enter EUI and WiFi password without errors, right?
Now, let’s start over again.
As I’m not a specialist like the other forum users present here (I’m really a beginner), I’m simply asking what the answer I got from the CLI means when trying to claim authorize. See below.
C:\Users\jacek\Downloads\ttn_cli>ttn-lw-cli gateways claim authorize eui-58a0cbfffe800bc8
INFO No API Key provided. Creating one
WARN Finished unary call {"duration": 0.0955, "error": "rpc error: code = PermissionDenied desc = error:pkg/auth/rights:no_gateway_rights (no rights for gateway `eui-58a0cbfffe800bc8@ttn`)", "error_correlation_id": "eaaa40db2dee47498cc20fb4c9a44fb9", "error_name": "no_gateway_rights", "error_namespace": "pkg/auth/rights", "grpc.method": "CreateAPIKey", "grpc.service": "ttn.lorawan.v3.GatewayAccess", "grpc_code": "PermissionDenied", "namespace": "grpc", "request_id": "b71d7bdf-932d-4362-a232-935f496c6d23"}
error:pkg/auth/rights:no_gateway_rights (no rights for gateway `eui-58a0cbfffe800bc8@ttn`)
uid=eui-58a0cbfffe800bc8@ttn
correlation_id=eaaa40db2dee47498cc20fb4c9a44fb9
My next question is: Is it possible to remove TTIG eui-58a0cbfffe800bc8 from TTN network? So that I can do claim gayeway in TTN v3 web browser for new (not existing) TTIG gateway?
Is it possible for me to check if the TTIG eui-58a0cbfffe800bc8 belongs to another user or organization? What command in CLI should I type to check this?
It’s saying:
Yes, delete it from v2, not recommended nor required nor indicated in the instructions nor indicated by the TTI team.
If you review the above and search the forum you’ll find that we don’t recommend removing it as it will stop forwarding the uplinks AND no one else has been required to do that.
Potentially, as there are various facilities that allow gateway locations to be looked up to allow mapping apps.
I don’t know so we are both starting from the beginning on this - again forum search and the docs will be a good starting place.
Hello everyone,
I am located in Argentina and using NAM1 cluster. My TTIG-AU915 cannot connect to the backend, I have claimed it following all the right steps but still no luck.
Could someone from the backend team please tell me if there is something wrong with it?
EUI-58A0CBFFFE8030BD
I apologise in advance in case this is the wrong place to post this message.
Thanks in advance
Created at “Jan 24,2022 12:37”
You either need to power cycle the TTIG or wait for it to update from the CUPS server (may take up to 24 hrs.), I assume you can see it connected to you local WIFi Router? What status is the top LED (Steady Green? Flashing Green?(Rate) Flashing Orrange/Red?..
And assume it was correct EUI? _ Small print so double, double check for common mistaken characters B,8, 0,6, etc…
Was it previously on V2 - and auto migrated 1st to V3 after V2 sunset or is it a new install?
Thanks for the quick reply.
The status of the top LED is steady green.
I assume previously on V2?
https://account.thethingsnetwork.org/api/v2/gateways/eui-58A0CBFFFE8030BD
Yes, that is correct it was previously on V2.
I did not do the migration on time before the V2 stack was turned off.
That says it is connected - dont trust the ‘disconnected’ status on console - - occasionally gets stuck (I think it is a scrapped value from another database/link, though will usually quickly start updating when triggered by traffic showing a last seen type time stamp), and may take a few hours to correct itself… do you have a node to hand? Is it showing data on TTN Console in Application and or Device views? If so all good and wouldnt worry… Also if you look at you GW’s console page listing do you see one listed as ID EUI… Name Auto-migrated-EI… or similar?
See here:
I have a node that is sending data periodically and can confirm the data is correctly received by using a Dragino LG308.
also if you look at you GW’s console page listing do you see one listed as ID EUI… Name Auto-migrated-EI… or similar?
I do not see anything like that. I did not use any migration tool for this gateway.
Click on one of the uplink messages and the expanded metadata (right hand side) will show all handling GW’s - hopefully including one you will recognise as your TTIG 
Also you can test further if TTIG handling ok by turning off your 308 briefly to see if data still comes through to console - unless other GW’s in the area are handling as well…
Sadly, still the same 
Data is only received by the LG308.
And turning off the Dragino stops data appearing in the Device console view?
BTW you need to back off your TX rate as at SF7, let alone the SF12 you are using you will breach the TTN FUP 
Also, just noticed the repeat downloads after each uplink - what node/firmware are you using? Looks like your device isnt handling downlinks/MAC commands correctly - system is telling to to use e.g. RX window delay 5sec etc. Is device OTAA or ABP? Are you using confirmed uplinks? (Hint - dont!)