SenseCAP T1000-B how to reset dev_nonce?

Products & Technology SenseCAP
1

My SenseCAP T1000-B sends a dev_nonce of 65535, which means it can’t work reliably. How do I reset the dev_nonce to zero?

I tried a factory reset (in the Android app), I switched between networks (which the manual says resets things), and I changed devEUI. None of these reset the dev_nonce.

A dev_nonce of 65535 means the device is unusable. I can get it to join by resetting the nonces on the server side but then a day later when the T1000 tries to rejoin it reuses the 65535 dev_nonce value and can’t join. That effectively kicks it off the network. Is my T1000 now e-waste?

2

Before considering it as a total waste, I think it’s better to update/re-flash the firmware.

3

If there was any progress on this, please let me know! I have the same issue and so far a firmware upgrade to 2.8 and a reset to factory defaults hasnt changed this.

4

Hi there,

So , it’s NOT really the Case it is to prevent replay attacks.
In LoRaWAN 1.0.4 and 1.1, DevNonce is a strictly incrementing 16-bit counter (0 to 65,535) stored in non-volatile flash memory to prevent replay attacks. Once it reaches 65535 ($2^{16}-1$), the counter is exhausted, and the specification forbids it from rolling over without changing root keys. Because standard OTA firmware updates preserve the non-volatile storage (NVS/flash EEPROM) containing cryptographic state, normal app resets and updates to firmware 2.8 will not clear it.

Here are the practical avenues they can try:

1. Regenerate / Rotate the AppKey on the Device and LNS

  • In LoRaWAN specifications, resetting DevNonce to 0 is explicitly permitted only when the root AppKey changes.

  • If the SenseCAP Mate app or the device’s serial/BLE configuration allows entering or generating a new AppKey, change it on both the tracker and the Network Server (TTN, ChirpStack, or Helium). Many LoRaWAN stacks will zero out the DevNonce counter upon detecting a newly provisioned AppKey.

2. Switch to ABP (Activation by Personalization) Mode

  • If the tracker firmware or configuration tool supports switching the activation mode from OTAA to ABP, do so.

  • ABP bypasses the OTAA join procedure entirely—it uses fixed DevAddr, NwkSKey, and AppSKey, completely eliminating the DevNonce handshake check.

3. Full Flash Wipe via SWD / Serial Debug Header

  • Standard firmware upgrades via BLE/DFU deliberately preserve user flash and security keys.

  • If they can open the tracker enclosure and attach a programmer (e.g., J-Link, DAPLink, or ST-Link depending on whether it uses the Nordic nRF52 or Semtech MCU) to the internal test pads, running a full chip erase (nrfjprog --eraseall or mass erase) will wipe the internal NVS/storage sector completely. Reflashing the factory firmware image onto an erased chip forces DevNonce back to 0.

4. Relax Server-Side DevNonce Tracking (Workaround)

  • On private/self-hosted instances (like ChirpStack), disable strict LoRaWAN 1.0.4 frame nonce checking in the device profile settings.

  • Note that public networks like The Things Network (TTN) enforce LoRaWAN 1.0.4 nonces strictly and will continue to reject join requests once 65535 is reached.
    Try these and report back.

HTH
GL :slight_smile: PJ :v:

5

Please contact our technical support team at [email protected]. We will provide you with a firmware that can clear/reset the DevNonce so the device can join the LoRaWAN network normally again!

1 Like