Consistent end device settings and defaults

[johanstokking]

Summary:

Help CLI and Console users a bit by filling boilerplate for devices.

• Sane defaults, ideally version ids is sufficient
• OTAA with option to generate root keys
• ABP with option to generate a session (with session keys and DevAddr in NetID 0)

Why do we need this?

The CLI and Console would be very unfriendly if (for example) you'd had to generate keys with openssl and then copy-paste them. Better to let the CLI and Console generate those and other boilerplate.

Also, we need a consistent set of defaults in the CLI and Console to avoid user confusion.

What is already there? What do you see now?

The CLI sets some sane defaults; i.e. ADR on, 32-bit frame counters enabled, OTAA by default. See the up-to-date settings in cmd/ttn-lw-cli/commands/end_devices.go.

What is missing? What do you want to see?

• The same defaults as CLI in the Console
• Potentially the NS to generate a DevAddr in the DevAddr range (or NetID)

How do you propose to implement this?

• Document the defaults
• Implement this in CLI and Console, referring to the documentation

---

Original issue: https://github.com/TheThingsIndustries/lorawan-stack/issues/1392 by @htdvisser

[kschiffer]

I could really use this info, as I am momentarily working on devices CRUD. I am wondering what options we should provide in the console when creating devices. From the getting started guide, I see the following options set when creating devices: --device-id, --dev-eui, --join-eui, --application-id, --frequency_plan_id, --root_keys.app_key.key, --lorawan_phy_version, --lorawan_version
So I'd assume that this should be mirrored in the console. Frequency plan, app key and versions should have some prefilled defaults, I guess?
Are there any other options important options to consider for console MVP?

[johanstokking]

@kschiffer great, looking forward to Console support. Please have a look at how the CLI does it; https://github.com/TheThingsNetwork/lorawan-stack/blob/master/cmd/ttn-lw-cli/commands/end_devices.go#L234-L313.

Also, here's how the CLI currently splits fields for components: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/cmd/ttn-lw-cli/commands/end_devices_split.go.

Looping in @rvolosatovs to coordinate consistency for CLI and Console, as well as commenting on NS behavior for defaults as filed in #60.

[rvolosatovs]

In #101 I moved most of NS-related defaults from CLI to NS
Now the only required fields on device creation are these 4:

lorawan-stack/pkg/networkserver/grpc_deviceregistry.go

Lines 62 to 65 in 348ac03

	"frequency_plan_id",
	"lorawan_phy_version",
	"lorawan_version",
	"supports_join",

Of course, besides these 4 there also must be valid Device/Application IDs and Join/Dev EUIs
For the rest, if unspecified, NS will assume a sane default.

Some defaults will be added to cmd/internal package, I will add a reference here once it's done.

The console should not send any "default" settings to NS - only the things that user explicitly chooses(e.g. ADR margin - by default, console should not send anything. I user sets it to X - only then X is sent)

Also, note that in #101 the API for MACSettings changes

[rvolosatovs]

https://github.com/TheThingsNetwork/lorawan-stack/pull/101/files#diff-9f3cf3507ba84739982d861438f9d0fe

[johanstokking]

@rvolosatovs what is the status here and what is the impact for the Console in terms of required fields?

[rvolosatovs]

Required fields for:
a) All devices

lorawan-stack/pkg/networkserver/grpc_deviceregistry.go

Lines 169 to 172 in e35ce50

	"frequency_plan_id",
	"lorawan_phy_version",
	"lorawan_version",
	"supports_join",

b) if supports_class_b == true (Class B device)

lorawan-stack/pkg/networkserver/grpc_deviceregistry.go

Lines 188 to 190 in e35ce50

	"mac_settings.ping_slot_date_rate_index",
	"mac_settings.ping_slot_frequency",
	"mac_settings.ping_slot_periodicity",

c) if supports_join == false || specified(session) (ABP device or OTAA device with existing session)

lorawan-stack/pkg/networkserver/grpc_deviceregistry.go

Lines 209 to 210 in e35ce50

	"session.dev_addr",
	"session.keys.f_nwk_s_int_key.key",

d) if (supports_join == false || specified(session)) && lorawan_version >= 1.1 (LoRaWAN 1.1+ ABP device or OTAA device with existing session)

lorawan-stack/pkg/networkserver/grpc_deviceregistry.go

Lines 222 to 223 in e35ce50

	"session.keys.nwk_s_enc_key.key",
	"session.keys.s_nwk_s_int_key.key",

specified(x) above means that the fieldmask of Set request contains x or any of x children

The resulting set of required fields is a function on the device.
It is a union of a and any combination or none of {b,c,d}

[johanstokking]

@rvolosatovs for completeness can you update your comment with the AS and JS fields?

[kschiffer]

Potentially the NS to generate a DevAddr in the DevAddr range (or NetID)

How would this be obtained using the SDK/console? @johanstokking

[johanstokking]

This would be a new rpc in Ns. Now, the CLI generates one in NetID 0, which is marked experimental. That's fine for now, but it won't support peering.