Background

Intel provide Active Management Technology to allow out of band monitoring and management of machines, regardless of the state of the client OS.

The BMC / ME can be assigned its own static address, which should "just work".

It can also use DHCP, although there may be come complications. Before AMT 5, the BMC / ME had its own MAC address (one greater than the host MAC address) so could DHCP independently. However, since then, a single MAC address is used, so the BMC / ME and host share a single IP address if both use DHCP. It snoops on DHCP replies, and sets the ME IP address accordingly, so causes problems if VMs on the machine use DHCP. The BMC / ME will steal any traffic for its ports (623, 4899 and 16992 - 16994), making them unusable for the host, which may nevertheless try to use them.

It can also use a different VLAN if the NIC is a VTRUNK.

It is available on S3000AH, DQ965GFEKR (but access seems somewhat flaky - just keep trying), DQ965GFEKR (AMT 2), DDQ35JO (AMT 3), DQ45CB (AMT 5), DQ57TM (AMT 6), DQ67SW (AMT 7), DQ77MK (AMT 8) and DQ87PG and Q87M-E (AMT 9) systems.

If the host is not in S0, the ME may move to M1 or M3 'sleep' state after the Idle Timeout (in minutes up to 65535, unless 0), plus 90s, has expired. A 'nudge' can wake it from this state, e.g. "Intel AMT command", ping (if enabled), WebUI (? if not enabled ??), ARP command directed to an AMT port (? ARP request for IP address ??)

Initial Notes

See. intel-amt, quick start guide (pdf), Implementation and Reference Guide

Some code is available in /usr/groups/linux/extra-packages/intel-AMT/ such as lms from openamt to access the local ME.

Common user commands

The most common user commands to manipulate the machine available only to the "assigned user" of a machine, are:

cl-boot-mc : boot the machine if not running (up to AMT 8 only)

cl-boot-mc tries to guess whether a machine might have an AMT BMC, and if so and the user has AMT credentials, it will try to use cl-amttool to power up the machine rather than just using WoL.

cl-amttool : power machine up or down (up to AMT 8 only)

cl-amttool can be used to power on, power off, reset etc a machine

Setup from BIOS

It should be possible to use Ctrl-P to manage the AMT setup and the ME. There may be alternative routes in, such as:

It will ask you for the password. The default is "admin" which has to be reset before remote management will work. Press Return to be prompted for the new PW. Passwords are 8 to 32 characters with at least one of each of: Upper Case Letter (A-Z), lower case letter (a-z), digit (0-9), "special" (!@#$%^&*). Clearing the password involves removing jumpers on the MB, so take care not to forget it. Use the "physical access" one with a stutter to meet the requirements

On a DQ965GFEKR there is a long delay before it comes up with a window saying that any changes need to be saved - press Return, and select "Intel(R) Active Management Technology Configuration".

[2011-09-06 fms] What if your new password is recognized by the local computer but not by the remote one? If the keyboard layout is anything other than US, note that some symbols may be on different keys (e.g. at least @#" between UK and US). When you redefine the password, the OS's keyboard driver is obviously not loaded, so what the BIOS receives may not be what you think you are typing. Then the password won't match the one you type in your client; and, because it isn't echoed, you won't even know. To check whether this is the cause of your problems, find a free-form text entry box in the BIOS and try typing your password in there to see what comes out. In the DQ965GF, for example, there is such an entry box in Setup / Intel ME / Intel AMT configuration / Computer Name.

Windows

Other than setting a "secure" password, the only required configuration (e.g. if wanting DHCP using a single MAC address) may be:

AMT 8

Select Intel(R) AMT Configuration and then

AMT earlier

When done:

Using a different VLAN (servers in machine rooms)

The machines can using a single VLAN, or use a separately tagged VLAN for the AMT traffic. It is cleaner to keep the AMT BMC management traffic on a separate VLAN, but it requires addition configuration in the switch, making more opportunities for confusion and errors. It also appears that on at least some switches, enabling VLAN trunking disables fast spanning tree detection. As such the current suggestion is that servers in machine rooms use VLAN tagging, whereas user Work Stations in offices use a single VLAN. The subnets 128.232.72/25 and 128.232.107/24 are used for $host-bmc and $host.bmc.

Enable VLAN and set which to use for the AMT (e.g. "Processor management" on 392). Under networking, enter the address (128.232.107.99), netmask (255.255.255.0) and default router (128.232.107.1).

Take the port down using HW (unplug it) or SW (mark it down). On the Cisco switch, enable VTRUNK and allow just the required VLAN (as clients don't VTRUNK prune).

conf interface FastEthernet0/1 switchport trunk native vlan 100 switchport mode trunk switchport trunk allowed vlan 100,392 (ctrl-Z) wr sh conf 

Re-enable the port.

Accessing (other than BIOS/POST at the console)

Access from VNC Viewer Plus (AMT 6+, on chip graphics)

If the machine has AMT 6 or later and uses the on chip graphics (see the hosts property BMC_vnc_plus), KVM access is possible using VNC Viewer Plus which requires a licence. Select "Connection Mode: Intel (R) AMT KVM" and "Encryption: None". If the machine does not use the on chip graphics, it may fail "Insufficient Permission to access" (as does bulova for reasons unknown) (most AMT 6) or "Unsupported or inactive display adapter" (bezier). If the machine is off and is not using on-chip graphics, connection may be possible, but it will disconnect when it turns on.

[fms:] If AMT access via the web browser works but you get that ambiguous "Insufficient permission to access" from VNC it may mean what it says, but it may also mean "I'm not telling you, but this hardware cannot run the VNC-based KVM". Even if the machine has AMT 6 or later. Even if the processor has on-chip graphics. Even if the BIOS lets you enable and disable the KVM options and set their permissions. The motherboard, chipset and processor ALL have to support AMT KVM for VNC+ to work. As for processors, only a few Core i5 and Core i7 (not Core i3) support AMT KVM and there is no easy way to tell which ones other than by consulting the following list. Just to show how unpredictable this is: the Sandy Bridge i5 2500K, which is in theory "slightly better" than the i5 2500 (ie has a higher-spec graphics subset, is unlocked and costs 10-20 pounds more) does not support VNC, even though the basic 2500 does. Summary: before spending hours trying to debug why it doesn't work, first check that the hardware actually supports it.

[sjm217:] If access to the KVM via VNC+ fails with "Unsupported or inactive display adapter" after boot, then adding "nomodeset" to the Linux command line may help (it did on ctsrd-slave2.sec). This can be achieved by setting: GRUB_CMDLINE_LINUX_DEFAULT="nomodeset" in /etc/default/grub for Ubuntu Server 12.04 LTS.

Access from web client on port 16992

If on a "core" Lab VLAN (but not the machine itself!), use http://$host.bmc:16992 (or http://$host-bmc:16992). If remote, use ssh tunneling, e.g. "ssh -N -L 8081:$host.bmc:16992 ssh-relay &", then connect to http://127.0.0.1:8081. For windows machines on VLAN 298 the same address is used by both the host and the bmc so access using http://$host.ad.cl.cam.ac.uk:16992

Access from a command line (amttool) on port 16992 (not available from AMT 9)

The Linux command amttool (may need the amtterm and perl-LWP-UserAgent-Determined packages to be installed) can be used to get general (info) and network (netinfo: 2.5+ only) info, reset, powerup, powerdown, powercycle, and configure the network (netconf: 2.5+ only). Commands which cause the machine to start can take a "special" argument to determine the boot behaviour.

A useful shell procedure to call this, which only keeps the password in the local shell, is:

ato() { h="$1"; shift; case "$h" in *bmc*|*.*|"") : OK;; *) h="$h"-bmc;; esac; case "$AMT_PASSWORD" in '') read -p "AMT_PASSWORD: " -s AMT_PASSWORD; echo;; esac; AMT_PASSWORD=$AMT_PASSWORD amttool $h "$@"; } 

Access from a command line (wsman) on port 16992 (available from AMT 3)

wsman -h $h-bmc -P 16992 -u admin -p $p identify
wsman -h $h-bmc -P 16992 -u admin -p $p get http://intel.com/wbem/wscim/1/ips-schema/1/IPS_HostBootReason

See AMT_Implementation_and_Reference_Guide.

Also consider wsl. See also Intel-AMT-vPro-under-Linux.

Access to SoL (radmin, gamt, amtterm) on port 16994

The Windows tool Radmin Viewer 3 (uses port 4899), the Linux GUI gamt and the Linux command line amtterm can be used to connect from another machine.

Linux clients appear not to be able to access the serial line during POST -- it only works when (e.g.) GrUB starts.

Although at least one instance of a machine running each AMT version works, many BMCs do not listen on port 16994

Access to BIOS or GrUB SoL, or boot non std device

In radmin, right click on the machine, select "Intel(R) AMT" and then:

the machine will immediately be reset, with access to the console in a new window.

On ramotswe (DQ35JO F11) and tywi (DQ35JO U9.04) a std GrUB configuration allow interaction. rhine (DQ35JO F10) does not.

If in use by another session it reports "Failed to communicate with the AMT library".

Client serial console setup

See "man amt-howto" for instructions on enabling the serial console in GrUB and running a getty (ttyS2 may be ttyS4 or ttyS1 -- it doesn't have a 'normal' serial port I/O and IRQ: "ttyS1 at I/O 0xe1c0 (irq = 17)")

SysInfo/IAMT (last edited 2014-07-17 13:00:44 by dart)