The things upgrade v3 missing field "session.dev_addr"

TTN V2 to V3 Upgrade Migrating Devices to V3
1

Tried to upgrade my device from v2 to v3 using the following generated device.json:

{
    "ids": {
        "device_id": "appid001003",
        "application_ids": {
            "application_id": "appid001001"
        },
        "dev_eui": "A840410001818B3C",
        "join_eui": "9EF1E12F9A7877D9"
    },
    "created_at": "0001-01-01T00:00:00Z",
    "updated_at": "0001-01-01T00:00:00Z",
    "name": "appid001003",
    "lorawan_version": "1.0.2",
    "lorawan_phy_version": "1.0.2-b",
    "frequency_plan_id": "EU_863_870_TTN",
    "mac_settings": {
        "rx1_delay": {
            "value": 1
        },
        "supports_32_bit_f_cnt": true,
        "resets_f_cnt": true,
        "status_time_periodicity": "0s",
        "status_count_periodicity": 0
    }
}

but get the following error:

{
  "code": 3,
  "message": "error:pkg/networkserver:field_mask (invalid field mask)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/networkserver",
      "name": "field_mask",
      "message_format": "invalid field mask",
      "correlation_id": "e8c3ec4e0ebd44e5a3a89cc2e932c0be",
      "cause": {
        "namespace": "pkg/ttnpb",
        "name": "missing_field",
        "message_format": "field `{field}` is missing",
        "attributes": {
          "field": "session.dev_addr"
        },
        "code": 2
      },
      "code": 3
    }
  ],
  "request_details": {
    "url": "/ns/applications/appid001001v3/devices/appid001003",
    "method": "put",
    "stack_component": "ns"
  }
}

Any help regarding this would be appreciated.

2

Could you cite the specific basis for thinking this would be a working path?

You appear to be trying to transfer registration of an OTAA device, so it would have to re-join and get a new session device address in the new network’s pool.

In so doing though, you should’t try to tell it to use TTN V2’s 1x RX1, but rather let V3 command the proper 5 second RX1 as part of the joining process.

3

Thanks for the fast reply. I don’t know what you exactly mean. I followed the tutorial and executed:

set TTNV2_APP_ID=appid001001
set TTNV2_APP_ACCESS_KEY=ttn-account-v2.xxxxxxxx-xxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx
set FREQUENCY_PLAN_ID=EU_863_870_TTN
ttn-lw-migrate device --source ttnv2 appid001003 --verbose > devices.json

I imported the generated devices.json file, giving me the error.

Can you please clarify what I did wrong? Thnx in advance

4

If you search the forum you’ll find other references to the field_mask (invalid field mask) issue.

5

I have the exact same problem and searching for the specific error does not provide any answers, but ironically just leads back to this thread.

I tried to export with --ttnv2.with-session=false, but produces the same error.

6

Hi Ateainsigths

I stopped trying, I deleted my gateway and devices from v2 and added them fresh to v3.
Now its all working again.
But, yes, you loose the data on v2, so that’s a disadvantage.

7

Thank you Oberon. However, that’s not really an option - well, that would be a last resort anyway :slight_smile:

I think it’s safe to say that Nick McCloud’s answer didn’t really help much, since we both hit a dead end. Is there anybody who had this problem and solved it?

8

I didn’t have the problem …

9

I believe there atleast 3 other threads that call out this specific issue ( field_mask (invalid field mask) ) TL:DR as, like Nick, I dont have the problem!

We have no way of knowing ahead of time as we dont have same problem, atleast he had the courtecy to try and point you in right direction :wink: …sometimes there is no helping some people and little thanks for trying. :man_shrugging: Mods do this work voluntarily and often for little appreciation - just saying :slight_smile:

10

Thanks Jeff. By no means I meant to insult anybody. I was merely concluding that the suggested answer did not help.
I am sorry if it was somehow perceived differently.

11

I’d like to add the following:

The above poses a remarkable contrast: You thank one user while saying his response is not really an option and then state that another user’s answer didn’t really help much (without thank you). You also mention the second user explicitly by name instead of the common @userid, while not being positive.

That is not what a positive contribution looks like.