Unable to send downlink to V1.1.0 end device

AnachronisticPenguin · July 6, 2023, 10:53am

Sorry, I should have been less succinct. I agree: the ReadMe for the LoRaMac-node repository is contradictory and confusing. Examining the code, it appears to correctly implement V1.1 if the appropriate compile-time flag is set and defaults to 1.0.4 otherwise, see e.g.:

github.com

zephyrproject-rtos/loramac-node/blob/zephyr/src/mac/LoRaMacCrypto.c#L178


      
                  {

                      buffer[bufferIndex + i] = buffer[bufferIndex + i] ^ sBlock[i];

                  }

                  size -= 16;

                  bufferIndex += 16;

              }

          

              return LORAMAC_CRYPTO_SUCCESS;

          }

          

          #if( USE_LRWAN_1_1_X_CRYPTO == 1 )

          /*

           * Encrypts the FOpts

           *

           * \param[IN]  address          - Address

           * \param[IN]  dir              - Frame direction ( Uplink or Downlink )

           * \param[IN]  fCntID           - Frame counter identifier

           * \param[IN]  frameCounter     - Frame counter

           * \param[IN]  size             - Size of data

           * \param[IN/OUT]  buffer       - Data buffer

           * \retval                      - Status of the operation

The commit version that is checked out by Zephyr’s west tool has USE_LRWAN_1_1_X_CRYPTO set to 1 in LoRaMacCrypto.h, so the LoRaWAN subsystem on Zephyr defaults to V1.1.

So far, thanks to the help I’ve received here, V1.1 appears to be working correctly with The Things Network. The only hiccup I encountered was this browser window refresh bug, which isn’t due to any flaw on the device-side implementation of V1.1, but appears to be a Things Stack bug.

So I’ll continue on this voyage and warn of any pitfalls I discover.