[JPHutchins]

Warning

LLM Disclosure

This post was authored by claude-opus-5-5 on behalf of @JPHutchins. JP asked me to turn a research note on SMP group 11 into a Zephyr fix for the Bluetooth transport, which emits type where the group specifies id. While fixing it I found a second defect in the neighboring configuration details callback, fixed it in a separate commit, and wrote a test that covers both.

Important

Review copy on the intercreate fork, not the upstream PR. Everything above Review notes is the proposed upstream description, under the title of this PR. Upstream, @thedjnK becomes a live mention.

Fixes both transport management information callbacks of the Bluetooth SMP transport and turns tests/subsys/mgmt/mcumgr/transport_bluetooth from a build-only test into a runtime test that covers them. The callbacks were added in zephyrproject-rtos#119051, which brought Bluetooth support to the transport management group from zephyrproject-rtos#113952.

Details on transport modes (command 7). smp_bt_bridge_modes() writes the mode ID under the key type. The group 11 documentation specifies id, as do the UART, raw UART, shell, dummy and raw dummy transports and the transport_mgmt test, so a client that follows the documentation cannot read the mode ID of a Bluetooth device.

Details on transport configuration (command 8). smp_bt_bridge_config_details() returns MGMT_RETURN_CHECK(ok) from a function that returns bool, which is false on success, and never writes *rc. transport_mgmt_config_details() therefore returns its uninitialized rc and leaves the configs list unterminated. The callback also ignored the requested mode. It now sets *rc, returns the encode status, and rejects modes other than 0 with TRANSPORT_MGMT_ERR_INVALID_MODE, as the other transports do.

Transport management is experimental and 4.5.0 is not tagged yet (VERSION is 4.4.99), so no release has emitted the type key and there is nothing to stay compatible with.

Found while implementing a client for this group: JPHutchins/smp#73, tracked in JPHutchins/smp#72.

/cc @thedjnK

Testing

west twister -p native_sim -T tests/subsys/mgmt/mcumgr/transport_bluetooth, with the test from this PR and smp_bt.c from each point in the series:

smp_bt.c	test_modes	test_config_details	test_config_details_invalid_mode
main	fail: Expected mode 'id' to be present	fail	fail
mode ID fix	pass	fail	fail
both fixes	pass	pass	pass

• west twister -p native_sim -T tests/subsys/mgmt/mcumgr: 20 of 20 configurations pass before the series, 21 of 21 after; the new one is transport_bluetooth.
• nrf52840dk/nrf52840: built with twister, not run on hardware.
• native_sim/native/64 is not in platform_allow: struct smp_bt_user_data holds a pointer and does not fit the Bluetooth default of 8 bytes for CONFIG_MCUMGR_TRANSPORT_NETBUF_USER_DATA_SIZE on 64-bit hosts.
• checkpatch, Gitlint, YAMLLint and KeepSorted pass. ClangFormat suggests reflowing the one-call-per-line zcbor chains; they are kept in the style of the surrounding code.

---

Review notes

Not part of the upstream description.

• Scope. The handoff covered only the type key (commit 1). Commit 2 fixes smp_bt_bridge_config_details(), which I found in the neighboring code while fixing commit 1: same file, same origin PR, same maintainer, so it is in this PR as its own commit. It can be split into a separate PR; the two config details tests in commit 3 would move with it.
• Trailers. Every commit has Assisted-by: Claude:claude-opus-5-5 and your Signed-off-by, added with git commit -s as you authorized. No Co-authored-by.
• Handoff corrections. Bluetooth support came from mgmt: mcumgr: transport: smp_bt: Add support for transport mgmt zephyrproject-rtos/zephyr#119051 (merged 2026-09-19), not mgmt: mcumgr: grp: Add initial transport mgmt implementation zephyrproject-rtos/zephyr#113952, which added the group. The handoff's claim that the Bluetooth PR "missed the batch where the key was settled" has no support in the review threads of either PR, so it is left out.
• LLM disclosure. AGENTS.md asks for no mention of AI tools in PR bodies beyond Assisted-by. I followed your disclosure rule, as on lib: notify: fix C23 incompatible function pointer types zephyrproject-rtos/zephyr#115691.
• Upstream plan.
  1. Rebase onto current main. It is 149 commits ahead of ic/main, none of them under mcumgr.
  2. Rerun the tests, push to JPHutchins/zephyr, and open the PR with the description above.
  3. You have READ permission upstream, so --add-reviewer thedjnK will probably be refused. The /cc is the fallback, and the assignment bot adds nordicjm (the MCU Manager maintainer, the same person) anyway.
  4. No upstream issue: nothing needs a backport, since group 11 is not on any release branch.

Also noticed, not changed

Candidates for issues or follow-up PRs:

• Peripheral-only link failure. With CONFIG_MCUMGR_TRANSPORT_BT=y and CONFIG_MCUMGR_GRP_TRANSPORT=y but no CONFIG_BT_CENTRAL/CONFIG_BT_GATT_CLIENT, the link fails with undefined bt_gatt_discover, bt_gatt_subscribe, bt_conn_le_create and bt_gatt_write_without_response_cb. The outgoing bridge code in smp_bt.c is compiled under CONFIG_MCUMGR_GRP_TRANSPORT alone, and no Kconfig dependency prevents that configuration. Reproduced on native_sim with -DCONFIG_BT=y -DCONFIG_BT_PERIPHERAL=y -DCONFIG_MCUMGR_TRANSPORT_BT=y on the transport_mgmt test.
• 64-bit user data. MCUMGR_TRANSPORT_NETBUF_MIN_USER_DATA_SIZE defaults to 8 for Bluetooth, but struct smp_bt_user_data is 16 bytes with 64-bit pointers. The Bluetooth transport therefore fails its BUILD_ASSERT on native_sim/native/64 with default settings.
• Map bound. smp_bt_bridge_modes() opens its map with a bound of 2 for 4 pairs. The other transports use the pair count; Copilot flagged the same mismatch in the mgmt: mcumgr: grp: Add initial transport mgmt implementation zephyrproject-rtos/zephyr#113952 review. It is harmless with the current zcbor, because the bound only reserves header width and 2 and 4 both encode in one byte, so it is left alone.
• Docs table (from the handoff, verified). The group ID table in doc/services/device_mgmt/smp_protocol.rst lists groups 0–9, 63 and 64. Groups 10 and 11 appear only in the toctree.

[JPHutchins]

LGTM