Add simple way to rejoin for TTN V2 to V3 migration

[terrillmoore]

We have a large number of devices in the field.

We need a simple way to force a rejoin with a new AppEUI. (Rejoining with the same AppEUI is a race condition with the V2 network, and involves break-before-make.)

Proposal:

Watch for port 239 messages, and interpret the 8-byte payload as the new AppEUI. Since anyone who can send a downlink knows the current credentials (or has access to them), we can use a MIC.

16 bytes plaintext: 3-byte nonce/salt | 1 byte opcode | 8-byte appEUI | MIC

MIC is calculated as aes128_cmac(AppSKey, plaintext), then taking bytes 0..3 of cmac[]. So a match proves that the message sender knew the AppSKey; as long as the network doesn't reuse application session keys, it defends against replay attacks. Of course, this requires that the app know the AppSKey, but it presently does.

The 4-byte nonce/salt is ignored by the receiver.

The receiver verifies the MIC, and if it matches, the opcode is examined. If 0, AppEUI is used to update the devices AppEUI for subsequent joins. If 1, the device re-joins (ignoring the AppEui).

Of course we have to update firmware; but this lets us schedule visits without having to synch with the cutover to V3.

All other messages are dropped.

[terrillmoore]

This is over-complicated. The first command can just cause the AppEUI to be set to zero. It has never been zero in the past. Once zero, the OTA command can't cause it to take on another value, so there's no possibility of hijacking. We can then use our existing rejoin mechanisms.

[mhmayyan]

I was trying to migrate one device to V3 cluster. The instructions provided by the TTN didn't work for me. I tried to use lorawan configure join 0 then lorawan configure join 1. I thought it could force a rejoin but it didn't work.

I had to reset the FRAM, and added a new device on V3 cluster and I used the previous AppEUI. It now works.

This is a problem. We have many devices in the field. If we need to update the firmware and do the same thing for every device then it will be a headache.

[terrillmoore]

Check whether your firmware is new enough that the lorawan join command works? lorawan configure join 0 / lorawan configure join 1 doesn't force a join.

[mhmayyan]

Yes, lorawan join works and I can see the device tries to join on V3 cluster. This is using the example "catena_hello_lora.ino". When I flash my application sketch the device message goes to TTN V2 cluster even though I changed the App Key on V2 and used the origional one on V3 as per the instructions of migrate-to-v3

How frequently does this library do a new join by itself?

Thank you, Terry

[terrillmoore]

Hi Mohammed, in my experience if both apps are live, it's a headache. Changing the appkey to zero in the V3 app seemed to work for me. Or deleting the V2 app.

I don't have confidence in the library rejoining by itself, at the moment.

If you say system version, the system will print the versions of the key libraries. If you'll let me know the versions, I can predict behavior a little better.

Best regards, --Terry

PS: sent a direct message via email just now, on a different subject.

[mhmayyan]

Here is the response of system version:
Board: Catena 4612
Platform-Version: 0.20.1
Arduino-LoRaWAN-Version: 0.8.0
Arduino-LMIC-Version: 3.3.0
MCCIADK-Version: 0.2.2
MCCI-Arduino-BSP-Version: 2.8.0

It was not acceptable to use zero for appkey on V3. I was unable to successfully move my device even after I deleted the device from V2.

[terrillmoore]

It was not acceptable to use zero for appkey on V3. I was unable to successfully move my device even after I deleted the device from V2

Ah -- I mistakenly wrote "appkey"?! I'm sorry, I meant "appeui".

Hm. I've heard that but I've not experienced that. Try an appeui of 0 (in the TTN V3 app) and leave the TTN V2 app as is. If that works for you, then we can work through other steps.

I regret that I was not smart enough to save the RX1 window timing in v0.8.0 of the Arduino-LoRaWAN library. This means that if you restart the device (for any reason), the device will no longer get messages from the TTN V3 network.

Maybe we should talk about your problems and brainstorm the best way to address. We have a number of improvements that are almost ready to deploy; maybe we can make the most of this update cycle.

[mhmayyan]

Hm. I've heard that but I've not experienced that. Try an appeui of 0 (in the TTN V3 app) and leave the TTN V2 app as is. If that works for you, then we can work through other steps.

I tried an appeui of 0 in the TTN V3 app but I already deleted my device on V2. That didn't work for me either.