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

**URL:** <https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328>\
**Category:** LoRaWAN Discussions\
**Created:** [February 12, 2020, 3:56pm UTC](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328 "2020-02-12T15:56:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kater](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kater/32/44393_2.png) [@Kater](https://www.thethingsnetwork.org/forum/u/Kater)\
**Post date:** [February 12, 2020, 3:56pm UTC](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328/1 "2020-02-12T15:56:26Z")

</div>

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?” 😉 — but this is a bit difficult)

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [February 12, 2020, 4:59pm UTC](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328/2 "2020-02-12T16:59:04Z")

</div>

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`](https://www.thethingsnetwork.org/docs/network/cli/api.html#ttnctl-devices-set) to force TTN to use the details of the old device, like:

```nohighlight
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>

```

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [February 12, 2020, 5:11pm UTC](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328/3 "2020-02-12T17:11:55Z")

</div>

…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](https://www.thethingsnetwork.org/forum/t/adr-fair-use-and-lmic/10037/6), 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.)

---

<div class="post-metadata">

**Author:** ![Kater](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kater/32/44393_2.png) [@Kater](https://www.thethingsnetwork.org/forum/u/Kater)\
**Post date:** [February 12, 2020, 5:22pm UTC](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328/4 "2020-02-12T17:22:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [February 12, 2020, 5:42pm UTC](https://www.thethingsnetwork.org/forum/t/node-credentials-accidentally-invalidated-any-possibility-to-force-re-join/34328/5 "2020-02-12T17:42:36Z")

</div>

> [@Kater](#):
>
> 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.

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](https://lora-alliance.org/sites/default/files/2018-05/lorawan1_0_2-20161012_1398_1.pdf#page=17):

> 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.
