Storage of LoRaWAN credentials, secrets, nonces and counters

[ropg]

Hi all,

I'm playing with LoRaWAN and RadioLib on ESP32. I'm new to both LoRaWAN and RadioLib, so please correct me if I'm getting anything wrong.

It seems to me that RadioLib writes the credentials, keys, nonces and counters to EEPROM, which on the ESP32 is emulated by writing them as a blob to an NVS key-value in flash. Actual EEPROMs, e.g. on PIC chips, typically guarantee a million write cycles, where SPI flash is anywhere between 10k and 100k writes, with stories of multiple orders of magnitude less if the temperature goes up, such as might happen in a sun-exposed device. If I want to wake up for a measurement every hour, even 10k writes means a device lifetime of around one year.

The ESP32 has 8kB of very low-power RAM in the real time clock that is kept alive during deep sleep, and I think that would be a much better place for the ephemeral stuff: the long-term secrets (joinEUI, devEUI, appKey, nwkKey) can be in flash and it's OK to send a new join message every time the battery is replaced.

I guess one could replace EEPROM.[c|h] code with a version that stores in RTC RAM, which would have the added benefit of being useful outside of RadioLib. But maybe it is cleaner and useful on more platforms if in addition to the option of using EEPROM.h, LoRaWANNode had something like getStateData(uint8_t *data, size_t *len) and putStateData(uint8_t *data, size_t len) for a blob that the user can get and store wherever before sleeping and put back before calling join() after waking up again.

[michapr]

Hi,
maybe this can help to undderstand it:

see: #963
(about EEPROM lifetime and save method)

From LoRaWan 1.1.0 the counter value should be saved, or you must wait until the counter value will be reached again.
You will find here in discussions many about this.

As sample you can save every 30 minutes the session what will save number of write cycles (if you think it is critical for your application).
In this case maybe you must wait 30 minutes until next values will be received from your device.

Michael

[ropg]

Now I could be totally wrong about the below, and please correct me if this is the case. However:

The way I look at the code, there is indeed all sorts of cleverness happening in LoRaWANNode::saveFcntUp() to make sure that only one byte in a block of bytes changes such that a change in FCntUp is effectively smeared out over multiple bytes. Bytes written are then passed via mod->hal->setPersistentParameter and ArduinoHal::writePersistentStorage to EEPROMClass::write, which handles checking if a byte changed, and only marks _dirty and writes when the byte changed. So far, so good.

Then however, on the ESP32, this emulated EEPROM is actually just a binary blob that lives in a key called 'eeprom' in NVS non-volatile key-value storage. So when ArduinoHal::writePersistentStorage calls EEPROM.commit(), what actually happens is that the ESP32's Arduino "Preferences" code in turn calls Espressif's nvs's nvs_set_blob for the entire "EEPROM". This leads to a convoluted process of marking the old copy of the entire 'eeprom' blob deleted, and adding a new one to whatever is now the active block. There is wear leveling at this level, the details are here, but it all depends on how big the nvs partitition is vs the size of the EEPROM modulated by how binary blobs are written to 32 byte chunks inside the bigger flash sectors.

Unless I am seeing this wrong (which is wholly possible) the clever FCntUp wear-levelling mechanism is clever on top of an abstraction, has never worked as intended on ESP32 and any devices relying on it are potentially dying faster than planned. The impact could be not-so-bad if the nvs flash region is big enough to hold lots of copies of the entire EEPROM before it needs erasing, but that still means that on ESP32 the saveFcntUp()-trick is null and void, because writing it straight-out would lead to the same amount of flash writing.

If I am wrong I am terribly sorry for wasting whoever looks at this next's time. If I am right, this should probably become an issue. And I still think the ephemeral data should live in the RTC RAM.

