search

arduino-libraries / MKRWAN_v2

[Beta] Library for Arduino MKRWAN 1300 / 1310 suitable for firmwares derived from ST sources
GNU Lesser General Public License v3.0
7 stars 6 forks source link

DevEUI before & after firmware update #10

Closed descartes closed 3 years ago

descartes commented 3 years ago

My MKR WAN 1310 arrived with the original 1.2 firmware on the Murata module which gave me the Arduino registered EUI (first three bytes A8:61:0A + sort-of-random based on MCU ID).

Updating using the v2 results in a totally random EUI starting 35:35:31, a prefix that isn’t registered.

The GitHub source shows that the original code to create the original EUI is still in place:

https://github.com/arduino/mkrwan1300-fw/blob/b1c48b27280cb455ebe73f723e4a6cc01854d1f5/Projects/Multi/Applications/LoRa/AT_Slave/src/mlm32l0xx_hw.c#L353

So I suspect that the MKRWANFWUpdate_standalone file in v2 has a generic firmware embedded in it.

Does anyone have a release level with the correct HW_GetUniqueId function embedded?

facchinm commented 3 years ago

Hi @descartes , this version of the library ships with an almost unmodified ST firmware (this is the reference branch https://github.com/arduino/mkrwan1300-fw/tree/master-1.3.1). The EUI is then only generated by the internal unique ID from the STM32L0, without the Arduino OUI prefix.

facchinm commented 3 years ago

(the release with the Arduino prefix is https://github.com/arduino-libraries/MKRWAN) :wink:

descartes commented 3 years ago

The EUI is then only generated by the internal unique ID from the STM32L0, without the Arduino OUI prefix.

I think I evidenced my understanding of this in my original post.

Why have you dropped the Arduino OUI prefix?

It doesn't seem a huge upset to the ST firmware by altering the appropriate function so that users have a proper DevEUI. Or provide us with a DevEUI that we can be assured will be unique.

facchinm commented 3 years ago

One of the biggest issues in using our OUI is that there's no assurance that the final ID will be unique :disappointed: ST only assure the uniqueness if their algorithm is being used (https://github.com/arduino/mkrwan1300-fw/blob/4de6f41c2f36ccf72ad2e2b0793c8e603da23507/Projects/Multi/Applications/LoRa/PingPong/src/mlm32l0xx_hw.c#L214-L224 ) . By changing the first 3 bytes we get a pseudo unique ID that may or may not clash (chance are low but not zero)

descartes commented 3 years ago

OK, I can see that and I know this is a bit harsh, but as you implemented it in the original release but then put us in to a sort of non-official-EUI limbo with this firmware, I think the first scheme is preferable.

A Network Server needs the DevEUI and AppEUI (aka JoinEUI in 1.0.4) to be a unique combination. Not sure how users go about generating the App/JoinEUI - on TTN v2 the console created one for you, on v3 you can enter all 00's - which actually makes the potential clash a reality.

Maybe this could help: https://community.st.com/s/question/0D50X00009XkXbvSAF/lorawan-demo-deveui-is-not-unique

You spend $20,000/year (or less if you were an early adopter and have kept your MA-L) to get the allocation - the risk that two boards on the same Network Server end up with the same DevEUI is much less of a problem than just using some totally random one. Is there any way of making use of it so that makers using the board can be reasonably compliant?