Upgrade to The Things Network v3.22.0 (completed)

TTN Announcements
1

Completed: Upgrade to The Things Network v3.22.0

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

Scheduled: Mon, 03 Oct 2022 14:00:00 +0200 until 18:00:00 +0200

Resolved: Mon, 03 Oct 2022 18:00:38 +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

Scheduled

Posted: Mon, 03 Oct 2022 10:36:34 +0200

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

We do not expect noticeable downtime during this deployment.

Here is the changelog since the current version <currently-deployed-version>:

Added

  • Add more specific rights for OAuth clients.
  • Experimental support for mTLS connections for LoRa Basics Station CUPS and LoRa Basics Station LNS (LNS-only mode) connections.

Changed

  • The flow for adding end devices has been updated in the Console.
    • Device QR codes can now be scanned to speed up end device onboarding.
    • Claiming end devices from external Join Servers is now possible seemlessly from the same onboarding flow.
  • LoRa coding rate now defined in DataRate instead of Band.
  • The Network Server will now schedule a potentially empty downlink in order to stop end devices from sending sticky MAC commands.
  • Factory preset frequencies may now be provided for bands with fixed channel plans, such as US915 or AU915. The factory preset frequencies are interpreted as the only channels which are enabled at boot time.
  • TxParamSetupReq MAC command priority has been increased.
  • DevStatusReq MAC command priority has been lowered.
  • Event subscriptions without history are now sent to the Redis read only replica, if it is available.

Removed

  • Removed coding rate from TxSettings as it is now defined in DataRate.

Fixed

  • --mac-settings.adr.mode.disabled, --mac-settings.adr.mode.dynamic and --mac-settings.adr.mode.static flags of the end-device update command.
  • Pagination in sessions and access tokens tables in the Console.
  • LinkADRReq MAC command generation for LoRaWAN 1.0 and 1.0.1 end devices.
  • LinkADRReq no longer attempts to enable channels which have not yet been negotiated with the end device.
  • Downlink path selection for uplinks which are not LoRa modulated.
  • Issues with byte inputs in the Console.
    • Pasting values into the input leading to issues in some cases.
    • Values being typed double on android phones.
  • Console showing deleted collaborator after successful deletion in application collaborator list.
  • Console crashing after deleting an organization.

In Progress

Posted: Mon, 03 Oct 2022 14:00:39 +0200

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

Completed

Posted: Mon, 03 Oct 2022 18:00:38 +0200

The scheduled maintenance has been completed.

1 Like
2

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

3

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

4

Hello.

After this upgrade, I am no longer able to set “Factory preset frequencies” and received this error:

{
“code”: 3,
“message”: “error:pkg/networkserver:field_value (invalid value of field mac_settings.factory_preset_frequencies)”,
“details”: [
{
“@type”: “type.googleapis.com/ttn.lorawan.v3.ErrorDetails”,
“namespace”: “pkg/networkserver”,
“name”: “field_value”,
“message_format”: “invalid value of field {field}”,
“attributes”: {
“field”: “mac_settings.factory_preset_frequencies”
},
“correlation_id”: “ad05454ed8ba4a8985b991c8f278429e”,
“code”: 3
}
]
}

image

I was just playing with this option at the time of the upgrade and right before the upgrade I was still able to make the change. I am using “Asia 920-923” and my device is trying to join at 922.0 and 922.2 MHz.

Thank you.

5

Looks similar to this and the post on Slack - an issue with the console app not being quite refreshed …

6

Thanks for your response. I also tried CLI (latest downloadable v3.21.2) and received similar error.

./ttn-lw-cli end-devices set --mac-settings.factory-preset-frequencies 922200000
error:pkg/networkserver:field_value (invalid value of field mac_settings.factory_preset_frequencies)
field=mac_settings.factory_preset_frequencies
correlation_id=eb433b25fdd14711b54f973ecd059490

7

To me the name suggests multiple values, isn’t there a list of some kind (even with just one value) required?

8

Thanks for the note. I believe it has syntax check. For example, when I used 922MHz instead of 922000000, the error would be:

invalid argument “922MHz” for “–mac-settings.factory-preset-frequencies” flag: strconv.ParseUint: parsing “922MHz”: invalid syntax

9

Why not look at the source code?

10

I’ve spoke to Head Office and a hot fix is in hand for an issue with EUI generation and factory preset frequencies - to be deployed at some point tomorrow.

11

Hello, new end device now will not register. Clicking on the “Register end device” button the page does not move to the view registered end device page and does not register the end device. Is there something I need to do here that is different to get this to work? (See below).
Error

12

Maybe you could read the posts above …

13

Hi Nick, I have tried to manually register a number of new end devices after the upgrade, but I get the same issue were after clicking the “Register end device” button nothing happens. I get no errors or warning messages when setting configuration. Last week I had no issues with registering devices.

14

Why have you not read the whole thread as suggested??

I very literally answer your concern in the post right above your post which was entirely redundant if you’d read the topic before posting.

15

Thanks for reporting everyone. This issue should now be resolved on TTN. Another issue with DevEUI generation is also resolved.

3 Likes
16

I noticed that when counter is 0 (after join), “f_cnt” field is missing from Webhook JSON message.
Noticed this on different devices, applications and users.

Not sure if I missed something in recent system changes which causes this. Can’t say if this is from last release.

From my personal experience sometimes if value is set to zero, some programming languages understands it as “null” and than removes it. (Just my 2 cents in possible solution :slight_smile: )

17

This has been the case from the start. There should be forum messages regarding this from some time ago.

18

I see now. Thanks for pointing on previous discussions. I somehow didn’t register this issue before.