Claiming Gateway: could not update CUPS credentials

Gateways TTIG - The Things Indoor Gateway
1

Hi everyone. First post so apologies if I’ve not got the level right.

I’m using this API to claim a TTI Indoor gateway:
https://www.thethingsindustries.com/docs/reference/api/gateway/#message:ClaimGatewayRequest

When I POST to the url (I’ve obfuscated the actual details with XXXXXX’s here):
https://XXXXXX.eu1.cloud.thethings.industries/api/v3/gcls/claim

With the following body:

{
    "authenticated_identifiers": {
        "gateway_eui": "XXXXXX",
        "authentication_code": "XXXXXX"
    },
    "collaborator": {
        "organization_ids": {
            "organization_id": "XXXXXX"
        }
    },
    "cups_redirection": {
        "target_cups_uri": "https://XXXXXX.eu1.cloud.thethings.industries:443"
    },
    "target_gateway_id": "XXXXXX",
    "target_gateway_server_address": "XXXXXX.eu1.cloud.thethings.industries",
    "target_frequency_plan_id": "EU_863_870_TTN"
}

And all the correct authentication headers.

The Gateway does not get claimed, but instead I receive a “could not update CUPS credentials” message, and the gateway ends up in my “Deleted (Admin)” section of the console.

{
    "code": 10,
    "message": "error:pkg/deviceclaimingserver/gateways:update_cups_credentials (could not update CUPS credentials)",
    "details": [
        {
            "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
            "namespace": "pkg/deviceclaimingserver/gateways",
            "name": "update_cups_credentials",
            "message_format": "could not update CUPS credentials",
            "correlation_id": "50319dc8d28b4f389f887ea93f882331",
            "cause": {
                "namespace": "pkg/deviceclaimingserver/gateways",
                "name": "operation_unsuccessful",
                "message_format": "operation `{name}` unsuccessful after `{number}` attempts",
                "attributes": {
                    "name": "update CUPS configuration",
                    "number": 5
                },
                "correlation_id": "a106c1ea88e04aee979f3fa8b89917d7",
                "cause": {
                    "namespace": "pkg/deviceclaimingserver/gateways/semtechrjs",
                    "message_format": "Unauthorized",
                    "correlation_id": "0dc707f67f7846979f28dfa34506a15e",
                    "code": 16
                },
                "code": 13
            },
            "code": 10
        }
    ]
}

I have found that if I purge the gateway I can repeat this, with the same result, many times.

Curiously, I’ve also found that if I purge it, then manually claim the gateway through the UI/Console that it will claim successfully. If I then delete it again, the API call above will now work without any modification. This implies that there is some extra step needed during initial registration that is missing through the API.

Does anyone have any experience of this error or can suggest what I’ve done wrong?

I saw a post from 2021 (Move your TTIG to V3: YES! - #19 by rikietje) that implied that it was an upstream server that was not functioning correctly, but I’m not sure if there’s anything I can do differently here or how to get that fixed. Any suggestions welcome.

1 Like
2

It might also be worth adding that I’ve tried this with multiple Indoor gateways over the course of the last few weeks and can reliably recreate this issue every time.

3

If you open the developer console on the browser you can see the exact calls used to do the registration - that may fill in the missing item that is causing a hiccup.

The non-functioning server was down for about half a day and is essential for any claiming processes so if it works in the console, then it’s OK.

4

Hi Nick

Firstly, many thanks for taking the time to reply - I hadn’t realised I could do that so that’s been useful to capture the details of a working request in the console.

Disappointingly though there is essentially no difference in the call made by the console compared to the one I made using Postman.

Certainly the body & url are the same. There are some differences that I that I cannot emulate (cookies, origin, etc). Now I’m wondering if the cups server might be ignoring the authorisation header or using a different form of authorisation? Or possibly it could be an origin problem - the Referrer Policy on the working request from the console was “strict-origin-when-cross-origin”.

Feels like there’s a setup issue with our TTI tenant, has anyone experienced this issue before, or do any of the TTI staff monitor these forums that might be able to dig into our configuration?

Thanks again
Ed

5

Cookies, Origin etc aren’t an issue. If any API call doesn’t like your auth header it says so. And it hasn’t.

Maybe. There is a message that indicates an authorisation issue inside the processing. Have you looked in to that & cross referenced against a console run?

Not really / occasionally / not as a matter of routine, you should use your support contract contact.

6

Thanks again Nick. The only message I’ve seen is the one I posted originally, is there somewhere else I can get hold of more detailed logs?

7

The message is inside the processing that indicates a potential cause for why the update CUPS config failed.

These are the only logs we get.

I’m assured that the API calls we make are the very same that the web console makes. So either do a compare & contrast or use your support contract.