• (Even just storing FCntUp as a single value in nvs instead of using the EEPROM abstraction would be an improvement as we're writing fewer nvs 32-byte blocks per send.)

[jgromes]

@ropg I would like to point out that all this is specific to ESP32, which isn't the only platform that emulates EEPROM/persistent storage by using flash (at least RP2040 does that too), and is just one of the platforms supported (albeit a popular one) . If there is some other memory in the ESP32 that can be exploited for this (i.e. is persistent and large enough), is available in the Arduino core and is available for all ESP32 variants, it the can be implemented for ESP32 instead of using the emulated EEPROM.

cc @StevenCellist as the author of most of the LoRaWAN code, including the wear leveling mechanism.

[ropg]

There's a few options, I guess:

1. Make a version of EEPROM.[h|cpp] that uses the RTC RAM. Although this would be fairly straightforward, getting that hooked into the existing code may take some time. Using RTC RAM will always have the disadvantage that the data is gone in case of power-loss or reset, so it's really only good for people that use deep sleep. Probably would be nice to give people some option to use the flash EEPROM emulation instead.
2. The getStateData(uint8_t *data, size_t *len) and putStateData(uint8_t *data, size_t len) functions I proposed in the original post at the top here would give maximum flexibility to all users to stick the persistent data wherever they please, but is kind of non-granular since you don't know what's actually changed in the blob you get.
3. Maybe the same can be accomplished in bits and pieces if there are gets and puts for all the individual bits of data. Ideally (maybe, wtf do I know, I just arrived in LoRaWAN-land) one would store the persistent stuff as individual Preferences.h / NVS keys together with the medium-term stuff and then really only have the FCntUp in RTC RAM?

By the way: You can store any variable you want in RTC RAM by simply marking them RTC_DATA_ATTR and poof, they survive deep sleep.

Here's a bit more to better understand what the impact of the problem is in the real world:

Based on quick reading, I think the typical nvs partition is 0x6000 = 24 kB, consisting of 6 x 4kB pages, in which the nvs values live in 32 byte chunks that each have an 'erased' flag. Since the EEPROM blob is 448 bytes, that would be 14 chunks, except the name of the key is also there, so I am assuming 15 chunks. That means we're getting 8 of these in a page, so 8 x 6 = 48 writes before we start erasing, and then one block erase per 8 saves.

And coming at us from the other side: the net is full of people claiming these 10-100k writes are completely illusory because inside the module is never going to be 20 degrees (what they spec at). Some people report a few thousand, or much less still if it gets hot (like outdoors in the sun).

So yikes, yeah, impact of all this on ESP32 is (sadly) real.

[StevenCellist]

Currently sick in bed and zero interest in reading up on the EEPROM implementation for the foreseeable future. Although your description vaguely rings a bell in the mists of my brain.
Maybe we can provide a means like you mention to allow plugging in RTC somewhat easy - or just recommend peeps to add an external FRAM chip for a few bucks if they really want to build products to the full LW v1.1 spec.

[ropg]

Hi Steven,

Understood, get well soon. I'll continue thinking a bit, will keep what I learn and think of in this thread.

[ropg]

Sometimes the simplest solution is eluding you...

So if we just mark all the persistent data as RTC_DATA_ATTR, we are already magically done, right ?

And then if people still call saveSession() because they want to survive reset/powerdown, we can, on ESP32 only, write the data as separate values to Preferences / nvs instead of to EEPROM so we write only 1 x 32-byte block instead of 15 when an item changes.

[HeadBoffin]

Sometimes the simplest solution is eluding you...

Ouch!

As above, RadioLib runs over a number of MCU types. We don't (yet) support flash save for SAMD (something that Semtech notes and has arbitrarily dropped support for SAMR34 on LoRaMAC-node), but this is not an issue for me as "deep" sleep still keeps RAM intact. Whereas RP2040 has no concept of low power sleep. AVR & ST has great low power sleep. Mostly the various other LW libraries just deep sleep which is fine for a deployed device which have a one time join and crack on with uplinks. This is not so great for development but that's resolved with turning off DevNonces on TTN or pressing the clear button on Chirpstack. These are the platforms I tend to use, ESP32 I've only really used for WiFi & BLE solutions thus far. But fundamentally, RadioLib is far more than LoRaWAN, so warping the library to fit its requirements on ESP32 isn't appropriate.

There are a fair few nuances to the above depending on if you are deploying a monitor for your greenhouse or designing a product to be deployed in the 1,000's with varying degrees of backend management as well as the device config.

Looking at the IDF link you provided I think the persistent store option is at least a two pints (of beer) read but at first glance there do appear to be details we weren't aware of in the underlying ESP flash implementation.

Your experience & expertise with M5Stack will be very helpful with figuring out a design but please consider that it's not all about ESP32 and LoRaWAN has to be a good RadioLib citizen.

[ropg]

I'm now testing a very simple and generic ESP32_RTC_EEPROM.[cpp|h], which for ESP32 can slot right into where EEPROM now sits, as that seems really the way to keep things simple as far as the RadioLib code is concerned.

It would be nice to somehow give ESP32 users the option to choose between flash save/restore, which will load/save the parameters to individual ESP32 nvs keys (so that's already 15x better in terms of flash wear than what we have) and using the RTC RAM via ESP32_RTC_EEPROM. That's really not all that hard, it's essentially just two functions with getting and putting from nvs. I think it would be quite clean if some #ifdefs would create ESP32-only saveSession(bool toFlash=false) and restore(bool fromFlash=false).

I'm aware that RadioLib runs on more than ESP32, and will try to make things as simple and clean as I can, keeping any special-sauce well-insulated from the rest of the code.

[michapr]

@HeadBoffin - yes, of course you are right.
But anyway any optimization to increase the life cycle of the ESP32 (as sample Heltec devices) would be nice ;)
And that after power reset the FCntUp should be restored for stable work I know (there is no way I know of to bypass this through settings without additional reset anything in TTN/Chirpstack interface, correct?)

So I think it could be a good idea for ESP processors save the session as RTC_DATA_ATTR (@ropg) and the FCntUp (maybe also FcntDown - not sure...) in EEPROM (NVS) using saveSession(). If saving less parameters in EEPROM we could make more different positions in cycle (as @StevenCellist explained in other posts) - if this make sense in NVS (also not sure...).

Could this be possible, or I'm wrong?

[ropg]

Alright, ESP_RTC_EEPROM exists (🎉 🥳) and is tested now. I made it its own library complete with example for others to use, naturally we should not depend and just copy the files to utils/ in RadioLib.

Plugging this in for ESP32 is easy, but that means people have no means of saving to flash anymore. Any opinions on whether to do that or continue writing to give both options and only submit that? And if we were to have both options, which should be the default?

[ropg]

I'd be happy to add the nvs flash option, but if everyone agrees that all serious use of LoRaWAN will include deep sleep, then adding it as the only option means we're essentially done. Which would be fine by me also...

[ropg]

Another thought: it's super easy to make a flash write that has exactly the same impact as what we do now: just save to RTC RAM and then write a RADIOLIB_HAL_PERSISTENT_STORAGE_SIZE-byte binary blob to NVS from EEPROM.getDataPtr().

[StevenCellist]

I personally think it would be a nice addition to give options for RTC memory to those that want to use it. Personally, I'd prefer it to be used in the following way:

• keep EEPROM the default (I hope to investigate if it's better to remove the implemented wear-levelling)
• don't use RTC RAM as an actual replacement by name, which is prone to confusion and errors
• make it clear to users that it is recommended to use RTC RAM for ESP32-based products
• always save keys and Nonces to EEPROM, never to RTC RAM

As LW v1.1 expects full persistence, and especially during development a board is likely to reset quite often, EEPROM should IMO be the default. It also helps users in finding out if their EEPROM works from the start. Once a board is ready to be put in the wild, a user would switch saveSession() to use RTC RAM (and maybe save once every e.g. 100 uplinks to EEPROM?).

Also, EEPROM is still an actual Arduino Library, not bound to the ESP32 only. Preferences may have a better implementation for ESP32, but any platform-independence is welcome and the effects of sub-optimal implementation is less problematic if RTC RAM is available.

[ropg]

Yes, but when is sometimes? Does it do any good to do it more often than every time after a successful join? If so, how often?

[michapr]

Yes, but when is sometimes?

User should know it... if I can wait for max 60 minutes for new values and have a cycle time of 5 minutes, then I should save every 12 cycles - as sample....

[ropg]

Not sure I understand. How would recovery work in that scenario if I have the state from an hour ago?

There's FCntUp, that needs to be saved every time, which we don't want to do. If we lose it, we will always need to rejoin, for which there's join nonces and dev nonces. (Or are they the same thing?).

Just for my understanding: what does below checkbox do and what does the button do, exactly?

(My apologies for being a bit of a LoRaWAN noob...)

[michapr]

I'm also still not the "LoRaWan specialist" ... but what I have seen is, that if the FCntUp will reach the old value again then the next transmission will be ok.
That's why I think it could make sense to save the old session - and then "wait" until the FCntUp will be valid again.
This was working for my tests here.

The "reset" (as far as I have seen) will help for new joins only.

Maybe somebody from the specialists can confirm it? ;) (Sorry,... but I'm also more or less a LoRaWan "beginner" ... :)) )

[StevenCellist]

There are documents detailing all this stuff, but let's keep it a bit productive; here is a short version:
The LW v1.1 (and v1.0.4) discern (not really, but implicitly) two parts of a device's memory:

• The keys and nonces (KN for short)
• The active session or state

Whenever a Join-Request is transmitted by the device, the device increases its DevNonce. A Join-Accept is only issued by the LNS if (it hears the Join-Request, and if) the DevNonce is strictly larger than the last-heard DevNonce from an earlier Join-Request. The Join-Accept issued by the LNS includes a JoinNonce - the device can only accept this if this value is strictly larger than the last heard JoinNonce.

Whenever a Join-Accept is received, a new session is initiated, with all counters set to 0 (FcntUp, NFcntDown, AFcntDown). Whenever an uplink is sent, the FcntUp is increased by one - an uplink is only accepted by the LNS if the FcntUp is strictly larger than the last-heard value.
If a device were to lose its DevNonce, it would have to send more and more Join-Requests during its lifetime (unless you check that box indeed, which is bad practice outside of development purposes).

So, the KN part should really be saved to EEPROM if there is any available. The KN are only written on a successful uplink, just as it now happens in the final part of beginOTAA() (and by extent in beginABP(), but that is a bit of a different story). The session can be lost, as long as it does not happen too often (read: at most once a month). Therefore, the session should be OK to store in RTC.

Regarding the FcntUp 'when to save' - if you were to send every 5 minutes and save the session to EEPROM every 12 uplinks, you would be at most 12 uplinks behind after an EEPROM restore after a battery swap or reboot. Losing an hour worth of data usually isn't the most time critical thing for battery powered devices running LoRaWAN - if you need more reliability, you shouldn't be using LoRaWAN. So there are some trade-offs that can be explained to users as to when & how often.
There are a few more nuances w.r.t. MAC state (what should you do when a MAC downlink has occurred within those last few 'lost' uplinks), but now there's more context.

[HeadBoffin]

Love the love-in everyone, but we run the risk of ending up in LoRaMAC-node land with its inscrutable NVM saving functions that then have to shell out to a HAL. LoRaWAN in bulk deployment benefits from some considerable consideration & documentation if your devices aren't at the bottom of your garden. For testing on your desk you don't need to trouble the airwaves because it's a closed spec and there is no need to run the radio. Once you have everything working you can then turn the stack back on.

ESP32 has always been the odd-one-out with it's deep sleep being the equivalent of a power down and LMIC wasn't really designed to fish the session out of memory to store so it's taken a considerable amount of time for various peeps to come up with their take on how to do it for ESP32, if you happen to need two cores at 240MHz for taking the temperature of something. And not having a pop at ESP32, but mostly this is an ESP32 problem, other devices sleep at the same level as the ESP32 deep sleep but retain RAM.

I strongly recommend people bake their own solutions and then @jgromes can arbitrate over what's best for RadioLib vs having either something in the wiki or something somewhere else. The LW specs are great bedtime reading if you suffer from insomnia but are actually quite pithy, so those that haven't read it yet are strongly urged to do so so that we all realise what sort of swamp we are creating for users, many of which aren't going to want to get in to these weeds.

From experience of supporting developer, lost uplinks due to f_cnt issues are some sort of disaster, so really do need saving, particularly for those uplinking every 12 hours where it could be a few days before they know if the device is lost or not.

[ropg]

I think I have just built the best solution because it leaves RadioLib essentially untouched.

My ESP32_RTC_EEPROM now has two new functions: toNVS() and fromNVS(). When it recognizes that it woke up empty, it calls fromNVS() automatically to see if there's a saved copy. So all the user needs to do when he/she wants to save to NVS is say EEPROM.toNVS(), everything else is fully automatic. The full, complete, entire patch to existing RadioLib code is literally just:

-  #include <EEPROM.h>
+    #if defined(RADIOLIB_ESP32)
+      #include "utils/ESP32_RTC_EEPROM.h"
+    #else
+      #include <EEPROM.h>
+    #endif

and adding the two files to utils/

[michapr]

Where is it located? Would like to have a look at it ;) (in your GitHub link is not the latest version ;) )

