Intel AMT not detected by agent, but meshcmd detects it

[virtualdxs]

I have a Lenovo Thinkpad W540 that I'm trying to set up with Intel AMT in WAN-only mode. The AMT policy on the group is Fully Automatic. I have booted the laptop off a USB with the setup.bin provided by MeshCentral, and it is fully activated in ACM mode.

From agent console:

> amt
Intel AMT not detected.

From OS terminal:

[root@alpha meshagent]# meshcmd amtinfo
DHCP error, timeout
Intel AMT v9.1.45, activated in Admin Control Mode (ACM).
Wired Enabled, DHCP, 54:EE:75:49:B2:19, 192.168.1.42
Wireless Enabled, DHCP, CC:3D:82:7D:21:70
Trusted DNS suffix: meshcentral.k7dxs.net
Connection Status: Direct, CIRA: Disconnected.
[root@alpha meshagent]#

Environment information:

• Agent OS: Arch Linux (64 bit)
• Intel ME: v9.1.45 activated in Admin Control Mode (ACM)

[Ylianst]

Is the agent running with sufficient permissions to access /dev/mei0? If not, that would be typical. Both MeshCMD and the MeshAgent should attempt to open /dev/mei0 to get Intel AMT information.

[virtualdxs]

Agent's running as root and SELinux is not installed.

[virtualdxs]

Looking at strace output, meshcmd looks for /dev/mei, doesn't find it, finds /dev/mei0, and opens it.

Meshagent does something different entirely. I can't find any instance of it looking for /dev/mei or /dev/mei0. It looks through a couple symlinks in /sys, until it finds one that points to ../../../../module/mei_me. However, it seems to make a mistake in that it calls access() on that path relative to itself, not to the symlink, and gets ENOENT because it tries to find /module/mei_me rather than /sys/module/mei_me. Unfortunately, while symlinking /sys/module to /module does make that access() return 0, nothing else seems to change, so that's at least not the entire problem. After that, there's a bunch of newfstatat() calls alternating between looking at /sys/bus/* (including /sys/bus/mei) and then looking at /sys/bus/mei/devices/*; the former of which returns 0 and the latter of which returns ENOENT.

strace output filtered for mei follows (I can provide the full output if needed)

strace -etrace=file -f meshcmd amtinfo

[pid  1992] stat("amt-mei.js", 0x7ffedeb46de0) = -1 ENOENT (No such file or directory)
[pid  1992] openat(AT_FDCWD, "amt-mei.js", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  1992] stat("/dev/mei", 0x7ffedeb47990) = -1 ENOENT (No such file or directory)
[pid  1992] stat("/dev/mei0", {st_mode=S_IFCHR|0600, st_rdev=makedev(0xeb, 0), ...}) = 0
[pid  1992] openat(AT_FDCWD, "/dev/mei0", O_RDWR|O_NONBLOCK) = 10

strace -etrace=file -f /usr/local/mesh_services/meshagent/meshagent --installedByUser=0 (grabbed from systemd service file)

[pid  2225] readlink("0000:00:16.0/driver", "../../../bus/pci/drivers/mei_me", 4096) = 31
[pid  2225] readlink("0000:00:16.0/driver/module", "../../../../module/mei_me", 4096) = 25
[pid  2225] access("../../../../module/mei_me", F_OK) = -1 ENOENT (No such file or directory)
[pid  2225] newfstatat(AT_FDCWD, "mei", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid  2225] newfstatat(AT_FDCWD, "/sys/bus/mei/devices/scsi_host", 0x7fff75f80bc0, 0) = -1 ENOENT (No such file or directory)
[pid  2225] newfstatat(AT_FDCWD, "mei", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid  2225] newfstatat(AT_FDCWD, "/sys/bus/mei/devices/host0", 0x7fff75f80bc0, 0) = -1 ENOENT (No such file or directory)
[pid  2225] newfstatat(AT_FDCWD, "mei", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid  2225] newfstatat(AT_FDCWD, "/sys/bus/mei/devices/host0", 0x7fff75f80bc0, 0) = -1 ENOENT (No such file or directory)
[pid  2225] newfstatat(AT_FDCWD, "mei", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid  2225] newfstatat(AT_FDCWD, "/sys/bus/mei/devices/ata1", 0x7fff75f80bc0, 0) = -1 ENOENT (No such file or directory)
[pid  2225] newfstatat(AT_FDCWD, "mei", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid  2225] newfstatat(AT_FDCWD, "/sys/bus/mei/devices/ata1", 0x7fff75f80bc0, 0) = -1 ENOENT (No such file or directory)
[pid  2225] newfstatat(AT_FDCWD, "mei", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid  2225] newfstatat(AT_FDCWD, "/sys/bus/mei/devices/0000:00:1f.2", 0x7fff75f80bc0, 0) = -1 ENOENT (No such file or directory)
(same 2 lines repeat with different devices)

