Bug: AMT is not detected on Linux devices

[veitw]

Hi,

I have two Linux nodes installed with a minimalised installation of Rocky Linux 8.6, thus RHEL8 compatible, but while the agent connects successfully to MC and AMT has been configured in ACM mode using a setup.bin file generated by MC for AMT Fully Automated Policy mode, AMT is not being configured. Having a look at the Details tab shows me that AMT is not even detected by the agent as the AMT section is simply missing and the agent responds on the console:

> amt
Intel AMT not detected.

The kernel detects AMT and loads the iAMT MEI driver suite with the modules mei, mei_me and mei_wdt. The latter issues an error in the kernel log, but as this is only the watchdog, I do not think this is relevant for the detection, as I have seen this on other Linux devices (desktop installations though), too, that work perfectly.

The kernel log messages (UUID substituted) are:

[    4.139910] mei_me 0000:00:16.0: enabling device (0000 -> 0002)
[    4.344601] mei_wdt 0000:00:16.0-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx: Could not reg notif event ret=-22
[    4.345744] mei_wdt: probe of 0000:00:16.0-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx failed with error -22

SELinux has been disabled for testing and does not cause this issue.

The AMT serial port is detected correctly:

[    0.663809] 0000:00:16.3: ttyS1 at I/O 0x5080 (irq = 19, base_baud = 115200) is a 16550A

The system is a HP EliteDesk 800 G2 SFF with the latest firmware installed.

What else is required for the agent to connect via LMS to the ME/AMT on the device? Maybe a system package needs to be installed or another kernel module to be explicitly loaded?

How may I debug where the agent is stuck when connecting to AMT locally?

Best regards, // Veit

[Ylianst]

Interesting. When Intel AMT is detected on most Linux OS's, you should see a /dev/mei0 present, first, check that it's present. `/dev/mei/ is also ok, but that should only be for older OS's. Also, these are generally "root" owned paths, so you need root to access them.

One thing that can help debug is meshcmd, you can get it from your MeshCentral server, or on the bottom right of this page. Download the right version for you as as root, run ./meshcmd amtinfo, it should display current information about your AMT. Should look like this:

On both Windows and Linux, there is no requirement for LMS to be present when using MeshCentral. Both MeshCMD and MeshAgent have their own MicroLMS built-in that is used when LMS is not present. This is a big deal as most system don't have LMS installed and it's a real pain to find the correct installation form each manufacturer. For "meshcmd amtinfo", LMS is not needed anyway, just access to the MEI.

Give it a try, let me know what you see.

[veitw]

Hi @Ylianst,

thanks for the hints. /dev/mei0 is present and AMT is detected by ./meshcmd amtinfo:

# ./meshcmd amtinfo
DHCP error, timeout
Intel AMT v11.0.0, activated in Admin Control Mode (ACM).
Wired Enabled, DHCP, 48:0F:CF:xx:xx:xx, 192.168.1.93
Trusted DNS suffix: rootcert.meshcentral.com
Connection Status: Direct, CIRA: Disconnected.

I am just irritated by the DHCP error. I activated network access in AMT and meshcmd pulls its IP address correctly, as seen above. It seems to originate from agents/meshcmd.js:3119-3129, but according to the comment, this only affects retrieval of the DNS suffix.

Local firewalling has been disabled for testing this for both IPv4 as well as IPv6 -- nothing changed.

Also other AMT commands work well using meshcmd, e.g.:

# ./meshcmd amtfeatures --password 'xxxxxxxx'
Setting up MEI...
Started LMS...
User Consent         : None
Redirection Port     : Enabled
Serial-over-LAN      : Enabled
IDE Redirection      : Enabled
Remote desktop (KVM) : Enabled

So I think this could be some problem with MeshCentral itself, not my machine.

Best regards, // Veit

[veitw]

@Ylianst : Any more ideas on how to make AMT fly on Linux devices?

I can confirm that AMT itself actually works well on these machines; e.g. I can start MicroLMS via ./meshcmd microlms and access AMT via http://127.0.0.1:16994/ . The MeshAgent does not recognise AMT even with meshcmd's MicroLMS running, neither after re-uploading the agent core, nor after restarting the meshagent service. I also tried this after disabling the local firewall.

In the meantime I also updated MC to 1.0.39, no change so far.

[rapi3]

UP same problem with latest v1.0.71 this is also MC2 server computer running on Ubuntu server 22 - kernel 5.15.0-46-generic

./meshcmd amtinfo
DHCP error, timeout
Intel AMT v8.1.72, activated in Admin Control Mode (ACM).
Wired Enabled, Static, 44:xx:xx:xx:xx:xx, 192.168.22.16
Connection Status: Direct, CIRA: Disconnected.

./meshcmd amtversions
BIOS Version = 9SKT9AAUS
Flash = 8.1.72
Netstack = 8.1.72
AMTApps = 8.1.72
AMT = 8.1.72
Sku = 24584 (AMT, AT-p, Corporate)
VendorID = 8086
Build Number = 3002
Recovery Version = 8.1.72
Recovery Build Num = 3002
Legacy Mode = False```

[rapi3]

I think this problem can be related to this https://github.com/Ylianst/MeshCentral/issues/3846

> eval SMBiosTables.amtInfo
{"AMT":false}

[jsastriawan]

It looks like the cause of the issue is because SMBIOS table says AMT is not available, amtmodule and amt object is not initialized. See: https://github.com/Ylianst/MeshCentral/blob/master/agents/meshcore.js#L748

                if (SMBiosTables.amtInfo && (SMBiosTables.amtInfo.AMT == true)) {
                    var amtmodule = require('amt-manage');
                    amt = new amtmodule(mesh, db, false);
                    amt.on('portBinding_LMS', function (map) { mesh.SendCommand({ action: 'lmsinfo', value: { ports: map.keys() } }); });
                    amt.on('stateChange_LMS', function (v) { if (!meshCoreObj.intelamt) { meshCoreObj.intelamt = {}; } meshCoreObj.intelamt.microlms = v; meshCoreObjChanged(); }); // 0 = Disabled, 1 = Connecting, 2 = Connected
                    amt.onStateChange = function (state) { if (state == 2) { sendPeriodicServerUpdate(1); } } // MEI State
                    amt.reset();
                }

As a result, amtinfo will be called with null amt object and return not detected.

Looking deeper into SMBiosTables.amtinfo, it depends on SMBIOS table type 130. On certain system that has no table type 130, this object will be null. We need to use other table such as SMBIOS type 131 too.

[BlackDuck888]

Hello I have the same problem. Under linux I get in agent when I call amtconfig "Intel AMT not detected". Also SMBios does not give any results.

> amtconfig
Intel AMT not detected.
> smbios
{
  processorInfo: {
  }
  systemInfo: {
  }
  systemSlots: {
  }
}

I have already tried to follow up on this, but I can't get any further due to my lack of knowledge of nodejs. But @Ylianst maybe you can take over from here and fix the little thing? :smile:

As far as I can see the problem the smbios module tries to load here and here MemoryStream. The module should be called memorystream by now. However, obviously the SMBios module seems to return nothing, which leads in the consequence as already mentioned at this point to the fact that it does not go on.

many greetings Marc