Broken multicast support (McRootKey is always generated based on LoRaWAN version 1.1.0 scheme)

TheThingsIndustries / generic-node-se

Generic Node Sensor Edition

https://www.genericnode.com

Other

110 stars 31 forks source link

Broken multicast support (McRootKey is always generated based on LoRaWAN version 1.1.0 scheme) #196

Closed elsalahy closed 3 years ago

elsalahy commented 3 years ago

Summary:

Our current LoRaWAN stack generates the MC keys based on 1.1 even when configured for 1.0.3

This is a mirror of an already fixed issue on LMN version 4.4.5

https://github.com/Lora-net/LoRaMac-node/issues/936

elsalahy commented 3 years ago

@johanstokking we use an ST LoRaWAN stack that is based on LMN v4.4.4

A lot of critical fixes related to FUOTA and LoRaWAN have been done since then as you can see from the changelog

Should I just keep patching our current stack? The issue mentioned above wasted a lot of my effort o debug and identify the root cause.

johanstokking commented 3 years ago

Should I just keep patching our current stack?

What is the alternative? Switch to LMN and add ST support ourselves?

elsalahy commented 3 years ago

What is the alternative? Switch to LMN and add ST support ourselves?

Yes This approach also has it's disadvantages, but it pays out in the long term.

As a short term solution I can keep patching the current ST version until they fix it them selves.

johanstokking commented 3 years ago

What is the balance in terms of effort between to these two approaches?

Take vanilla LMN and add ST support
Take ST LMN and patch upstream changes

elsalahy commented 3 years ago

Considering the overall effort (certification, fixes, testing)

Take vanilla LMN and add ST support

Medium effort (since the HW is constant)
Suitable as a long term solution
ST and Semtech do this, but their release cycles are long (it's not our job to do this)

Take ST LMN and patch upstream changes

High effort (since the FW changes are rapid and ST changes cause upstream conflicts)
Suitable as a short term solution and effort can be be minimized by doing targeted fixes.
We will end-up with our own stack fork.

I'm currently continuing with the patching route until we settle on different strategy.

johanstokking commented 3 years ago

OK, then I'm in favor of going with taking the vanilla LMN and add ST support.

Until, of course, ST publishes a stable version that covers our use cases. I don't see this happening in the short term, especially not with LoRaWAN 1.0.4 and 1.1.1 coming up.

elsalahy commented 3 years ago

Thanks @johanstokking. I will plan this accordingly.