Have you included the session save to EEPROM?

[ropg]

v0.2.0 has these functions and is released. Check the example, it saves to flash every 10 boots.

[michapr]

Already have seen ;)

Looks nice and easy to use, great job!
Will test it tomorrow with my Heltec devices.

You have modified the ArduinoHal.cpp file and replaced the #include <EEPROM.h> here?

[jgromes]

Thanks everyone for the discussion, I really appreciate it. After a bit of catching up, I think there are essentially two options:

1. On ESP32, use RTC RAM instead of EEPROM for the persistent variables that change often (more than once every 10 uplinks, let's say), especially the counters. The advantage is less wear on the ESP32 flash which is desirable, since it's a rather popular device. The disadvantage is that it adds some more platform-dependent code to RadioLib. I'm not saying it's a no-go, in fact precedents do exist for the ESP32 (e.g. tone), but it should be kept in mind. It's also not what this library is supposed to be doing - I had a feeling when writing the very first persistent memory stuff to RadioLib that I was opening a can of worms ...
2. We offload this to the user. Keep the current implementation as-is, and provide methods (as @ropg proposed in the original post) to save the session state or even the keys in a persistent storage of their choosing, be it an external FRAM, EEPROM or an 8-inch floppy. In theory this can be done already if the user were to write their own HAL that just overrides the methods for persistent memory management and inherits the rest from Arduino HAL, but it's not very practical. This would allow the user to do their own tradeoff of persistent memory degradation against the risk of losing counters.

Currently I lean more in favor of the second approach, because it's more generic, and it still allows ESP32 RTC RAM to be used.

[jgromes]

And of course, hoping that you get well soon @StevenCellist :)

