Upgrade to The Things Network v3.21.0 (completed)

Completed: Upgrade to The Things Network v3.21.0

This is a cross-post of an incident on our The Things Network status page.
It will be updated automatically.

Scheduled: Mon, 08 Aug 2022 12:00:00 +0200 until 14:30:00 +0200

Resolved: Mon, 08 Aug 2022 14:30:31 +0200

Affected Components

  • Europe 1 (eu1.cloud.thethings.network): Operational
  • North America 1 (nam1.cloud.thethings.network): Operational
  • Australia 1 (au1.cloud.thethings.network): Operational


Posted: Fri, 05 Aug 2022 18:58:31 +0200

During this maintenance window we will upgrade The Things Network v3.21.0

We do not expect noticeable downtime during this deployment.

Here is the changelog since the current version v3.20.2:


  • BatchGetGatewayConnectionStats RPC to fetch Gateway Connection Stats for a batch of gateways.
  • The ability to disable the downlink scheduling mechanism for individual end devices (mac-settings.schedule-downlinks).
    • This option is useful during a migration procedure in order to force the end device to join the new network. The Network Server will no longer schedule any data downlinks or MAC commands, and will stop answering potential join requests.
  • Support for comma-separated (,) values in The Things Stack CSV file format for importing end devices.
  • Support for the RxParamSetup, RxTimingSetup, TxParamSetup, and DlChannel sticky answer mechanism. The commands were supported previously, but subsequent sticky responses would cause the Network Server to drop the MAC command buffer in certain situations.
  • Button with connection to the Network Operations Center in the Console.


  • Deleted users are no longer included in primary email addresses uniqueness checks. This allows a user to create a new account which uses the email address of a deleted account.
    • This requires a database schema migration (ttn-lw-stack is-db migrate) due to updated indices.
  • The CLI settings fields retry-config.enable_metadata and retry-config.default_timeout have been renamed to retry.enable-metadata and retry.default-timeout for consistency reasons.
  • Generated device ID based on a DevEUI from an imported CSV file is now prepended by eui-. This is consistent with generated device IDs by the Console.
  • The Claim Authentication Code (CAC) field is stored in the Identity Server instead of the Join Server.
    • This requires a database schema migration (ttn-lw-stack is-db migrate) because of the added columns.
    • CAC values stored currently in the Join Server should be migrated to the Identity Server. One method is to run the following CLI commands on each device with a CAC.
      • Read the current values using ttn-lw-cli dev get <application-id> <device-id> --claim-authentication-code. This will fetch the value stored in the Join Server as a fallback.
      • Write back the value read ttn-lw-cli dev set <application-id> <device-id> --claim-authentication-code.valid_from [xxx] --claim-authentication-code.valid_to [xxx] --claim-authentication-code.value <xxx>. This will by default write to the Identity Server.
      • Note that this requires a minimum CLI version of 3.21.0.
  • Device Repository no longer uses the ApplicationID for validating requests. Authentication is still necessary, but the ApplicationID field has been deprecated in the Device Repository API.


  • Console showing 404 Not Found errors for pages containing user IDs in the path, when the user ID has a length of two.
  • CLI no longer panics when deleting a device without JoinEUI, this scenario only occurred when deleting a device that uses ABP.
  • Console crashing when navigating to certain Packet Broker network configuration pages.
  • Packet Broker network pages becoming inaccessible until refreshing after a user navigates to a non-existing network.
  • The batch update query for EndDevice.LastSeenAt field now specifies the data type of the placeholders.
    • This resolves an issue in the Console where Last activity values were inconsistent.

In Progress

Posted: Mon, 08 Aug 2022 12:00:36 +0200

Scheduled maintenance is currently in progress. We will provide updates as necessary.


Posted: Mon, 08 Aug 2022 14:30:31 +0200

The scheduled maintenance has been completed.

Will this be available for devices that are on V3 already?

The incident on our status page was just updated with new information. The first post in this topic has been updated accordingly.

The incident on our status page was just updated with new information. The first post in this topic has been updated accordingly.

It seems not to work yet on V3:

$ ttn-lw-cli end-devices get <app-id-hidden> <node-id-hidden> --mac-settings.schedule-downlinks
unknown flag: --mac-settings.schedule-downlinks

Als wel as hidden feature does not work:

$ ttn-lw-cli end-devices set <app-id-hidden> <node-id-hidden> --mac-settings.schedule-downlinks false
unknown flag: --mac-settings.schedule-downlinks

Or have I got the wrong command setting/node version?

I tried with the latest (available) ttn-lw-cli version

The Things Network Command-line Interface: ttn-lw-cli
Version:             3.20.2
Build date:          2022-07-20T07:58:54Z
Git commit:          65556a319
Go version:          go1.18.4
OS/Arch:             windows/amd64

… but get the same “unknown flag” response. Perhaps the ttn-lw-cli needs bumping up to be in sync with the recent v3.21.0 ? Just a thought.

We haven’t yet released the assets for v3.21.0. We do that after the updates to make sure that we include fixes that show up during/immediately after the deployment.

You can either build the latest CLI directly from the repository or wait for a day (or two max) when we officially push the release to Github.

If you still have issues after that, please feel free to open a new topic. Since this topic is related to the v3.21.0 update (and potential operational issues related to that), I’m closing this.

Keeping this post open for other issues related to the v3.21.0 update.