LoRaWAN: fcntUp wraps after 50 transmissions about radiolib HOT 5 CLOSED

Got it. The node.restoreFcntUp() function was nicely implemented with 'dynamic sizing' of the NVM buffer size which got expanded from 6.3.0 to 6.4.0, but unfortunately I apparently had forgotten to also dynamicalize (inventing new words there) node.saveFcntUp().

If it bothers you personally, the fix is to change lines 818/819 to

  uint8_t fcntBuffStart = mod->hal->getPersistentAddr(RADIOLIB_EEPROM_LORAWAN_FCNT_UP_ID);
  uint8_t fcntBuffEnd = mod->hal->getPersistentAddr(RADIOLIB_EEPROM_LORAWAN_FCNT_UP_ID + 1);
  uint8_t buffSize = fcntBuffEnd - fcntBuffStart;
  #if RADIOLIB_STATIC_ONLY
  uint8_t fcntBuff[RADIOLIB_STATIC_ARRAY_SIZE];
  #else
  uint8_t* fcntBuff = new uint8_t[buffSize];
  #endif

  mod->hal->readPersistentStorage(mod->hal->getPersistentAddr(RADIOLIB_EEPROM_LORAWAN_FCNT_UP_ID), fcntBuff, buffSize);

And modify the two occurrences of simply '30' in the lines 859 & 864 to buffSize.
I will include this fix in a PR later, probably next week.

from radiolib.

@StevenCellist good catch - no, that is not intentional. I guess I never really used god mode to acces private members from PhysicalLayer. I will fix it so that your PR can remain focused on LoRaWAN stuff :)

from radiolib.

I have a suspicion, I will investigate. Good find!

from radiolib.

@StevenCellist thank you so much for your quick investigation! I'll apply your fix locally, looking forward to your PR :)

from radiolib.

Welcome and thank you for digging this out + providing the easy code for me to run. I suspect this also solves behaviour that I thought I dreamt of where some packets went missing, but it may also help in solving #949 which will come clear soon.

@jgromes while debugging this, I noticed that PhysicalLayer.h does not expose its private members upon godmode because of the protected: at its line 491 - is this intentional, or could you move that block to below private?

from radiolib.