[StevenCellist]

@jgromes thank you!

I agree with you that the second one is favourable in light of RadioLib. As there is a wiki upcoming, we can expand the already planned dedicated page on this topic to include some plug-and-play functionality to use the RTC memory.
Possibly we can add a function into the stack that works only in combination with user-enabled external memory (to save a session to e.g. RTC) - which fails unless overriden by the user.. sort of middle ground?

[HeadBoffin]

I'm with the second option as well - with the RTC save there is no need to lose counters but we run the risk of, as above, entering the LoRaMAC-node NVM zone - which BTW, I mostly disable as it is a complication that ST haven't quite got working as well as the original design (the secret unpublished one) implies.

[ropg]

OK. I'm not making it into a PR just yet because I'd like to hear what y'all think, but please check out my RadioLib fork. It has a few small diffs in LoRaWAN.cpp, LoRaWAN.h and ArduinoHal.cpp, under 30 lines added in total. Then it adds my ESP32_RTC_EEPROM.[cpp|h].

In the new example LoRaWAN_ESP32_Deep_Sleep, I only save to NVS after each successful join, and to RTC RAM otherwise. It is robust as hell in that the uplink packets arrive, and when I reset (thus clearing RTC RAM and reverting to what's in NVS) I see a new join and things continue as normal. I have not enabled 'Resets join nonces' or hit 'Reset used DevNonces' here.

[ropg]

Note that this still saves the "EEPROM" contents to NVS as a blob, so for someone that opts to saveSessionToNVS() every round, this does exactly what we had before. We could be doing 15 times better by saving the individual values to NVS, but it's more work. I think this might suffice.

[ropg]

Still tinkering. Don't test my version just yet, it's getting better, and possibly simpler, still.

[HeadBoffin]

under 30 lines added in total.

I trust you don't suffer from size anxiety ;-)

It is robust as hell in that the uplink packets arrive

Can I steal that phrase for the next client project review?

Don't test my version just yet

I'm not clear on what you do for a living, but please be aware that the rest of us have work other than this and we have/had a general plan for the LW dev which right now is getting the examples updated and a first pass on the wiki. My PIO remote test setup has two ESP32 boards attached but the changes require lots of interaction rather than a soak test. And Steven is currently re-learning to eat again.

So if we take a few days to test, please take this in to consideration. With current workloads it would be preferable to test a release version rather than an in-progress one.

[ropg]

As you can see, I have just filed PR #1002 which adds the functionality described above. I understand you take time to test features, I just happened to have some time on my hands and as I'd like to use deep sleep without burning devices, this clearly needed fixing. I hope I have honored the concerns of y'all by dealing with the ESP32-specific issues as much outside of the existing RadioLib code as possible.

I will continue testing also, so far everything seems stable and resilient against resets while only writing to flash very occasionally. I'd be happy to hear (in due time) what you think of the choices I made in implementing this. I'll close this thread now, but we can continue discussing (at a much slower and more deliberate pace) at the PR.

[ropg]

I seem to recall that at this point multiple times it has been mentioned that we run different schedules, none of which is in a hurry

The ;-) smiley was there for a reason.

