Steps to reproduce

On .mpsrc set these values

"https": false,
"tls_offload": true,

Run MPS, it will exit

Describe the bug 🪲

AMT resources (enumeration contexts for example) are limited. If too many requests are sent to a computer over CIRA in a given time frame, some will fail, typically with a CHANNEL_OPEN_FAILURE with either code 2 or 4. This results in an exception and the API call fails.

Code 2 is OPEN_CONNECT_FAILED and code 4 is OPEN_RESOURCE_SHORTAGE.

It is particularly bad if the Pull for an enumeration fails as the enumeration context will be lost until it times out. One fewer context makes the problem more likely.

This isn't the fault of the caller. MPS needs to do some kind of flow control and only let so many requests over CIRA be active at once - especially with enumerations. Failures need to be retried - preferably after a delay.

To Reproduce 🪜
Steps to reproduce the behavior:

These exceptions do occur randomly, but the following is almost certain to generate these errors.

1. Set MPS logging to "silly" and restart MPS. Wait for devices to reconnect with CIRA.
2. Use the sample UI to go to the device details page for a device connected using CIRA.
3. Reload the page several times quickly in succession.

Note that error messages will flash on the page, and some data will not be filled in. Further attempts to refresh the page may generate more errors and different data will not be filled in.

The MPS logs will have errors like this:

2022-08-03T06:47:47.739Z silly: MPS: CHANNEL_OPEN_FAILURE, 794, 4
2022-08-03T06:47:47.740Z info: getComputerSystemPackage getResponse :
2022-08-03T06:47:47.740Z silly: getComputerSystemPackage Complete
2022-08-03T06:47:47.740Z error: Exception during AMT Hardware Information request : TypeError: Cannot read properties of null (reading 'Envelope')
2022-08-03T06:47:47.741Z debug: Event message published
2022-08-03T06:47:47.749Z debug: end of request, closing channel
2022-08-03T06:47:47.750Z debug: end of request, closing channel
2022-08-03T06:47:47.750Z silly: MPS: CHANNEL_OPEN_FAILURE, 795, 4
2022-08-03T06:47:47.751Z silly: getRedirectionService Complete
2022-08-03T06:47:47.752Z error: Exception during AMT Features request: TypeError: Cannot read properties of null (reading 'Envelope')

and later, after restarting everything:

2022-08-03T20:57:04.637Z silly: MPS: CHANNEL_OPEN_FAILURE, 41, 2
2022-08-03T20:57:04.638Z info: getChassis getChassis :
2022-08-03T20:57:04.638Z silly: getChassis Complete
2022-08-03T20:57:04.638Z error: Exception during AMT Hardware Information request : TypeError: Cannot read properties of null (reading 'Envelope')

Expected behavior

The page should reload with no errors.

AMT Device (please complete the following information): 🖥️

• OS: Windows
• AMT Version: 15.0.41
• AMT Configuration Mode: CCM
• Network Configuration: Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16
• Component & Version: latest

Mostly, CIRA connection timeout trigger occurs when we use power action API like (power off, restart, power on bios). Because of this we lose connection on MPS but AMT is still sending keep alive request in every 30 seconds but on MPS side we have already closed CIRA connection of client and it is stuck in loop now, The client thinks that it is still connected but on the other side (MPS) we have already closed the connection.

I have to restart MPS server every time to get it working again.

Describe the bug 🪲

This probably applies to other string values, it was observed with alarm clock occurrences.

A leading zero is lost in numeric Alarm names. The Alarm will display without the leading zero and it's not possible to delete it from the sample UI.

To Reproduce 🪜
Steps to reproduce the behavior:

Create an Alarm instance with the name "01". Observe it is displayed as "1" and attempting to delete it fails.

Expected behavior

It will display correctly. The delete button will work.

AMT Device (please complete the following information): 🖥️

• OS: N/A
• AMT Version: 16 - probably not relevant
• AMT Configuration Mode: ACM
• Network Configuration: Dynamic

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16
• Component & Version: MPS 2.6.0

Additional context

The alarm clock occurrence is properly set with AMT - if the leading zero was stripped before it got to the device, one would expect delete to work.

The problem is with the parsing of the XML returned from AMT - the parser has the xml2js.processors.parseNumbers value processor set which turns anything that looks like a number into a number.

The following fix seems to work. It prevents parsing of the ElementName and InstanceID fields as numbers if there is a leading zero.

