Signatures don't match when using LoRaWANNode::setBufferSession()

[alistair23]

Describe the bug

LoRaWANNode::setBufferSession() fails with The Session buffer (1601) does not match the Nonces buffer (49f7) when trying to restore data from a buffer.

After a successful connection I can run

internal_nonce_data_buf = node.getBufferNonces();
internal_session_data_buf = node.getBufferSession();

to save the buffers (they are saved in a K/V store).

After a reboot I can then run

node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);

node.setBufferNonces(internal_nonce_data_buf);
node.setBufferSession(internal_session_data_buf);

node.activateOTAA();

but setBufferSession() fails with the error above.

If I comment out the check

  // the Nonces buffer holds a checksum signature - compare this to the signature that is in the session buffer
  uint16_t signatureNonces = LoRaWANNode::ntoh<uint16_t>(&this->bufferNonces[RADIOLIB_LORAWAN_NONCES_SIGNATURE]);
  uint16_t signatureInSession = LoRaWANNode::ntoh<uint16_t>(&persistentBuffer[RADIOLIB_LORAWAN_SESSION_NONCES_SIGNATURE]);
  if(signatureNonces != signatureInSession) {
    RADIOLIB_DEBUG_PROTOCOL_PRINTLN("The Session buffer (%04x) does not match the Nonces buffer (%04x)",
                                    signatureInSession, signatureNonces);
    return(RADIOLIB_ERR_SESSION_DISCARDED);
  }

everything works fine. It kind of looks like the wrong offsets are used to calculate the signatures there, because I don't see how we would expect them to be the same. As the bufferNonces is compared against the bufferSession (that is stored as persistentBuffer).

Debug mode output

[2024-11-22 13:26:36.266] RLB_DBG: 
[2024-11-22 13:26:36.266] RadioLib Info
[2024-11-22 13:26:36.266] Version:  "7.1.0.0"
[2024-11-22 13:26:36.269] Platform: "Generic"
[2024-11-22 13:26:36.272] Compiled: "Nov 22 2024" "13:26:02"
[2024-11-22 13:26:36.287] RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING:
[2024-11-22 13:26:36.291] RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00  SX1261 V2D 2D02.
[2024-11-22 13:26:36.300] RLB_DBG: 
[2024-11-22 13:26:36.300] RLB_DBG: M    SX126x
[2024-11-22 13:26:36.454] Found existing nonce
[2024-11-22 13:26:36.501] Using existing session data
[2024-11-22 13:26:36.501] RLB_PRO: The Session buffer (1601) does not match the Nonces buffer (49f7)
[2024-11-22 13:26:36.509] setBufferSession failed, code -1120

To Reproduce
The entire example is here: https://github.com/alistair23/libtock-c/blob/4e308c9964d9913aa44277ade755aa36913c7eb2/examples/lora/sensor-lorawan/main.cc

Sketch that is causing the module fail

  node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);

  if (retrieve_internal_nonces() == 0) {
    printf("Found existing nonce\n");
    node.setBufferNonces(internal_nonce_data_buf);
  }

  if (retrieve_internal_session() == 0) {
    printf("Using existing session data\n");

    state = node.setBufferSession(internal_session_data_buf);

    if (state != 0) {
      printf("setBufferSession failed, code %d\r\n", state);
      return 1;
    }
  }

  state = node.activateOTAA();

  if (state != RADIOLIB_LORAWAN_NEW_SESSION && state != RADIOLIB_LORAWAN_SESSION_RESTORED) {
    printf("activateOTAA failed, code %d\r\n", state);
    return 1;
  }

  printf("activate success!\r\n");

  set_internal_nonces(node.getBufferNonces());
  set_internal_session(node.getBufferSession());

Expected behavior

I would expect LoRaWANNode::setBufferSession() to complete successfully, as it does if I remove the check.

Additional info (please complete):

• MCU: Tock Apollo3
• Link to Arduino core: N/A
• Wireless module type: SX1261
• Arduino IDE version: N/A
• Library version: 8d119fc

[HeadBoffin]

Noted this issue, will look at it over the weekend as you have a workaround.

I believe the code is there to check that the buffers are from the same Join but it's been a while ...

[StevenCellist]

When I flashed my Wireless Stick Lite v3 I had the same problem (have seen it a few times before as well which on a re-join resolved itself), but when I swapped a couple of lines and added debug, it somehow disappeared. Let's hope that 5d6ca62 was enough of a fix - @alistair23 can you confirm? Otherwise please let it re-join once and see if it wakes up correctly the next time around. Which would be a curious behaviour but actually did solve it for me in the past