subsys/mgmt: Add UDP transport for SMP

[aunsbjerg]

This makes it possible to perform mcumgr operation like DFU over ethernet instead of bluetooth or serial. The mcumgr tool already has support for UDP transport.

[carlescufi]

@aunsbjerg thanks for the PR!
I will let @de-nordic and @nvlsianpu decide over this, but would it make sense to target the upstream mcumgr repository for (parts of) this PR?

[zephyrbot]

All checks are passing now.

checkpatch (informational only, not a failure)

-:1141: WARNING:LINE_SPACING: Missing a blank line after declarations
#1141: FILE: subsys/mgmt/smp_udp.c:31:
+	struct k_thread thread;
+	K_THREAD_STACK_MEMBER(stack, CONFIG_MCUMGR_SMP_UDP_STACK_SIZE);

- total: 0 errors, 1 warnings, 1203 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: Ignored message types: AVOID_EXTERNS BRACES CONFIG_EXPERIMENTAL CONST_STRUCT DATE_TIME FILE_PATH_CHANGES MINMAX NETWORKING_BLOCK_COMMENT_STYLE PRINTK_WITHOUT_KERN_LEVEL SPLIT_STRING VOLATILE

NOTE: If any of the errors are false positives, please report
      them to the maintainers.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[aunsbjerg]

@carlescufi I don't think it's necessary to add anything to upstream mcumgr, as we're basically just adding a transport that's already supported by the mcumgr-cli. I might be wrong though.

[de-nordic]

@aunsbjerg thanks for the PR!
I will let @de-nordic and @nvlsianpu decide over this, but would it make sense to target the upstream mcumgr repository for (parts of) this PR?

The PR only adds transport, similarly to smp_uart, smp_bt sources. The management part is still performed by mcumgr lib. I think that this is the the right place for the code.

[nvlsianpu]

I have been looking at other transport solution as well. This PR is in right place.

[nvlsianpu]

@aunsbjerg Can you become one of code-owner of files you added or modified?

[dbkinder]

+1 for doc change :)

[aunsbjerg]

Thanks for the feedback. I will try and get the changes made during the weekend. I will also update the documentation for the sample and for the subsys in general where applicable.

[carlescufi]

Thanks for the feedback. I will try and get the changes made during the weekend. I will also update the documentation for the sample and for the subsys in general where applicable.

Thanks @aunsbjerg for the PR and the feedback. I think you are right and nothing is required upstream, but I'd like @nvlsianpu and @de-nordic to approve.

[aunsbjerg]

Alright, finally got around to actually reworking this according to feedback.

Sample application is refactored. Common configuration stuff is put into prj.conf and transport specific is put into overlays. Code is separated into main, bt and udp specific stuff. I do not have any nordic boards so I have not been able to test that the bluetooth samples still work. Can someone verify this for me?

I have added myself as codeowner for the smp_udp.c in subsys and for the sample application. It would be nice to have a co-owner for the sample for the bluetooth stuff.

[aunsbjerg]

Updated commits according to feedback from @jukkar
Notably, both ipv4 and ipv6 support can be enabled at the same time or independently of each other.
UDP ipv4 and ipv6 samples have been merged into a single sample.

[jukkar]

Do you need this extra level of configuration? What I mean is that now it is possible to have the device to have IPv6 enabled, but SMP UDP to not support it. Perhaps this is ok, it really depends on the use cases.
For example in networking libs and apps, it is usually enough to just enable IPv6 which then enables IPv6 usage in corresponding lib/app. So usually it is not needed to turn off IPv6 in app if the system globally supports IPv6.

[aunsbjerg]

It's not necessary, but I figured one might want to disable ipv4/ipv6 for SMP independently of the network stack configuration. I can remove these config items and use the network config values instead if that's preferable.

[jukkar]

This is more or less up to you and the use cases. If you have a good use case for it, that is fine. It was just not obvious by looking the patch so wanted to clarify it.

[jukkar]

LGTM

[nvlsianpu]

CONFIG_MCUMGR_CMD_FS_MGMT=y

[aunsbjerg]

See #24444