Node credentials accidentally invalidated, any possibility to force re-join?

LoRaWAN LoRaWAN Discussions
1

Hi, we have one node out in the field which worked well so far. Then, in our lab, we accidentally provisioned another node with the same credentials and let it do a join. This of course invalidated the session keys of the “real” node so we cannot receive data from that node nor send data to it.
Is there any way to force a re-join of the original node? Any other trick?
(I know: “Have you tried turning it off an on again?” :wink: — but this is a bit difficult)

2

If you did not explicitly program anything into the device to force it to magically join again, then there’s no way to do that remotely.

So, you would need to know the previous DevAddr, NwkSKey, AppSKey (as generated during the OTAA join of the old device), and the values for the uplink and downlink frame counters of the old device. If you happen to know all that, then I think you can use ttnctl devices set to force TTN to use the details of the old device, like:

ttnctl devices set <device id> --dev-addr <old DevAddr>
ttnctl devices set <device id> --nwk-s-key <old NwkSKey>
ttnctl devices set <device id> --app-s-key <old AppSKey>
ttnctl devices set <device id> --fcnt-down <old downlink count>
ttnctl devices set <device id> --fcnt-up <old uplink count>
1 Like
3

…or, if it has ADR enabled: maybe your LoRaWAN module or library will re-join when it’s no longer getting ADR downlinks? But even if true, then such might take a long time, given that ADR_ACK_LIMIT and ADR_ACK_DELAY total to 96 messages, after which the module’s first action might be to decrease its data rate (increase its SF) and wait for an ADR downlink again, and so on, until it has no more options left…

(I’ve searched the RN2483 specifications for that some time ago, but failed to find any details.)

1 Like
4

Thanks. I suspected that…¯\_(ツ)_/¯
Unfortunately we did not store the old session keys (of course…).
I think the node software will get a downlink timeout mechanism in the future, i.e. it will (configurably) require a downlink telegram in a certain time interval or otherwise try a rejoin.
We actually do use a RN2483 module here, but the connection was lost several days ago and the node sends a telegram every few minutes.

5

When using ADR, you should already see it having decreased its data rate then? (In the gateway’s Traffic page.)

But ADR is no guarantee that the module will reset, especially not as the LoRaWAN 1.0.2 specifications only require ADRACKReq for SF 11 or lower:

The end-device will further lower its data rate step by step every time ADR_ACK_DELAY is reached. The ADRACKReq shall not be set if the device uses its lowest available data rate because in that case no action can be taken to improve the link range.

…and does not seem to specify what should be done in that case.

1 Like