But all in all, I think that we are coming closer to a solution that will fit in the long term.

Yay!

[HeadBoffin]

You can't solve this and not change RadioLib

No one said that RadioLib wouldn't need changing. It's how it's changed that needs a more complete & long term solution rather than a whirlwind of activity.

• Yet, on the other hand, every single user of LoRaWAN will need to store their persistent state

Nope, spec ≠ reality and all across the maker community on TTN the ESP32 is called out as not being suitable for sleeping. This will change that, which is overall a good thing.

The LoRaWAN world is not ESP32 shaped - mostly it is STM32 + SX1276 shaped in a variety of combos, mostly Murata, with makers previously using ATmega328 + SX1276 until LMIC crossed the threshold of being easy to put on a diet to allow some space for sensor code - whilst the AVR is lacking in internal blocks, it still did the job (still does if you know how to put it on a diet, or get an ATmega4808 board). RadioLib addresses the gap that the ATmega328 leaves by providing an Arduino environment on relatively affordable & obtainable ESP32 boards - even more affordable if plans come to pass either ESP32 or getting RadioLib running not the STM32WL5JC modules like the Seeed LoRa-E5. Which is why having it external makes more sense as it is only ESP32 that needs to burn info in to flash, everything else can sleep at the same power level without turning off SRAM, so no need to burden RadioLib with code that targets one MCU for one protocol.

