Is your feature request related to a problem? Please describe.
Currently, inside the code, a Sender object is passed around to provide (eventually) log messages back to the client. I see an opportunity to improve this architecture, simultaneously adding value to the bmcd.

Describe the solution you'd like
A more elegant way is to create a logging Sink for the log crate that sends log messages to HTTP clients that are subscribed for logging information. This way, all the log statements inside our code debug!(), error!() warn!() are automatically sent, eliminating the need to use Sender objects.
This solution needs to be redfish compliant.

https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2023.1.pdf

Acceptance Criteria

• There is a logging sink that hooks into Rust's logging framework
• Bmcd implements the LogService and is exposed over the Restful API
• Logging instances inside the code using Sender objects are replaced with conventional log statements

Describe the bug
A clear and concise description of what the bug is.

[email protected]:/$ bmc
# Hello bmc start build time = 19:01:28-Jul 28 2023
bmc version:v1.1.0
INFO  [tpi_rs::c_interface] tpi_rs v1.3.0
start uart thread node num = 0----
pthread end
start webserver -
************************************************************************************************************************
* [libgo]	rel versiion V1.0.0.7  svn version: Unversioned directory   build time: 2022-11-14 23:27:17  
************************************************************************************************************************
start uart thread node num = 3----
start uart thread node num = 1----
start uart thread node num = 2----
goahead: 2: Configuration for Embedthis GoAhead
goahead: 2: ---------------------------------------------
goahead: 2: Version:            3.6.5
goahead: 2: BuildType:          Debug
goahead: 2: CPU:                arm
goahead: 2: OS:                 linux
goahead: 2: Host:               127.0.0.1
goahead: 2: Directory:          /tmp
goahead: 2: Documents:          /mnt/var/www
goahead: 2: Configure:          me -d -q -platform linux-x86-default -configure . -gen make
goahead: 2: ---------------------------------------------
goahead: 2: Started http://*:80
======= ASP_Init =====func_num 3=====
ASP_Init jst : name app_WebS_Jst_test
 ASP_Init act : name app_WebS_Act_test
 ASP_Init act : name bmc
*** stack smashing detected ***: terminated
Aborted

[email protected]:/$ echo $?
134

[email protected]:/$ df -h 
Filesystem                Size      Used Available Use% Mounted on
ubi0_5                   34.0M     32.2M      1.8M  95% /
devtmpfs                 49.9M         0     49.9M   0% /dev
tmpfs                    54.4M         0     54.4M   0% /dev/shm
tmpfs                    54.4M     44.0K     54.3M   0% /tmp
tmpfs                    54.4M     88.0K     54.3M   0% /run
/dev/mmcblk0p1           29.7G     32.0K     29.7G   0% /mnt/sdcard

[email protected]:/$ free -h
              total        used        free      shared  buff/cache   available
Mem:         108.7M       35.8M       50.1M      132.0K       22.9M       63.8M
Swap:             0           0           0

To Reproduce

I don't know what happened. The last thing I did was poweroff a node, and connected to some of the uarts. BMC (daemon) crashed while the BMC was still running. I couldn't restart it - same error. I rebooted the BMC (via reboot), same error. BMC (daemon) has not come back.

Expected behavior
A clear and concise description of what you expected to happen.

BMC does not crash or provides a message about what it was trying to do before it crashed. Is it getting bad or constant input from some source?

Screenshots
If applicable, add screenshots to help explain your problem.

Versions
print here the version of the tpi_rs library and other applicable versions

Additional context
Add any other context about the problem here.

We want to implement a firmware update of the BMC using the 'legacy api' endpoint. This endpoint accepts streaming firmware update file and executes the update accordingly.

Acceptance Criteria

• bmcd accepts a chunked upload to "/api/bmc?opt=set&type=firmware&file=my.img"
• 'osupdate' is executed when the file is completely uploaded
• result status is communicated back over HTTP

Acceptance Criteria

• Basic and Session-based authentication is enabled (created according to Redfish spec. 4.1 and 4.2)
• The legacy API is behind this authentication as well

Is your feature request related to a problem? Please describe.
As a web developer, I want an API call that returns more node information given a particular node id.
As a web developer, I want an API endpoint to update any of these properties.

