search

ArmDeveloperEcosystem / lorawan-library-for-pico

Enable LoRaWAN communications on your Raspberry Pi Pico or any RP2040 based board. 📡
BSD 3-Clause "New" or "Revised" License
139 stars 46 forks source link

Update board.c #5

Closed QINLIMIN closed 3 years ago

QINLIMIN commented 3 years ago

Add "SecurAdd "SecureElementRandomNumber" function for generating DevNonce in Random way. Currently, the code can't increasing DevNonce every reboot due to you didn't add Nvm functions, so we need to set "USE_RANDOM_DEV_NONCE = 1", use random DevNonce every power to avoid conflict. Next step, it's better store the Nvm data to flash.

sandeepmistry commented 3 years ago

Hi @QINLIMIN,

Thank you for the pull request! How were you setting USE_RANDOM_DEV_NONCE to 1 in your testing? Is there a way to do this without modifying the lib/LoRaMac-node source (which is a git submodule)?

For the NVM data in flash I've just opened pull request https://github.com/sandeepmistry/pico-lorawan/pull/6. Please take a look and let me know what you think.

QINLIMIN commented 3 years ago

Hi @sandeepmistry, As we know DevNonce(2 bytes) is one part of join-request message, it cannot be duplicate for a given JoinEUI value at each power cycle. There 2 ways to ensure handle this in LoRaMac-Node,  one is randomly generated a DevNonce from 0 to 65535 when joining, second is increase DevNonce when joining which must store the value to a Non-volatile memory.

Currently, if we want to ensure LoRawan node can be joined successfully without DevNonce conflict, we must use random DevNonce way, due to the code haven't NVM function. It' mean that we need to modify a macro definition in LoRaWan-Node/src/Mac/LoRaMacCrypto.h USE_RANDOM_DEV_NONCE. But actually, this way is not perfect, when the number of join requests increase, the probability of DevNonce conflict will be increased. So it is necessary to complete #6 .

If we don't want to change the source code of LoRaWan-Node, we must create Nvm functions for RP2040. Let it can store the Nvm data in flash. Actually, I also have try to write Nvm function, but currently still have something wrong, still need some debug. Because flash not the same as eeprom, write one bytes to flash, we must erase one sector first, as a result, it is very slow to read and write, I think it will cause some problem.

sandeepmistry commented 3 years ago

@QINLIMIN agreed, let's proceed with either pull request #6 or #7 instead of these proposed changes then.