All Zero App/JoinEUI fails on various MACs

[descartes]

Summary

Forum reports come in regularly with outright join failures using both LMIC and older LoRaMAC-node implementations that fail in some way when the App/JoinEUI (referred to from now on as AppEUI) is all zeros.

As TR007 says that there should always be a real EUI. It is prohibited to make one up although there is an official unoffical scheme which I've ended up facilitating as others can't do the math, see here and forum discussion here.

Whilst I understand the idea behind all zero's, the conflicting advice & actual real world arising issues make this a muddle.

Steps to Reproduce

Read / search the forum, I can supply links if required.

Or try LMIC or an Arduino MKR WAN that has a Murata module on it that runs an older LoRaMAC-node.

What do you see now?

Gateway entries but nothing reaching the application.

What do you want to see instead?

At minimum enough on the console to inform users that all zero's may not work for their device. If they don't have an AppEUI they are likely to be self-build and so are more likely to run in to issues.

A satisfactory outcome & a quick win for all would be to remove the button with a link to the docs on what to do - if you are setting up a self-build device, hand entering all zero's isn't a huge ask.

Ideally remove the all zero's button and replace with a Generate button. Take the EUI from the application's pool, or a user pool for AppEUI's. If the generate button is used again it uses the same EUI allocated to that application. But I'd be hard pressed to justify the engineering effort.

If the All Zeros button remains, we'd need something in the docs to reconcile the TR007 recommendations vs the button vs it not working.

Environment

TTS

How do you propose to implement this?

Sorry, can't

How do you propose to test this?

I can test / validate LMIC and the MKR WAN and current LoRaMAC-node if absolutely necessary

Can you do this yourself and submit a Pull Request?

Sorry, no

[johanstokking]

As TR007 says that there should always be a real EUI.

It doesn't say that the JoinEUI must be non-zero. If one follows TR007, the device maker issues the JoinEUI from a IEEE MAC block, ideally an OUI / MAC-L block, to refer to a Join Server. When registering devices local to the cluster (the current situation in TTSCE), there's no point in setting a JoinEUI so we allow an empty value. We did that to avoid the other situations described in TR007, namely random JoinEUIs or JoinEUIs that do not belong to a MAC block controlled by the device maker or the Join Server, which is worse than an empty JoinEUI.

We are addressing this.

Groundwork was done in #4840
Console support will be added as part of #4847 (see 3.ii.a specifically).

[johanstokking]

Duplicate of #4847 (see 3.ii.a)

[descartes]

All zeros seems not be an official EUI to some, but interpretation of TR007 aside, the problem still exists.

Will the new onboarding at some level that will mitigate the issue arrive in Q1 as suggested?

Is there a road map so mere mortals can keep track of what's coming. A DCS that allows small scale device creators to pre-populate devices in to the TTI infrastructure would be excellent. I've experimented with adding them to TTN & setting claim codes which is OK but that doesn't appear to work for TTI instances.