Describe the solution you'd like

endpoint api/bmc/?opt=get&type=node_info

which returns the following JSON structure:

{
   "node_info":[
      {
         "1":{
            "name":"my raspberry",
            "module_name":"Nvidia Jetson nano",
            "uptime": 123123,
            "uart_baud": 115200
         }
      },
      {
         "2":{
            "name":"foobar",
            "module_name":"Nvidia Jetson nano",
            "uptime": 123123,
            "uart_baud": 115200
         }
      },
   ....
   ]
}

• All attributes of the json items are plain strings or numbers.
• the module_name is an arbitrary name, it does not have to be a predefined exhaustive list item

endpoint api/bmc/?opt=set&type=node_info SET

Which can be used to update the items. The user can decide to update all nodes/all attributes at once. Or select specific attributes. e.g.

{
   "node_info":[
      {
         "1":{
            "module_name":"Raspberry Pi CM4",
            "uart_baud": 115200
         }
      },
      {
         "2":{
            "name":"New jeston",
         }
      },
   ....
   ]
}

will only update the module name and buad of node 1. for node 2 only the name gets updated.

This data can be persisted in the app persistency

Is your feature request related to a problem? Please describe.
During firmware-update of a given node, It is possible to power off the board (via the front-panel). Since the BMC is never turned off, it continues the firmware upgrade process, including writing to it. This will fail at some point. The annoying side effect is that the webapi is still blocking on the request.

Describe the solution you'd like
A way to cancel an ongoing firmware update request. A generic solution would be desired, as we will have more requests in the future with long execution times.
A possible solution could be to cancel or stop polling the tokio task executing a certain request.

The goal is to set up the fundamentals for our redfish interface. As a proof, a call to the redfish service root can be made

Acceptance Criteria

• calling curl -k 'https:///redfish/v1/' returns a HTTP service root response
• API schemas are created that support similar functionality as the legacy API
• API schemas are exported to the appropriate directory on the target

As part of Legacy and Redfish APIs, implement a reader/writer of nodes' serial interfaces in bmc_application.

For reasons of backwards-compatibility, and as easy-to-create beginnings of a new webserver, implement support of a legacy API. This webserver will recreate functionality of its C version, which already had a lot of its functionality moved to tpi_rs library.

The implementation details of this webserver will later be used when creating support for Redfish API.

Includes #22

Acceptance criteria

• goahead webserver is removed
• rust HTTP framework is chosen and a MVP server is implemented
• TLS is enabled
• tpi_rs is renamed to bmcd which stands for BMC Daemon
• c_interface module is removed
• Bmcd should easily be extendable with another Restful interface (Redfish)
• Bmcd builds as part of the buildroot build. Buildroot package declaration files are created/updated
• There is an init.d service file on the target that starts the bmcd on startup
• full support of the legacy API is implemented

for a better user experience for our client tools, such as tpi, implement a service discovery mechanism as defined in the redfish spec.

Goal

The objective of discovery is for client software to locate managed devices that conform to the Redfish
Specification. Therefore, the primary SSDP functionality is incorporated in the M-SEARCH query.

Example response

HTTP/1.1 200 OK
CACHE-CONTROL:max-age=<seconds, at least 1800>
ST:urn:dmtf-org:service:redfish-rest:1
USN:uuid:<UUID of the service>::urn:dmtf-org:service:redfish-rest:1
AL:<URL of Redfish Service Root>
EXT:

Acceptance Criteria

• the service should use UDP port 1900 for all SSDP traffic.
• the Time-to-Live (TTL) hop count setting for SSDP multicast messages should default to 2.
• The UUID in the USN field of the service shall equal the UUID property in the Service Root.
• The unique ID shall be in the canonical UUID format, followed by ::dmtf-org.
• the bmc responds to search targets: urn:dmtf-org:service:redfish-rest:1 and ssdp:all and upnp:rootdevice
• The URN provided in the ST header in the reply shall use the redfish-rest: service name followed by
  the major version of the Redfish Specification

Describe the bug
I recently upgraded the BMC firmware to the latest, namely version 1.1.0. After that I wanted to ensure the right version was installed by issuing bmc info command.
The tool crashed right away no matter the argument I tried with.