[HeadBoffin]

because the persistent connection that is now required leaves you no choice but to cache the session.

Sorry, but it just doesn't for most of the platforms, just if you want to use the lowest power sleep on an ESP32.

Pushing to make this wonderful for one platform without consideration of the impact on other platforms is doing all the users of other platforms a disservice.

[ropg]

I probably don't follow. What do you mean by "impact on other platforms" ?

[michapr]

@HeadBoffin

Sorry, but it just doesn't for most of the platforms, just if you want to use the lowest power sleep on an ESP32.

I thought we are speaking here about the ESP devices ;) ... there are many ESP LoRa devices on market - and yes, an lot of (maybe most) IoT devices are working in deep sleep mode with battery

because the persistent connection that is now required leaves you no choice but to cache the session.

Sorry, but it just doesn't for most of the platforms

How a power loss (battery change etc.) can solved at other platforms without saving sessions? The goal is ultimately to have self-healing systems... Maybe I'm wrong, but I have no idea how it could work.

But of course you are right, the RadioLib is much more than LoRa and it cannot be the task to offer the perfect solution for hardware-specific requirements for every platform.
There is a community that can contribute its knowledge if the interfaces for customization are available.

Again - thanks for your work, greatly appreciate and admire it!

[HeadBoffin]

Clarifications:

