AMT stops responding via network - DHCP IP Address missing

[GMaie4]

Hello,

After initial Configuration on a new client AMT work fine. After some days AMT stops responding on the network. Only a hard reset of the computer pulling the powercord reactivate AMT on the client.

Since AMT Version 11 I have to change the AMT initial configuration  process.

Right now I enable AMT in BIOS. After reboot I logon to the MEBx via ctrl -P .   I change the default password and activate network access with DHCP Ip-Sharing with host. Thereafter I import my self-signed openssl certificates with powershell to access the system remote via port 16993 only.

That work fine but after a while AMT stops responding.  Connecting to AMT via localhost on the device revealed that the link is up but the system didn't receive an IP-address.

When I hard switch off the system MEBx reinitialize  and the system is working for a view days, loosing it s Ip -Address  again.

Solutions appreciate!

Regards

Günter

[adutchman]

I would have gone with 12th Gen NUC with vPRO and AMT but I can't seem to find any place to buy one yet.

[adutchman]

Apparently, the only fix for this will be a firmware update from Intel.  All of the "hacks" posted previously don't fully work.  They only may extend the time that the AMT stays awake and responding to network requests.

[adutchman]

I have now ordered the NUC12WSHv7 to replace this non-working NUC11TNHv7.  It was only about $35 more.  Hopefully the 12th gen NUC does not have the same issue as this one.  I will report back once here I have the new unit and configure the vPRO/AMT and test.

[jerrythea]

If you don't mind me asking, where were you able to find any 12th vPro models in stock?

I have tried all the usual spots: simplynuc, eitx, mitxpc, etc.

[adutchman]

Were you able to get a 12th gen NUC with vPro ordered from BLT?  Mine is shipping out today.

[adutchman]

I found the 12th gen NUCs with vPRO on Bottom Line Telecommunications (shopblt dot com).  I've never bought from them before, but they appear to be a legit company.

I wanted a NUC with Core i7, so I went with the NUC12WSHv7.  The BLT Item # is B09LX54 for that one with a US power cord.  They still have 2 units in stock.

If you want one with just the Core i5 processor (NUC12WSHv5), they have 4 of those in stock as well.  The BLT Item # is B09LX52 for the Core i5 with US Power cord.

[adutchman]

The good thing for me is that the RAM and storage I purchased for the NUC 11 will move to the NUC 12 without any issues. 

It looks like the Management Engine Firmware on the NUC 12 is newer than the NUC 11, but the Network Interface Controller is the same on both systems.  So, I just hope that the vPro/AMT works as it should on the NUC 12.

[jerrythea]

I am going to wait and see if you all have better luck with the 12th gen.

Intel should be providing these to us, since we seem to be doing their QA.

[adutchman]

It's just that I saw that their "in stock" quantity on the NUC12WSHv7 dropped by another 1, so I thought maybe you got it.  Looks like their current inventory on that model, which started out at 5, will be gone soon.  There is only one left and currently no more on order at this time.

[adutchman]

I have finished setting up the NUC12WSHv7 and wanted to let everyone following this post that so far all is good.  Something to note, there is no longer a CTRL-P option to get into and setup vPro/AMT/MBEX.  That has now been transitioned into the UEFI bios.  Frankly, I think that was long over due.

Also, I was concerned about "mondern standby" in Windows 11 because it didn't seem to work properly on the NUC11 series, but it seems to be working perfectly on the NUC12.

This is the model of NUC that I initially wanted to buy and so far, I am glad that I finally was able to get one.

I will post back in about 1 week to let you all know if the AMT continues to respond on my network.  (Fingers crossed!)

[adutchman]

It has been 4 days since I intentionally restarted the NUC12WSHv7.  I think it is safe to say that the 12th generation NUCs are not plagued with the issue discussed in this topic.  vPro and AMT continues to respond on the network. 

It should be noted that in Windows 11 with "modern standby", I have set the power policy to "balanced" and changed a setting to never sleep when plugged in.   I'm not sure if this setting has any bearing on the issue or not.

For me, though, at this point, everything with my unit is working as expected.  I will no longer be monitoring this topic.

[epavelcz]

Hello,

there's has been a new firmware released. I applied that 4 days ago and since that moment the IP keeps responding.

https://www.intel.com/content/www/us/en/download/19699/bios-update-tntglv57.html

Someone mentioned, that Intel admitted that as bug and now it seems to be fixed with version 70: TNTGLV57.0070.

Good luck

Regards, Pavel

[jerrythea]

I saw nothing in the README for the firmware update concerning an AMT fix.

I have asked Intel support for some clarification from the developers.

[jerrythea]

Official word from Intel is that version 70 did not fix the issue.

[jerrythea]

Intel support has shared a workaround that I actually believe can be considered a solution.

Depending on your system's platform (Windows or Linux) power savings mode needs to be changes from 'auto' to 'on'.

Intel can provide details on the mechanism to utilize on Windows.

On Linux, here is the solution:

# lspci | grep -e 'Communication controller'
00:16.0 Communication controller: Intel Corporation Tiger Lake-LP Management Engine Interface (rev 20)
# cd /sys/bus/pci/devices/0000:00:16.0/power
# ls
autosuspend_delay_ms  runtime_status          wakeup_abort_count   wakeup_count         wakeup_max_time_ms
control               runtime_suspended_time  wakeup_active        wakeup_expire_count  wakeup_total_time_ms
runtime_active_time   wakeup                  wakeup_active_count  wakeup_last_time_ms
# cat control
auto
# echo on >control
# cat control
on

If your AMT LAN access is not working, this command will immediately enable it and the AMT will be reachable on the LAN again.

I am working on a systemd script that will ensure that the setting defaults to 'on' by default.

[jerrythea]

After implementing this solution as a small systemctl script, my AMT system has been reachable on the LAN for several weeks now without issue.

I closed the support case with Intel, and consider this to be a solution, not a workaround.

[adutchman]

Thanks great news for Linux users.  Not so much for Windows users as there has been no information on how to implement this fix in Windows.

For me, I returned my NUC11 device and replaced it with a NUC12 unit.  I find Intel's lack of support on issues like this frustrating.

[jerrythea]

The fix for Windows users is even simpler:

Try this:

1. Open Device manager.
2. Under System devices, double click-Intel(R) Management Engine Interface #1
3. Select the Power management tab and de-select, Allow the computer to turn off this device to save power

[adutchman]

I'm glad to know that there is a workaround to fix this issue.  I'm sure that it will help other people experiencing this problem.

[jerrythea]

• Did you ever try filing a support ticket with Intel?
• I was able to work closely with them on this, and they were quite responsive.
• Their support group was able to reproduce the issue locally, and then they shipped a unit to a specialist for further investigation.
• While they waited for a response from the specialist, they continued to trying to find a workaround.
• In the end, I believe they found a solution.

[adutchman]

Most definitely! 

I opened a case/ticket with Intel support on December 20, 2022.  After the initial chat conversation with a support person, all further communications were moved to email.  It was a very slow and frustrating process.  The email messages usually took 2 or more days to go back and forth.  I even referenced and provided a link to this thread to let them know that this is exactly what was happening with my unit and that other people were experiencing the same issue.

My final contact with them for this case was on January 3, 2023, where I told them to close the ticket because I was returning their device as defective.  I needed to deploy a system and could not wait any more for them to admit that there was a problem, let alone to get a fix or work around.  I could not deploy a system that lost remote access via vPRO AMT or that required power cycling to restore functionality.

This was not the kind of support experience you would expect for a "business class" product.