If it turns out that ElementName and instanceID are always strings, the check for leading zero can be removed. They are certainly documented as strings for Alarm clock occurrences. (We don't care about a single zero, that works.)

diff --git a/src/amt/HttpHandler.ts b/src/amt/HttpHandler.ts
index d5ca127..354cfd4 100644
--- a/src/amt/HttpHandler.ts
+++ b/src/amt/HttpHandler.ts
@@ -19,6 +19,15 @@ export class connectionParams {
   digestChallenge?: DigestChallenge
 }
 
+function myParseNumbers(value: string, name: string): any
+{
+  if (name === 'ElementName' || name === 'InstanceID')
+  {
+    if (value.length > 1 && value.charAt(0) === '0') return value
+  }
+  return xml2js.processors.parseNumbers(value, name)
+}
+
 export class HttpHandler {
   digestChallenge: any
   authResolve: any
@@ -30,7 +39,7 @@ export class HttpHandler {
   parser: any
   constructor () {
     this.stripPrefix = xml2js.processors.stripPrefix
-    this.parser = new xml2js.Parser({ ignoreAttrs: true, mergeAttrs: false, explicitArray: false, tagNameProcessors: [this.stripPrefix], valueProcessors: [xml2js.processors.parseNumbers, xml2js.processors.parseBooleans] })
+    this.parser = new xml2js.Parser({ ignoreAttrs: true, mergeAttrs: false, explicitArray: false, tagNameProcessors: [this.stripPrefix], valueProcessors: [myParseNumbers, xml2js.processors.parseBooleans] })
   }
 
   wrapIt (connectionParams: connectionParams, data: string): Buffer {

On specific versions of AMT, the Audit Log REST API call will fail to respond. In the Sample UI this manifests as the Device page never loading any device information. Currently we are seeing this on a couple of different versions of AMT (11.6.10, 12.0.40). Updating the AMT FW to the latest version resolves this issue.

Link to issues on snyk:
https://snyk.io/vuln/SNYK-JS-LODASH-1040724
https://snyk.io/vuln/SNYK-JS-LODASH-1018905

Describe the bug 🪲
Upon first execution, MPS will generate the certificates that it uses for the CIRA connection.
On subsequent executions, it retrieves those certificates from the secrets manager (Vault in the reference design) to use for the duration of that instance's execution.
Since these certificates are pushed to the managed Intel AMT devices during activation, any changes to the certificates would require reactivation of each managed device.

In the current implementation design, if the certs are not retrieved from the secrets manager they are assumed to have not been created and the generation flow is executed. Unfortunately, if there is any issue with retrieving the already defined MPS certificates, then this will also trigger the cert generation flow. For example, in the reference design, if there was an issue with accessing Vault -- whether the vault is sealed or an infrastructure issue -- then the MPS certificates are assumed to not exist and will be regenerated.

This issue appears to be agnostic to the underlying secrets manager implementation, whether Vault or custom middleware.

To Reproduce 🪜

1. Initial State: Open AMT Cloud Toolkit, v.2.10, deployed with 1 or more Intel AMT devices activated and connected via CIRA
2. Seal the Vault instance
3. Restart the toolkit services and confirm that CIRA is failing to reconnect

ExpectedPreferred behavior

1. The MPS certificate creation process should be done during the deployment stage of the server components (or configurable by users of the toolkit).
2. MPS should log an appropriate error message when the certificates cannot be retrieved from the secrets manager, and then exit.

Screenshots 🖼️
n/a

AMT Device (please complete the following information): 🖥️
n/a

Service Deployment (please complete the following information): ⛈️

• Deployment Type:
• Node Version:
• Component & Version:

Additional context
Related issue: #614

Describe the bug 🪲

When using an API that takes a character string, for example creating an alarm, the API will fail.

To Reproduce 🪜

Try to create an alarm named FooÀ.

Expected behavior

The alarm should be created and displayed correctly

AMT Device (please complete the following information): 🖥️

• OS: N/A
• AMT Version: 16
• AMT Configuration Mode: ACM
• Network Configuration: Dynamic

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16
• Component & Version: MPS 2.6.0

Additional context

Although the string sent to the device is UTF8 encoded into a Buffer in HttpHandler.wrapIt(), it implicitly gets decoded when appended to the message string since the default parameter to Buffer.toString() is 'utf8'.

In addition, the length of the javascript string is used, rather than the length of the UTF8 encoded string.

Although inefficient, the easiest workaround is to explicitly convert back from Buffer using Buffer.toString('binary'). When eventually converted to a buffer, the string returned from wrapIt() is treated as 'binary' so no further changes are necessary.

Making the above changes allows the alarm to be created, but it displays incorrectly. This is because the xml parser ignores the encoding. A very inefficient fix is: xmlToParse = Buffer.from(xml, 'binary').toString('utf8') in HttpHandler.parseXML().

diff --git a/src/amt/HttpHandler.ts b/src/amt/HttpHandler.ts
index 60ce395..1ad2453 100644
--- a/src/amt/HttpHandler.ts
+++ b/src/amt/HttpHandler.ts
@@ -37,7 +37,7 @@ export class HttpHandler {
     try {
       const url = '/wsman'
       const action = 'POST'
-      let message = `${action} ${url} HTTP/1.1\r\n`
+      let message: any = `${action} ${url} HTTP/1.1\r\n`
       if (data == null) {
         return null
       }
@@ -62,6 +62,7 @@ export class HttpHandler {
         })
         message += `Authorization: ${authorizationRequestHeader}\r\n`
       }
+      /*
       // Use Chunked-Encoding
       message += Buffer.from([
         `Host: ${connectionParams.guid}:${connectionParams.port}`,
@@ -72,7 +73,16 @@ export class HttpHandler {
         0,
         '\r\n'
       ].join('\r\n'), 'utf8')
+      console.log(message)
       return message
+      */
+      const dataBuffer = Buffer.from(data, 'utf8')
+      message += `Host: ${connectionParams.guid}:${connectionParams.port}\r\nContent-Length: ${dataBuffer.length}\r\n\r\n`
+      message = Buffer.concat([Buffer.from(message, 'utf8'), dataBuffer])
+      if (dataBuffer.length !== data.length) {
+        logger.silly(`wrapIt data length mismatch: Buffer.length = ${dataBuffer.length}, string.length = ${data.length}`)
+      }
+      return message.toString('binary')
     } catch (err) {
       logger.error(`${messages.CREATE_HASH_STRING_FAILED}:`, err.message)
       return null
@@ -108,7 +118,8 @@ export class HttpHandler {
 
   parseXML (xmlBody: string): any {
     let wsmanResponse: string
-    this.parser.parseString(xmlBody, (err, result) => {
+    const xmlDecoded: string = Buffer.from(xmlBody, 'binary').toString('utf8')
+    this.parser.parseString(xmlDecoded, (err, result) => {
       if (err) {
         logger.error(`${messages.XML_PARSE_FAILED}:`, err)
         wsmanResponse = null

Ideally, once UTF8 encoded, only a Buffer object should be used, but that requires more extensive changes. The switch to using "Content-Length" rather than chunked encoding makes the fix easier (saves 19 bytes on the wire, but breaks the CIRAChannel test - fix below).

diff --git a/src/amt/CIRAChannel.test.ts b/src/amt/CIRAChannel.test.ts
index 945a3fe..83f54f9 100644
--- a/src/amt/CIRAChannel.test.ts
+++ b/src/amt/CIRAChannel.test.ts
@@ -85,7 +85,9 @@ describe('CIRA Channel', () => {
   })
   it('should resolve if data does not contain messageId', async () => {
     ciraChannel.state = 2
-    ciraChannel.sendcredits = 116
+    // use sendCredits = 116 if using chunked encoding;
+    // extra characters are: "ingChunked\r\n\r\n0\r\n\r\n"
+    ciraChannel.sendcredits = 97
     const data = 'KVMR'
     const params: connectionParams = {
       guid: '4c4c4544-004b-4210-8033-b6c04f504633',

When a device should be removed from MPS/RPS first we should deactivate the device, which will deactivate the device and remove the device from RPS, including the secrets, and then delete&disconnect from MPS.
But there are chances that the device cannot be deactivate, by any method (it's unplugged, has no network, it's broken etc). In this case we can implement some background job to see if the device will become online but even so it may remain not accessible for ever.
It these cases it may be usefull to have APIs to completely remove the device from MPS/RPS, including the secrets (the device will remain activated but at least the db will be clean) .
As Matt suggested (https://discord.com/channels/1063200098680582154/1084852828733968405/1084859724106833992) the current MPS DELETE api may be extended with a query param to delete the secrets too.

Steps to reproduce:

1. in .env file, set MPS_USE_ALLOWLIST = true
2. Docker Up
3. AMT Device connects to MPS
4. following messages are output to MPS logs on device connect:
   2021-05-06T16:53:25.718Z info: getting secret secret/data/global guids_allowlist
   2021-05-06T16:53:25.731Z error: getSecretFromKey error
   2021-05-06T16:53:25.731Z error: Status 404
   2021-05-06T16:53:25.731Z error: Error while retrieving guids allowlist
   2021-05-06T16:53:25.732Z error: Cannot read property 'includes' of null
   2021-05-06T16:53:25.733Z info: CIRA connection established for {DeviceGUID-Redacted} executed query { text: 'SELECT * FROM devices', duration: 6, rows: 1 }

Describe the bug

Feature request - please provide a configuration setting to disable the MPS Auth capabilities, both "login" and "validator".

Expected behavior

This should result in a failure for anything passed into a call to either of these end points. I believe that 404 is best, but will defer.

No AMT device, the use case is one in which, Kong points at a different auth server.

All deployment types.

Describe the feature
Request adding support for and API endpoint to initiate remote unprovisioning/deactivation.

To Reproduce
Steps to reproduce the behavior:
n/a

Expected behavior
I want a way to unprovision the client remotely, so that I do not have to pass the AMT Admin password to and run the RPC on the endpoint.
Consider using the AMT_SetupAndConfigurationService.Unprovision WSMAN method.

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

AMT Device (please complete the following information): 🖥️

• OS: [e.g. Linux Kernel & Version]
• AMT Version: [e.g. 11.8.5, 12.0.45]
• AMT Configuration Mode: [e.g. Admin Control Mode or Client Control Mode]
• Network Configuration [e.g. Dynamic IP or Static IP]

Service Deployment (please complete the following information): ⛈️

• Deployment Type: [e.g. Azure, Docker, K8s]
• Node Version: [e.g. LTS 14]
• Component & Version: [e.g. RPS 2.0.0]

Additional context
Add any other context about the problem here.

AB#13156

Describe the bug 🪲
The API route /mps/api/v1/devices/stats should return the total amount of devices but it is currently capped at 25 devices due to a set constant "DEFAULT_TOP" in the DB query. This cap basically renders the stat useless as soon as you have more than 25 devices connected.

Code with the limited DB query is in the file src/routes/devices/stats.ts on line 10.

To Reproduce 🪜
Steps to reproduce the behavior:

1. Join > 25 Devices to AMT
2. Verify that the counter will not go above 25

Expected behavior
It should list the true total of devices.

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

AMT Device (please complete the following information): 🖥️
[Not relevant]

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: Latest docker image
• Component & Version: 2.4.0

Describe the bug 🪲

AMT may reject an incoming request from a CIRA channel if chunked encoding is used and the final chunk marker 0\r\n\r\n is split over two writes to the channel. This is arguably a bug with AMT's handling of requests over CIRA, but we can't fix that, nor is it likely that it will ever be fixed on all machines that OpenAMT needs to support.

To Reproduce 🪜
Steps to reproduce the behavior:

It may well occur randomly, but see pull request for an example #658

In the case of requests to the Alarm Clock Service, the length of a request depends on the length of user supplied strings. For example, the problem occurs trying to set an alarm named "Alarm Instance 3", but doesn't occur if the name is "Alarm Instance. The extra two characters are just enough to cause the write of the 0\r\n\r\n to be split.

Currently, an exception is thrown in whatever API was making the call and the API fails mysteriously. Posting the exact same xml (as was sent via CIRA) to localhost:16992/wsman succeeds.

See also #661

Expected behavior

Data should be written to the CIRA channel in a format that will be accepted, i.e. when data is written to a CIRA channel, do not split the final 5 characters over more than one write to the channel.

AMT Device (please complete the following information): 🖥️

• OS: Windows
• AMT Version: 15.0.41
• AMT Configuration Mode: CCM
• Network Configuration: Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16
• Component & Version: mps latest

Additional context

Silly level logging was added to log data sent by SendChannelData in APFProcessor.ts. It was noted that in the cases that failed, the final 0\r\n\r\n was split across two calls.

So, in the example case, the following change was made for test purposes. With the change, requests that previously failed, succeeded. No other new failures have been noted with this change. It obviously needs further testing.

diff --git a/src/amt/APFProcessor.ts b/src/amt/APFProcessor.ts
index 1e74107..ba4e6be 100644
--- a/src/amt/APFProcessor.ts
+++ b/src/amt/APFProcessor.ts
@@ -164,9 +164,15 @@ const APFProcessor = {
         delete cirachannel.sendBuffer
       } else {
         // Send a part of the pending buffer
-        APFProcessor.SendChannelData(cirachannel.socket, cirachannel.amtchannelid, cirachannel.sendBuffer.substring(0, cirachannel.sendcredits))
-        cirachannel.sendBuffer = cirachannel.sendBuffer.substring(cirachannel.sendcredits)
-        cirachannel.sendcredits = 0
+        let toSend = cirachannel.sendcredits
+        if (cirachannel.sendBuffer.length - toSend < 5) {
+          toSend = cirachannel.sendBuffer.length - 5
+        }
+        if (toSend > 0) {
+          APFProcessor.SendChannelData(cirachannel.socket, cirachannel.amtchannelid, cirachannel.sendBuffer.substring(0, toSend))
+          cirachannel.sendBuffer = cirachannel.sendBuffer.substring(toSend)
+          cirachannel.sendcredits -= toSend
+        }
       }
     }
     return 9

Describe the bug 🪲
Device shows 'connected' but API calls fail after MPS container restarts. This happens because we don't clean up the 'connectionstatus' property in database. See line https://github.com/open-amt-cloud-toolkit/mps/blob/main/src/index.ts#L126, this doesn't get executed.

To Reproduce 🪜
Steps to reproduce the behavior:

1. Connect a device to the Toolkit
2. Restart MPS container
3. The device shows connected but in reality NO API calls work

Screenshots 🖼️

AMT Device (please complete the following information): 🖥️

• OS: Win 10
• AMT Version: All supported AMT version
• AMT Configuration Mode: ACM
• Network Configuration: DHCP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Component & Version: Latest

Additional context
Add any other context about the problem here.

Describe the bug 🪲
MPS REST API calls fail after changing AMT password using changepassword maintenance command in rpc

To Reproduce 🪜
Steps to reproduce the behavior:

1. Deploy Open AMT CT stack using docker-compose or k8s
2. Activate and connect an AMT device to the stack
3. On the AMT device, run changepassword maintenance command using rpc
4. Notice that on the Sample-Web-UI all MPS REST API calls (like Power action) fail

Expected behavior
MPS REST API calls should work after changing AMT password using changepassword maintenance command in rpc

AMT Device (please complete the following information): 🖥️

• OS: Win 11
• AMT Version: On all AMT versions
• AMT Configuration Mode: Admin Control Mode or Client Control Mode
• Network Configuration: Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Component & Version: v2.7 release

This API route returns the root certificate but it is always reading from the file, ignoring what's on the config when using RAW format for certs

On the API GET /devices can you add a query param for the hostname.

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

MPS AuditLog API doesn't return audit records with most recent events first.

To Reproduce 🪜
Steps to reproduce the behavior:

1. Go to Devices in sample-web-ui
2. Click on a connected device with lots of entries in the device audit log (my device has over 1600 entries)
3. Device audit log may not show most recent events -- shows events from 5 months ago

Expected behavior
I expect to see the most recent events first

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

AMT Device (please complete the following information): 🖥️

• OS: [e.g. Linux Kernel & Version] Linux
• AMT Version: [e.g. 11.8.5, 12.0.45] 16
• AMT Configuration Mode: [e.g. Admin Control Mode or Client Control Mode] Admin Control Mode
• Network Configuration [e.g. Dynamic IP or Static IP] Dynamic

Service Deployment (please complete the following information): ⛈️

• Deployment Type: [e.g. Azure, Docker, K8s] - Local
• Node Version: [e.g. LTS 14] - 18
• Component & Version: [e.g. MPS 2.0.0] - Jan 2023 Release

Describe the bug 🪲
Issuing a power/bootoptions POST call with action 400 (Reboot to PXE), reboots the devices but does not cause the device to boot to the PXE boot options. However, if you then send a power/bootopions POST call with action 101 (Reboot to BIOS) the device will reboot and go to the PXE boot option. The device will not boot to BIOS.

To Reproduce 🪜
Steps to reproduce the behavior:

1. Send device power/bootoptions POST call with action set to 400
2. Wait for device to complete reboot
3. Send device power/bootoptions POST call with action set to 101
4. Device will reboot to PXE boot option

Expected behavior
Sending power/bootoption POST call with action set to 400 will cause the device to reboot to PXE boot option. Subsequent reboots (without setting action to 400) will not cause it to boot to PXE boot option.
Sending power/bootoption POST call with action set to 101 after the same call with action set to 400 will cause the device to reboot to BIOS, not PXE boot option

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

AMT Device (please complete the following information): 🖥️

• OS: Windows
• AMT Version: 12.0.85
• AMT Configuration Mode: Admin Control Mode
• Network Configuration DHCP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: LTS 16
• Component & Version: MPS 2.7 (release candidate)

Additional context
Add any other context about the problem here.

There is currently a known environment detection issue with AMT 11.x systems where AMT will not connect to the MPS after configuration. As AMT 11.x FW versions are no longer being updated, there is no FW fix for this issue. However there are two simple work arounds that can be used to resolve this issue.

1. Rebooting the system will reset the network adapter which will prompt AMT to perform environment detection and then connect to the MPS
2. Unplugging/Re-plugging the network cable will reset the network adapter which will prompt AMT to perform environment detection and then connect to the MPS

Currently we are only seeing this issue on AMT 11.x systems. If you see similar behavior on other AMT versions, please add to this issue so that we can update the issue.

Lines 20 to 22:

if (req.query.$status != null) {
  list = list.filter(x => x.connectionStatus === req.query.status)
}

Describe the bug 🪲

Both getAMTFeatures and setAMTFeatures call getKvmRedirectionSap() and assume that a response containing CIM_KVMRedirectionSAP is returned.

There is no check that a CIM_KVMRedirectionSAP is returned and the response can actually contain:

2022-08-19T18:13:21.022Z silly: {
        "Fault": {
                "Code": {
                        "Value": "a:Sender",
                        "Subcode": {
                                "Value": "b:DestinationUnreachable"
                        }
                },
                "Reason": {
                        "Text": "No route can be determined to reach the destination role defined by the WSAddressing To."
                },
                "Detail": ""
        }
}

The code attempts to access CIM_KVMRedirectionSAP resulting in an exception:

2022-08-19T18:13:32.040Z error: Exception during AMT Features Set request: TypeError: Cannot read properties of undefined (reading 'EnabledState')

The API fails with 500 status.

To Reproduce 🪜

Use the sample UI.

Provision a machine that doesn't have KVM, for example, the Dell Precision 3571. (Note that KVM isn't an option in the BIOS settings.)

In the sample UI, go to the Device Details for the machine. Note that an error flashes as the getAMTFeatures call fails. The error occurs again if the page is reloaded. Attempts to do SOL fail.

Expected behavior

There should be no error loading the Device Details and SOL should succeed.

AMT Device (please complete the following information): 🖥️

• OS: Windows 10
• AMT Version: 16
• AMT Configuration Mode: CCM
• Network Configuration Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16.16.0
• Component & Version: MPS orinem fork with Alarm Clock Support

Additional context

FWIW IMO, setAMTFeatures should use the same code to process the getKvmRedirectionSap() response. Since it's an exported function in getAMTFeatures.ts, it would simply be a matter of importing and calling processKvmRedirectionResponse() in setAMTFeatures.ts.

The underlying call to AMT does in fact return status of 400, but that is discarded by getKvmRedirectionSap() returning result.Envelope.Body. It should perhaps return null in this case and the callers interpret null as KVM not available.

It could also be argued that IPS_KVMRedirectionSettingData should be obtained and its EnabledByMEBx property checked, but using powershell to get IPS_KVMRedirectionSettingData also fails with 400 status (as observed by Wireshark), so there seems little point at this point in time.

Bandaid

The following will prevent the exceptions and both allow the device detail page to load, and SOL to work.

diff --git a/src/routes/amt/getAMTFeatures.ts b/src/routes/amt/getAMTFeatures.ts
index daf2d07..c46b740 100644
--- a/src/routes/amt/getAMTFeatures.ts
+++ b/src/routes/amt/getAMTFeatures.ts
@@ -18,6 +18,8 @@ export async function getAMTFeatures (req: Request, res: Response): Promise<void
     const optServiceResponse = await req.deviceAction.getIpsOptInService()
     const kvmRedirectionResponse = await req.deviceAction.getKvmRedirectionSap()
 
+    logger.silly(JSON.stringify(kvmRedirectionResponse, null, '\t'))
+
     MqttProvider.publishEvent('request', ['AMT_GetFeatures'], messages.AMT_FEATURES_GET_REQUESTED, guid)
 
     const { redir, sol, ider } = processAmtRedirectionResponse(amtRedirectionResponse.AMT_RedirectionService)
@@ -46,6 +48,7 @@ export function processAmtRedirectionResponse (amtRedirection: AMT.Models.Redire
 }
 
 export function processKvmRedirectionResponse (kvmRedirection: CIM.Models.KVMRedirectionSAP): boolean {
+  if (kvmRedirection == null) return false
   const kvm = ((kvmRedirection.EnabledState === Common.Models.CIM_KVM_REDIRECTION_SAP_ENABLED_STATE.EnabledButOffline &&
                 kvmRedirection.RequestedState === Common.Models.CIM_KVM_REDIRECTION_SAP_REQUESTED_STATE.Enabled) ||
                 kvmRedirection.EnabledState === Common.Models.CIM_KVM_REDIRECTION_SAP_ENABLED_STATE.Enabled ||

diff --git a/src/routes/amt/setAMTFeatures.ts b/src/routes/amt/setAMTFeatures.ts
index f01367f..ffbec21 100644
--- a/src/routes/amt/setAMTFeatures.ts
+++ b/src/routes/amt/setAMTFeatures.ts
@@ -27,7 +27,8 @@ export async function setAMTFeatures (req: Request, res: Response): Promise<void
     let redir = amtRedirectionResponse.AMT_RedirectionService.ListenerEnabled
     let sol = (amtRedirectionResponse.AMT_RedirectionService.EnabledState & Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.Enabled) !== 0
     let ider = (amtRedirectionResponse.AMT_RedirectionService.EnabledState & Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.Other) !== 0
-    let kvm = ((kvmRedirectionResponse.CIM_KVMRedirectionSAP.EnabledState === Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.EnabledButOffline &&
+    let kvm = kvmRedirectionResponse.CIM_KVMRedirectionSAP != null &&
+      ((kvmRedirectionResponse.CIM_KVMRedirectionSAP.EnabledState === Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.EnabledButOffline &&
       kvmRedirectionResponse.CIM_KVMRedirectionSAP.RequestedState === Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.Enabled) ||
       kvmRedirectionResponse.CIM_KVMRedirectionSAP.EnabledState === Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.Enabled ||
       kvmRedirectionResponse.CIM_KVMRedirectionSAP.EnabledState === Common.Models.AMT_REDIRECTION_SERVICE_ENABLE_STATE.EnabledButOffline)

Debug logs are not showing up on VS code output window. It works fine while running the application from terminal though.

Is it possible to port MPS to .NET Core 3.1? Considering that .NET Core 3.1 is an LTS version and is very popular these days?

Describe the bug 🪲
MPS will create new certificates if the vault is sealed. Incoming CIRA connections will fail due to expecting the old certificate.

To Reproduce 🪜

Follow steps to run vault in production mode here

Create a profile with a CIRA config and provision machines using it.

Restart Docker containers from Docker Desktop.

Unseal the vault.

Machines will show RAS Remote Status of "connecting" forever and the Web UI will show the machines as disconnected.

Expected behavior

Machines reconnect with CIRA.

AMT Device (please complete the following information): 🖥️

N/A

Service Deployment (please complete the following information): ⛈️
Docker, openamt 2.3.1

Additional context

Relevant part of MPS log:

2022-05-13T17:07:09.127Z error: getSecretAtPath MPSCerts error : Response code 503 (Service Unavailable)
2022-05-13T17:07:09.128Z info: Generating Root certificate...
2022-05-13T17:07:09.436Z info: Generating Intel AMT MPS certificate...
2022-05-13T17:07:09.571Z error: Error while writing secrets : Response code 503 (Service Unavailable)
2022-05-13T17:07:09.596Z info: Intel(R) AMT server running on 10.0.0.193:4433.
2022-05-13T17:07:09.596Z info: MPS Microservice running on 10.0.0.193:3000.
2022-05-13T17:20:07.188Z info: MQTT client closed

<restart MPS container>

2022-05-13T17:20:08.885Z info: Intel(R) AMT server running on 10.0.0.193:4433.
2022-05-13T17:20:08.886Z info: MPS Microservice running on 10.0.0.193:3000.

When MPS starts, it attempts to get the certificates from the vault. It gets a 503 response indicating the vault is sealed. It treats this response the same as if no certificates exist in the vault (the response is 404 if the certificates do not exist in the vault) and creates new certificates.

Machines connecting CIRA don't like the new certificates and the connections fail.

Workaround

Always restart MPS container after unsealing the vault and don't do anything involving MPS while the vault is sealed (creating CIRA profiles for example). MPS will revert to using the certificates stored in the vault after the restart.

I'm not familiar enough with how MPS is listening for connections to definitively suggest a fix. Perhaps reject connections while the vault is sealed? Once unsealed, get the certificates or create new certificates on a 404 response. Check vault on a timer or on incoming connections?

There may be other timing windows where MPS will serve certificates which have not been stored in the vault that can occur during the vault setup process. I recommend restarting MPS before creating CIRA profiles as the certificate currently in use by MPS will be stored in the database for the profile and sent to machines during CIRA configuration! This configuration will fail after MPS is restarted.

Describe the bug 🪲
A clear and concise description of what the bug is.
CIRA: Failed to add remote policy access rule

Expected behavior
A clear and concise description of what you expected to happen.
We try to configure and manage the device by AMT feature after follow the step on https://hackmd.io/sLq2LmbDQXGW6p16fGbPyA#Enviroment-Checking it got the device disconnected.
We run the rpc at manage device but it got the message as in below

time="2023-03-20T22:48:10+07:00" level=debug msg="connecting to lms"
time="2023-03-20T22:48:10+07:00" level=debug msg="connected to lms"
time="2023-03-20T22:48:10+07:00" level=debug msg="sending message to LMS"
time="2023-03-20T22:48:10+07:00" level=debug msg="listening for lms messages..."
time="2023-03-20T22:48:10+07:00" level=debug msg="sent message to LMS"
time="2023-03-20T22:48:11+07:00" level=trace msg="done listening"
time="2023-03-20T22:48:11+07:00" level=debug msg="received data from LMS"
time="2023-03-20T22:48:11+07:00" level=trace msg="HTTP/1.1 200 OK\r\nDate: Mon, 20 Mar 2023 22:48:10 GMT\r\nServer: Intel(R) Active Management Technology 14.0.39.1339\r\nX-Frame-Options: DENY\r\nContent-Type: application/soap+xml; charset=UTF-8\r\nTransfer-Encoding: chunked\r\n\r\n0425\r\n<a:Envelope xmlns:a="http://www.w3.org/2003/05/soap-envelope\" xmlns:b="http://schemas.xmlsoap.org/ws/2004/08/addressing\" xmlns:c="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd\" xmlns:d="http://schemas.xmlsoap.org/ws/2005/02/trust\" xmlns:e="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\" xmlns:f="http://schemas.dmtf.org/wbem/wsman/1/cimbinding.xsd\" xmlns:g="http://schemas.xmlsoap.org/ws/2004/09/enumeration\" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance\"><a:Header><b:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</b:To><b:RelatesTo>21</b:RelatesTo><b:Action a:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/09/enumeration/PullResponse</b:Action><b:MessageID>uuid:00000000-8086-8086-8086-0000000001F1</b:MessageID><c:ResourceURI>http://intel.com/wbem/wscim/1/amt-schema/1/AMT_ManagementPresenceRemoteSAP</c:ResourceURI></a:Header><a:Body><g:PullResponse><g:Items></g:Items><g:EndOfSequence></g:EndOfSequence></g:PullResponse></a:Body></a:Envelope>\r\n0\r\n\r\n"
time="2023-03-20T22:48:11+07:00" level=debug msg="sending message to RPS"
time="2023-03-20T22:48:11+07:00" level=debug msg="closing connection to lms"
time="2023-03-20T22:48:11+07:00" level=info msg="Status: already enabled in client mode."
time="2023-03-20T22:48:11+07:00" level=info msg="Network: Wired Network Configured. "
time="2023-03-20T22:48:11+07:00" level=info msg="CIRA: Failed to add remote policy access rule"
time="2023-03-20T22:48:11+07:00" level=debug msg="closing connection to lms"

AMT Device (please complete the following information): 🖥️

• OS: Windows 10 IOT
• AMT Version: Not sure please suggest how to check
• AMT Configuration Mode: Client Control Mode
• Network Configuration Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: Don't know please suggest how to check
• Component & Version: [e.g. MPS 1.0.0]

Describe the bug 🪲
Currently the secret interface blindly returns either data retrieved from the secret store or null if error. If the secret store provided a more robust return code, MPS could better handle issues where the secret store is unavailable for different reasons (sealed, service not available, data doesn't exist).

Currently MPS can take fairly drastic action based on getting a null response from the secret store when checking if the MPS certificates exist. If it receives null, MPS will regenerate certificates, causing all currently configured AMT devices to have invalid certificates. Have a more detailed return code can help MPS to moderate this action.

Describe the bug 🪲

It's possible for AMT to return status code 400 with no body (Content-Length: 0). In this case, parseBody() attempts to access message.body.text and throws an exception.

To Reproduce 🪜

It may well occur randomly due to an underlying problem with splitting writes of a request using chunked encoding to CIRA channels. This pull request discusses one such case

Expected behavior

A suitable error should be returned, either '' or null. It could be as simple as:

  if (message.bodySize === 0) {
    return ''
  }

Alternatively, it shouldn't even be called if bodySize is zero.

AMT Device (please complete the following information): 🖥️

• OS: Windows
• AMT Version: 15.0.41
• AMT Configuration Mode: CCM
• Network Configuration: Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16
• Component & Version: mps latest

Additional context

Debug trace showing message object passed to parseBody():

2022-08-01T18:54:20.997Z silly: parseBody: {
        "protocolVersion": "HTTP/1.1",
        "statusCode": 400,
        "statusMessage": "Bad Request",
        "headersSize": 143,
        "bodySize": 0,
        "headers": [
                {
                        "name": "Date",
                        "value": "Mon, 1 Aug 2022 18:54:20 GMT"
                },
                {
                        "name": "Server",
                        "value": "Intel(R) Active Management Technology 15.0.41.2142"
                },
                {
                        "name": "Content-Length",
                        "value": "0"
                }
        ]
}
2022-08-01T18:54:20.997Z error: Exception during alarm occurrences request : TypeError: Cannot read properties of undefined (reading 'text')
2022-08-01T18:54:20.998Z info: TypeError: Cannot read properties of undefined (reading 'text')
    at parseBody (/mps-microservice/dist/utils/parseWSManResponseBody.js:13:25)

Describe the bug 🪲

The src\interfaces\ISecretManagerService.ts interface appears to be missing at least 2 methods that are referenced in the src\utils\certificates.ts file. (from the current main branch)

• getMPSCerts() on line 25 of src\utils\certificates.ts
• writeSecretWithObject(...) on line 67 of src\utils\certificates.ts

To Reproduce 🪜
n/a - discovered via manual code review

Expected behavior
Having these functions clearly defined in the ISecretManagerService allows them to be cleanly overridden when substituting in a different secrets manager in customized builds.

Screenshots 🖼️
n/a

AMT Device (please complete the following information): 🖥️
n/a

Service Deployment (please complete the following information): ⛈️
n/a

Additional context
n/a

Describe the bug 🪲
We need the ability to create short lived bearer tokens to initiate and authorize KVMs sessions.

Expected behavior
An authorized client of Open AMT Cloud Toolkit can create a token and deliver this to an 'admin console.' This token must be locked to one particular AMT endpoint (client) and have a configurable short lifetime. The MPS should authorize this token prior to starting the KVM session.

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

See this sequence diagram for intended usage.

AMT Device (please complete the following information): 🖥️

• OS: OS Independent
• AMT Version: 11.8.5 and forward.
• AMT Configuration Mode: Admin Control Mode and Client Control Mode
• Network Configuration: Dynamic IP and Static IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: K8s
• Node Version:
• Component & Version:

Additional context
Information available from presentation shown by Matt and Michael. Please reach out if there are any questions.

Bug in 2.13!

We've upgraded from 2.8 to 2.13.

The custom middleware example set tenantId = ''.
https://github.com/open-amt-cloud-toolkit/mps/blob/main/src/middleware/custom/example.ts#L19

Our tenantId middleware is named connect-portal-tenant-id.js. Linux lists files in alphabeticaly order so example.ts will come after ours and overwrite the tenantId on request. As a result the multi tenant feature does not work anymore!

The line above should be commented, it's not good to provide an example middleware that alters the flow.

Describe the feature enhancement request 🪲
Add in RSE support for OAMTCT

To Reproduce 🪜
New request

Expected behavior
Support added for RSE to work when detecting vPro Enterprise platforms. RSE works on all SSD drives currently.

Screenshots 🖼️

AMT Device (please complete the following information): 🖥️
N/A

Service Deployment (please complete the following information): ⛈️
N/A

Additional context
Add any other context about the problem here.

Describe the bug 🪲

If an API request to MPS is aborted for whatever reason (browser 'reload', browser window/tab closed, 'back' in the browser?), the AMT channel being used by that request isn't closed. Eventually, the device runs out of channels and API calls fail.

To Reproduce 🪜
Steps to reproduce the behavior:

Set silly level logging.
On a device page, hit reload several times before the page finishes loading. Some API failures messages will probably show briefly.

Note in the MPS logs that there are completed API calls without an associated channel close.

Expected behavior

AMT channels should be closed immediately after an API call completes.

AMT Device (please complete the following information): 🖥️

• OS: N/A
• AMT Version: N/A
• AMT Configuration Mode: N/A
• Network Configuration N/A

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: 16
• Component & Version: 2.6.0

Additional context

Note that eventually, the device will timeout the orphaned channels and reloading the device page will succeed.

MPS is relying on either of the 'close' and 'finish' events being emitted by the Response object to close the AMT channel. In this case, neither are emitted.

The only event I've found to be emitted is 'aborted' on the Request object.

The obvious fix is to also close the channel on an aborted request, something like:

  appUseCall (req: Request, res: Response, next: NextFunction): void {
    res.on('finish', this.afterResponse.bind(this, req, res))
    res.on('close', this.afterResponse.bind(this, req, res))
    req.on('aborted', this.onAborted.bind(this, req, res))
    next()
  }

  onAborted (req: Request, res: Response): void {
    logger.debug(`Request aborted: ${req.url ?? 'undefined'}`)
    this.afterResponse(req, res)
  }

  afterResponse (req: Request, res: Response): void {
    if (req.deviceAction?.ciraHandler?.channel) {
      logger.debug(messages.EOR_CLOSING_CHANNEL)
      req.deviceAction.ciraHandler.channel.CloseChannel()
    }
    res.removeListener('finish', this.afterResponse)
    res.removeListener('close', this.afterResponse)
    req.removeListener('aborted', this.onAborted)
    // actions after response
  }

However, on reviewing nodejs issues re: which events are emitted when, I could not trust that this is the only event we might miss resulting in leaking AMT channels, or even that the 'aborted' event on the Request object is how they'll handle such cases in the future.

A better solution IMO is to add:

    finally {
      try {
        req.deviceAction?.ciraHandler?.channel?.CloseChannel()
      } catch (error) {
        logger.error(`${messages.ALARM_OCCURRENCES_EXCEPTION} : ${error}`)
      }  
    }

or similar to the end of each API, after the existing try-catch block to ensure any channel created would be properly closed. It is rather tedious though.

Hello. I've been testing this repo and it's amazing. Congratulations and thank you for doing this!

I was testing the Active Edge branch and I have a little question:

Will you provide a way to secure the REST API? I've not seen any authentication on it.
Also, I don't see any authentication for the React components.

Any way to secure the endpoints of MPS and RCS?

Thanks!!

After installing docker-open-amt-cloud-toolkit V1.5. According to https://open-amt-cloud-toolkit.github.io/docs/1.5/APIs/indexMPS/ ,I was trying to send request to my AMT device, but when I used Postman to send POST request

{
 "username":"my user name",
 "password":"my password"
} 

to https://192.168.xxx.xxx/mps/api/v1/authorize
It showed up {"message":"Unauthorized"}

Also,
when I used Postman to send POST request

{
 "action": 8,
 "userSOL":false
} 

to https://192.168.xxx.xxx/mps/api/v1/amt/power/action/MY_GUID
It showed up {"message":"Unauthorized"}

If a user 1 is in an active KVM sessions, and another user from another machine tries to initiate a KVM session on the same device that is active for user 1, an error should be returned to user 2 stating there is an existing KVM session.

Current MPS database backend is hardcoded to PostgreSQL. As deployments environment varies, connecting to different database means intrusive code editing. In order to ease the adjustment to various deployment condition, database middleware such as knex, sequelize, bookshelf etc should be looked at to provide flexibility.

After some combination of npm installs and deleting package-lock.json, both powerAction.ts and powerCapabilities.ts failed to compile. In both cases, it was attempting to return a value from a function declared as returning Promise<void>.

mps % npm run build

> @open-amt-cloud-toolkit/[email protected] build
> tsc

src/routes/amt/powerAction.ts:24:5 - error TS2322: Type 'Response<any, Record<string, any>>' is not assignable to type 'void'.

24     return res.status(200).json(powerAction).end()
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

src/routes/amt/powerCapabilities.ts:21:5 - error TS2322: Type 'Response<any, Record<string, any>>' is not assignable to type 'void'.

21     return res.status(200).json(bootCaps).end()
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Found 2 errors in 2 files.

Errors  Files
     1  src/routes/amt/powerAction.ts:24
     1  src/routes/amt/powerCapabilities.ts:21

The fix, should this occur, is either to remove the 'return' keyword or move it to a new line in these two files (falling through would simply return in both cases, but probably better to make it explicit).

After restoring my package-lock.json, this problem is no longer reproducible.

However, one of the fixes should be applied as trying to return something when void is expected doesn't make sense.

It's using CIM_Processor where it should be using CIM_PhysicalMemory. Not worth a pull request.

diff --git a/src/routes/amt/getHardwareInfo.ts b/src/routes/amt/getHardwareInfo.ts
index 98ae46b..8ba93d1 100644
--- a/src/routes/amt/getHardwareInfo.ts
+++ b/src/routes/amt/getHardwareInfo.ts
@@ -86,7 +86,7 @@ export function formatResponse (response: any): any {
     },
     CIM_PhysicalMemory: {
       responses: Array.isArray(response.CIM_PhysicalMemory?.Body?.PullResponse?.Items?.CIM_PhysicalMemory) ? response.CIM_PhysicalMemory?.Body?.PullResponse?.Items?.CIM_PhysicalMemory : [response.CIM_PhysicalMemory?.Body?.PullResponse?.Items?.CIM_PhysicalMemory],
-      status: response.CIM_Processor?.Body?.PullResponse?.Items?.CIM_Processor ? 200 : 400
+      status: response.CIM_PhysicalMemory?.Body?.PullResponse?.Items?.CIM_PhysicalMemory ? 200 : 400
     },
     CIM_MediaAccessDevice: {
       responses: Array.isArray(response.CIM_MediaAccessDevice?.Body?.PullResponse?.Items?.CIM_MediaAccessDevice) ? response.CIM_MediaAccessDevice?.Body?.PullResponse?.Items?.CIM_MediaAccessDevice : [response.CIM_MediaAccessDevice?.Body?.PullResponse?.Items?.CIM_MediaAccessDevice],

We registered the AMT device with MPS using the RPC. We don't see the AMT device name in the MPS dashboard; rather we see the UUID as the name as well as the uuid for the device. To identify a device , it is difficult to do that with the uuid if say 100 devices are registered.

• MPS CIRA connection not working on Node v8.11.4 & npm v5.6.0
• All the other functionality of project like REST API's, Web UI etc working fine
• AMT device doesn't initiate CIRA on above mentioned Node version for some reason

When the number of devices registered to the MPS increases, it becomes very difficult to search for a device.

Toolkit version: 1.3
AMT device version: 12
Steps to reproduce:

1. Send AMT command to power off system (either REST call or through UI)
2. Once device is off, send any other command (get powerstate, refresh device page on the UI and re-pull hardware)
3. In MPS logs, will see the device disconnect and be removed after several seconds

Sometimes the device will reconnect after a minute or two, other times you need to completely power off the device (pull power or 5 second hold on the power button). Once you power the device back on, it will reconnect to MPS.

Have tested this on other AMT versions (11.8) and this behavior doesn't happen.

Describe the bug 🪲

MPS sends CHANNEL_CLOSE when closing a channel. It also sends it in response to a CHANNEL_CLOSE message. AMT sends a CHANNEL_CLOSE message in response to receiving a CHANNEL_CLOSE message, at which time, it could re-use the channel ID. MPS's second CHANNEL_CLOSE could then close the wrong channel.

1. MPS sends CHANNEL_CLOSE for channel ID N
2. AMT responds with CHANNEL_CLOSE for channel ID N; it considers the channel closed
3. MPS sends CHANNEL_OPEN
4. AMT processes the CHANNEL_OPEN and reuses channel ID N
5. MPS processes the CHANNEL_CLOSE response and sends another CHANNEL_CLOSE for channel ID N, closing the wrong channel
6. MPS tries to use channel ID N and gets errors

The order of 2 and 3 isn't critical.

To Reproduce 🪜
Steps to reproduce the behavior:

Using MPS with silly level logging.

From the Sample UI, reload the device page multiple times before it finishes filling all the fields. The sample UI should show no errors. If it does, check the MPS logs for errors and the order of SendChannelClose, CHANNEL_CLOSE and CHANNEL_OPEN_CONFIRMATION along with the channel numbers. This example was OK, channel 7 was closed and the channel opened was 0. The 'bad' SendChannelClose is in bold:

2022-11-23T01:27:11.304Z debug: end of request, closing channel
2022-11-23T01:27:11.304Z silly: MPS: SendChannelClose, 7
2022-11-23T01:27:11.305Z debug: end of request, closing channel
2022-11-23T01:27:11.307Z silly: MPS: SendChannelOpen
2022-11-23T01:27:11.309Z silly: MPS: CHANNEL_CLOSE 9, 7
2022-11-23T01:27:11.309Z silly: MPS: SendChannelClose, 7
2022-11-23T01:27:11.314Z silly: MPS: CHANNEL_OPEN_CONFIRMATION, 10, 0, 499

Expected behavior

There should be no errors and SendChannelClose should only be called once.

AMT Device (please complete the following information): 🖥️

• OS: N/A
• AMT Version: 14..16
• AMT Configuration Mode: N/A
• Network Configuration: N/A

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Docker
• Node Version: MPS
• Component & Version: 2.6.0

Additional context

To quote the port forwarding reference manual:

3.3.2.4 APF_ChannelClose
When a party wishes to terminate a channel, it sends the APF_ChannelClose message. The receiving party must send back an APF_ChannelClose message unless it has already sent this message for the same channel. The channel is considered closed for a party when it has both sent and received APF_ChannelClose. The party may then reuse the channel number.

This wouldn't have been a problem if the protocol had used the sender/recipient pair to close a channel since in our case at least, it's unique.

Fix is to add a 'closeSent' flag to CIRAChannel, set it when sending CHANNEL_CLOSE and don't send CHANNEL_CLOSE on receipt of a CHANNEL_CLOSE if the flag is set.

As an ISV, I want to be able to deploy the MPS to an enterprise network and manage AMT devices directly, without using the CIRA channel

I want to have a way for MPS to notify me when specific events happen in MPS so that I don't have to monitor the log files or repeatedly make REST calls to get notified.

Example of events:

• When a device connects to MPS
• When a device disconnects from MPS
• When the device power state changes
• When a Remote Sessions starts (KVM, SOL, IDE-R/USB-R)
• When a Remote Session ends (KVM, SOL, IDE-R/USB-R)

Describe the bug 🪲
We are having trouble sending the Sleep and Hibernate power actions. We identified this problem when we tried to run these commands in our application that uses the AMT Cloud Toolkit. Basically we send the Sleep action and the machine remains on, and when we send the Hibernate command, the machine is turned off.

To Reproduce 🪜
Steps to reproduce the behavior:

1. We connect the machine with the AMT CLOUD,
2. Click on Hibernate in the toolkit interface and it performs the power down action

Expected behavior
Have him run the Hibernate command on the machine

Screenshots 🖼️
As you can see in the log, the history shows that power action 8, which is the power down, was executed, but we were clicking on Hibernate

AMT Device (please complete the following information): 🖥️
We did the tests on 4 machines, and on 3 of them this happened

• OS: Windows 11 64 Pro
• AMT Version: 16.1.25
• AMT Configuration Mode: Client Control Mode
• Network Configuration: Dynamic IP

• OS: Windows 11 64 Pro
• AMT Version: 15.0.42
• AMT Configuration Mode: Admin Control Mode
• Network Configuration: Dynamic IP

• OS: Windows 10 64
• AMT Version: 11.8.92
• AMT Configuration Mode: Client Control Mode
• Network Configuration: Dynamic IP

Service Deployment (please complete the following information): ⛈️

• Deployment Type: Azure
• Node Version: 16.18.1 (LTS)
• Component & Version: MPS 2.7 and 2.11

1. The documented endpoints are incorrect and missing admin directory
   https://open-amt-cloud-toolkit.github.io/mps/APIs/RPSmethods/ciraconfig/#get-all-cira-configurations
   https://open-amt-cloud-toolkit.github.io/mps/APIs/RPSmethods/ciraconfig/#get-a-cira-configuration
   https://open-amt-cloud-toolkit.github.io/mps/APIs/RPSmethods/ciraconfig/#create-a-cira-configuration

For example:
Documented Endpoint: /api/v1/ciraconfigs/
Actual Endpoint: /api/v1/admin/ciraconfigs

2. I'm assuming this is POST method, but it should probably be documented.
   https://open-amt-cloud-toolkit.github.io/mps/APIs/RPSmethods/ciraconfig/#create-a-cira-configuration

3. Error using Postman Google Chrome extension with POST methods
   Error: rps_1 | (node:54) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'configName' of undefined
   Getting a similar errors as above for these endpoints:
   /api/v1/admin/ciraconfigs/create
   /api/v1/admin/profiles/create

Hello there.

I have a few things to point out about the api/v1/amt/log/event/{guid} API call and documentation.

First of all I would like to ask if I am following the correct documentation (because some of the issues to be pointed out can be explained if not)

The initial link provided on the toolkit doc it this:
https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=HTMLDocuments%2FWS-Management_Class_Reference%2FAMT_EventLogEntry.htm

And following the docs and looking for the PET specs to translate the fields I got this:
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/platform-event-trap.pdf

It seems to be an old document but I did not found anything newer related to this. Is this the right place I should be looking for to translate those event fields?

Anyway putting that aside there are a few issues I would like to point out here:

1. The API documentation: https://open-amt-cloud-toolkit.github.io/docs/2.7/APIs/indexMPS/ have a few key points that are misleading
   1.1 All result event fields on the doc are lowercase but when we call the API all those fields starts with a Uppercase letter.
   1.2 The field time is actually TimeStamp when calling the API
   1.3 This is only a issue if the PET document pdf I pointed out is the right one but on the sample value and also calling the API the entity: 34 is returning the entityStr: "BIOS", but looking at the documentation BIOS should be 35.
   As I checked on the code for this it seems that the part that does not match between that doc and the current enum used is actually the number 19 (it was marked as reserved on the doc). On the current code we can find it here:
   https://github.com/open-amt-cloud-toolkit/mps/blob/88a14f4b67385f922a48570fada901d257bd9e71/src/utils/constants.ts
   Checking for SystemEntityTypes

Note: For the first two issues I don't know if the right place to post would be here or on the sample UI repo.