Other platforms = other MCU families

@michapr, someone is focused on ESP32 but changes impact all other platforms / MCUs as well. And the reason for less haste is that a good LoRWAN device doesn't lose it's session - it's powered up and about two to seven years later it either gets its batteries changed, so does a second join or is disposed of. So constructing a scheme carefully is rather important. The ONLY reason all of the above occurs is because ESP32 doesn't retain its main RAM in deep sleep, which is why it has not been a recommended platform on the TTN forum.

The existence of support for AVR EEPROM doesn't mean it's a good idea to just add more code. It would be better to leave what's there alone, mark it as deprecated and provide more flexible functionality that can use existing libraries for each MCU.

I can't see this moving forward whilst there is focus on just one MCU type - it may be the one you love, but there are other MCU's and as above, we don't do the library users any favours by not coming up with a plan.

[michapr]

The FCntUp is the counter of uplinks, is reset to 0 after a join and has no impact on joining. It isn't a problem on any MCU.

Ok, this is new for me.
I thought until now, that the value should be the same as before the power down (if I will not check the "non compliant" option "resets the nonces)
In my cases I had to wait until have reached the number of sendings (FCount value) was reached before the sensor could join and send again values. Speaking of course about v.1.1.0

So I have any other problem in my sketches.... (?)

About ESP - saying it is not optimal I was thinking only about the problem with the deep sleep and "forgotten values" - so that it need a special "treatment" in the lib (what you do not like - what I understand)

[StevenCellist]

Currently not much for you to worry about! Saving sessions is all you need to do on the current release to be perfectly compliant. Over the course of the next days/week/smthng, we plan to provide the handles mentioned in #1002 such that we can use the RTC implementation by @ropg - at that point, it will be worth it more to learn how it all works.

[michapr]

@StevenCellist - thanks, yes, I know. I have already implemented and tested the solution from @ropg .

Comment was more about the "strategic way" for the RadioLib, interfaces for special plugins for special MCU etc. - for optimizing solutions for RadioLib - without bothering the RadioLib developers ;)

[ropg]

@michapr Check out latest version of my heltec_esp32_lora_v3 library. Examples work, library (temporarily) contains my fork of RadioLib to do deep sleep without flashing every send. Examples work.

[HeadBoffin]

I thought until now, that the value should be the same as before the power down (if I will not check the "non compliant" option "resets the nonces)

I suspect you are conflating join vs wake. When it joins, FCntUp is set to zero, one of the benefits of OTAA. You mean when you wake after sleep you have ended up with your FCntUp either at zero or lower than the one the LNS has, so sure it then has to send uplinks until it exceeds the one the LNS has - this is a standard part of LW spec security - you would benefit from reading all of https://www.thethingsnetwork.org/docs/lorawan/ - watch the video after you've read the sections but on YouTube where there are bookmarks to stop your brain frying with the pace of delivery.

The current release savages the flash but does in return save FCntUp in the session if you care to use that.

And mostly it will end up an appliance where you can send a byte array and turn it in to coloured charts on demand. But for now, did we mention that RadioLib LW is still in beta?

[HeadBoffin]

With agreement of @StevenCellist, closing as we are repeating & elaborating on something that needs work - best to get the job done and everyone can start with a clean slate.