AMT not responding after power off

[Roman_L_]

Hi,

I have an issue with AMT on a NUC (NUC5i5MY). When I send the "Turn power off" command, the AMT will stay alive for a bit but then it shuts off completely. In DHCP mode it does not send any DHCP requests (is it supposed to do that while Off?). When I configure it to use a static IP (remotely, using the Web UI), it just stops responding to pings and power management requests after a couple of minutes.

The power policies are set to "Mobile: ON in S0, ME Wake in S3, S4-5 (AC only)", so I was expecting that I should be able to reach AMT in S5.

Any ideas what could be wrong? Thanks!

[Roman_L_]

Seems to be caused by AMT going into sleep and not waking up. Setting IdleWakeTimeout to a higher value helps. Is this a known issue?

[Joseph_O_Intel1]

If AMT is going to sleep and not waking, you may need to readjust your tool usage, firmware and/or provisioning methodology.

To start with, I would update the firmware, to the newest available for your NUC

• Intel® NUC Kit NUC5i5MYHE firmware

When using the SCS tools for configuration, the IDLEWakeTimeOut value defaults to 3 minutes. This can be adjusted from 1 to 65535.

What management tool are you using to initiate the reboot commands?

Joe

[Roman_L_]

I'm using wsman (linux) which sends a RequestPowerStateChange request with PowerState=8, using the port 16992.

After IDLEWakeTimeOut, AMT stops responding to pings and connections to port 16992 fail repeatedly. Sending a WOL request using the MAC address of the machine works as a last-resort workaround as it wakes the machine up and brings AMT back.

Trying the new firmware is a good idea, thanks.

[Joseph_O_Intel1]

If after firmware update is done and you still have the issue.

I would suggest using the Mesh Commander tool and seeing if it will wake up the device. If it does, then we will know something is wrong with your tool implementation or if it is a platform issue.

https://meshcommander.com