zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.71k stars 6.54k forks source link

mgmt/mcumgr/lib: RFC: SMP Command pass-through #44224

Open de-nordic opened 2 years ago

de-nordic commented 2 years ago

Is your feature request related to a problem? Please describe. SMP commands can now only be targeted by a device that is directly connected to transport, and if user wants to send a SMP request to a device that is not directly connected to the transport, but is connected to a device that is, the user needs to establish tunnel like solution from the point of contact with mcumgr client software to target device. This can be done in various ways like using additional UART, when UART is transport, which is passed through the main device and out of another UART to a target device (this solution requires two additional ports per tunnel) and requires switching ports to select a target device; another way is to multiplex UART ports and switch them in software.

Example of UART tunneling from main device to the other device with use of additional UARTs.

                                   Main device
                              +---------------------+
                              |                     |                     Other device
   mcumgr-cli  <-----> UART0 <=>  SMP service       |                   +-----------------+
                              |                     |                   |                 |
   mcumgr-cli  <-----> UART1 <=========tunnel========> UART2 <--------><=> SMP Service    |
                              |                     |                   |                 |
                              +---------------------+                   +-----------------+

Above is costly, inconvenient, and may not be possible on other transports or devices with not enough resources, like UART ports.

Describe the solution you'd like SMP protocol needs extension that would allow to select or address target device by either switching SMP transport between devices or allowing to identify destination for SMP packet.

Describe alternatives you've considered Currently there is no convenient alternative.

Additional context TBD

ddavidebor commented 2 years ago

Loving this idea!

nordicjm commented 2 years ago

An idea for this: a new group could be added, which would allow querying of transports on device (server) which would have an ID, a type and a identification name, the connected client can write to this to select which transport is active, the default would be 0 (internal), but could be set to a number for an external UART, or another ID for external BLE device, or another ID for external UDP device (BLE/UDP would need a way of setting the remote device address (and port), UART would need to set which UART, or these could be part of the selection already e.g. ID 1 for UART1, ID 2 for UART5, etc.) Then when SMP commands are received on the device, it checks what the transport ID for the connection is, if it's 0 then it processes the data as normal, if it's non-0 then it strips away the transport-specific data and sends it to a transport-specific output function which can then output the data, this would allow a command to be received over UART and then transmitted to another device via BLE. It would maintain compatibility with existing commands and would only need the transport selection group code adding to the client, then clients can use other devices through a main device without changing the commands they send e.g. for firmware uploading or filesystem management.

Would probably need to be able to return the MTU of the different transport types howerver