To Reproduce
Steps to reproduce the behavior:

1. Enter CLI via ssh
2. Execute bmc command
3. See below error message

Hello bmc start build time = 19:01:28-Jul 28 2023
bmc version:v1.1.0
INFO  [tpi_rs::c_interface] tpi_rs v1.3.0
thread '<unnamed>' panicked at 'unable to initialize bmc app: pin_controller

Caused by:
    0: error initializing pin [PORT1_USB_VBUS, PORT2_USB_VBUS, PORT3_USB_VBUS, PORT4_USB_VBUS]
    1: Device or resource busy (os error 16)', src/c_interface.rs:49:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 9
Aborted
<img width="1299" alt="Screenshot 2023-08-24 at 16 28 28" src="https://github.com/turing-machines/bmcd/assets/23614/dca7a8fd-4bd8-4a5a-8696-69893ae28a53">

Expected behavior
bmc tool should display usage or recognize and execute the command specified in arguments.

Describe the bug
The command to route the USB-a port as a USB device to a node is not working anymore. I compared the same reproduction scenario on TP 'v1.0.2' and the issue was not present.

To Reproduce
Steps to reproduce the behavior:

1. have raspberry cm4 ready with an working OS on it.
2. flash latest on TP2. e.g. https://github.com/turing-machines/BMC-Firmware/actions/runs/5554950485
3. set the TP in USB device mode: curl 'http://<TP IP>/api/bmc?opt=set&type=usb&node=0&mode=0'
4. power on the nodes by pressing KEY1
5. Attach USB keyboard to USB-A port.
6. see keyboard is not powered and not working.

Expected behavior
keyboard to be powered and working

Versions
seen with tpi_rs 1.2.0

Acceptance Criteria

• There is an CI job that scans the repo for non-permissive licenses
• The bmcd fulfills the requirement of displaying the appropriate licenses to the user with a convenient command
• the documentation makes mention of these licenses

Is your feature request related to a problem? Please describe.
Currently, the async Read/write trait for writing firmware to the RK1 is implemented in a blocking way. This is because the crate we use to interface rockusb, is implemented using blocking calls. I'd argue this ticket has a low priority as its a relatively high effort for a small gain.

Describe the solution you'd like
Implement async read/write for USB commands inside rockusb. Perhaps rusb-async can support in achieving this goal.

Describe alternatives you've considered
couldn't find any other crates to date.

The goal is to enable "Basic Authentication" for the bmcd.

Acceptance Criteria

• There is an actix wrapper that implements a basic authentication protocol using Linux's user database.
• All users that are registered to the Linux OS are granted permission to use any API endpoint beyond this authentication

Is your feature request related to a problem? Please describe.
Rockchip-based devices are typically shipped with a debug UART that communicates at 1500000 baud. bmcd naively configures all four serial ports to 115200 baud, since that's the default for Raspberry Pi devices (and others, I'm sure). The current uart API is, therefore, unusable for these Rockchip devices.

Describe the solution you'd like
Ideally, bmcd could auto-detect the appropriate baud rate for a given node's device. This may be through a mapping of known device types to rates, or autobaud detection. This would probably need to be overridable by the user as well, in case of unknown or broken detection.

So, for a given node, the baud rate could be configured by falling through values from this list, in order:

1. User-specified baud rate for single node
2. User-specified baud rate override for all nodes (maybe?)
3. Known baud rate for a known device attached to the node
4. Auto baud rate detection
5. Fallback, default rate of 115200

Maybe an initial implementation could be as simple as items 1 and 5?

Describe alternatives you've considered
Look, you can always ssh in and use picocom to set the baud rate, but that's not ideal.

Additional context
A device that exhibits this behaviour is the Orange Pi CM4.

This is more of a question than a true feature request- is there any reason bmcd is being built against OpenSSL rather than rustls? I've been playing with the latest build on my hardware and ported it over without much headache, but I didn't want to submit a PR without some discussion first to make sure I understand why it is built the way it is.

Loving the new tools btw, absolutely excellent work!

Acceptance Criteria

• bmcd listens on port 443
• TLS is enabled using openssl
• There is an script that on the first boot of the device, generates self signed certificates