[virtualdxs]

Have there been any updates on this?

[krayon007]

Not yet, but I'll take another crack at it this afternoon.

[krayon007]

By the way, on the console tab of your agent, can you run the following command, and let me know what it returns?

eval SMBiosTables.amtInfo

I suspect that your Lenovo doesn't have the SMBios Tables populated correctly. It looks like the meshcore.js that the agent runs, only attempts to connect to MEI if the SMBios tables say that AMT is supported. If I remember correctly, this was to accommodate platforms that have an MEI driver installed, but don't actually have AMT support, from being reported as supporting AMT.

One thing I can do, is to try to make some AMT specific calls on HECI to see if it works, if the SMBios tables returns the wrong result... Let me talk to Ylian about that...

[virtualdxs]

Looks like you're spot on about that: {"AMT":false} Disappointing on Lenovo's part that this is an issue even after I fully brought the BIOS and ME firmware up to date.

[krayon007]

I'm going to try to write something in the JS to see if it can verify amt absence when smbios says it's absent. If it works, I can probably use it to force that smbios value to true so it gets reported correctly. I'll ping you again when I have that ready to see if you can test on your Lenovo system.

[cptechie]

I am having the same issue. Command eval SMBiosTables.amtInfo also returns {"AMT":false} for my Lenovo system even though I can activate AMT.

My AMT version is v8.1.72 if that helps.

[rapi3]

@krayon007 I can also test if you need as I have the same problem on Lenovo. This issue can be a duplicate here: https://github.com/Ylianst/MeshCentral/issues/4092

[veitw]

Hi,

looks like the same issue as #4092.

I am experiencing the same problem on all my Linux machines:

meshcmd:

-(~:#)-> ./meshcmd amtinfo
DHCP error, timeout
Intel AMT v11.0.0, activated in Admin Control Mode (ACM).
Wired Enabled, Static, 48:0F:CF:XX:XX:XX, 10.x.x.x
Connection Status: Direct, CIRA: Disconnected.

Agent:

> amt
Intel AMT not detected.
> eval SMBiosTables.amtInfo
{"AMT":false}

All devices are HP Elitedesk desktops (different models and generations), so this issue is not Lenovo-specific.

Maybe the agent would be better off relying on whether the Linux kernel has detected the MEI instead of what the vendor has populated to SMBios.

Best regards // Veit

[rapi3]

Lucky me on Dell ( linux of course ) I don't have this issue:

eval SMBiosTables.amtInfo
{"AMT":true,"enabled":true,"storageRedirection":true,"serialOverLan":true,"kvm":true,"TXT":false,"VMX":true,"MEBX":"9.0.0.29","ManagementEngine":"9.1.45.3000"}

[veitw]

The OS is a good point here.

So just to mention this: Other HP Elitedesk clients of equal model and generation as the problematic devices but running Windows instead of Linux get AMT detected successfully.

[rapi3]

About OS:

I just tested two Lenovo M83 - chipset Q85 ( latest BIOS and latest AMT firmware available upgraded ) and CPU I5-4590T so only AMT without vPro support form chipset Q85, event CPU support vPro:

• agent in win7 pro x64 - AMT was not detected by mesh agent / MC2
• agent in Linux x64 - AMT was not detected by mesh agent / MC2

AMT it is configured and accessible form lan or 127.0.0.1 in win7 and can be added by hand in another AMT group...

[raghu-mp]

Has there been any progress on resolving this?

Same problem here. Both Lenovo Tiny (M83, M93p) and HP (8300 Elite SFF) don't show any SMBiosTables.amtInfo. But AMT can be activated manually via BIOS. But running meshcmd to activate AMT outside of BIOS does detect it and meshcentral show AMT version as well. Just won't activate it.

[si458]

Due to @Ylianst being let go from Intel,

all amt issues are on hold for the moment due to no access to amt software and development

If you want to have a go fixing the issue yourself please do and we will accept pr

[dinger1986]

The other alternative would be to give the devs access to all modern AMT machines. I am sure they can supply an address to send the kit too