Home / server / Questions / 605077
Accepted
mpontillo
Asked: 2014-06-14 16:21:03 +0800 CST

How does Intel AMT (Active Management Technology) not interfere with the TCP/IP host stack?

  • 772

The Intel dev kit I've been using includes a remote management feature (also see the Ubuntu man page here) which allows remote reboots in case the operating system hangs.

It has the capability of listening a handful of ports (16992 and 16993, to be specific) on an IP address it shares with the operating system. (either by snooping DHCP requests or issuing its own; I'm not sure, but either way it uses a shared MAC address in this mode)

I have it running on a separate IP address, because I'm worried about one potential use case: how does AMT prevent the host network stack from conflicting with it?

In other words, the Intel management software is now listening [at least] two TCP ports, out-of-band and without the operating system's knowledge. Let's say I initiate a TCP connection to a remote host, and the host stack chooses 16992 or 16993 as the local port to listen on [for packets coming back to the box].

Won't packets returning from the remote host get "blackholed" and never reach the OS? Or is there some preventative measure, like an Intel driver in the Linux kernel knowing that TCP should avoid port 16992? (seems unlikely since this is an OS-agnostic feature.) Or maybe the management interface can forward traffic sent to port 16992 that doesn't belong to a known management session back to the host stack?

Either way, I'm reluctant to use this for network-intensive loads until I understand how this works. I searched the Intel documentation and couldn't find anything there either.

I suppose this could be tested by initiating around 30,000 TCP connections, and checking if connectivity works even if the port overlaps. But I haven't had a chance to do that yet.

(Footnote: I realize this question is similar to How does an Intel vPro based computer maintain IP connectivity?, but that questions addresses connectivity in general, not connectivity to the specific TCP ports that overlap with the host stack.)

networking

5 Answers

  1. Best Answer

    After configuring AMT to listen on a shared IP address, I ran the test mentioned by kasperd in the comments above. (against my own remote host with an SSH server, not actually example.com, of course) Here is the result:

    Positive test case (using a port not used by AMT):

    $ nc -p 16991 example.com 22
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
^C
$

    Negative test case (using a port used by AMT):

    $ nc -p 16992 example.com 22
$

    (After a few minutes, the negative test case timed out and returned to the shell prompt.)

    So as you can see, the packets coming back to port 16992 were dropped before they reached the host's TCP/IP stack.

    Recommendation: if reliable networking is important to you, do not enable AMT on the same IP address as your host TCP/IP stack!

    • 10

  2. There is a controversary thread at Intel forum Mapping between the Host IP and Intel AMT Device IP with the suggestion that

    one must configure different IP addresses for AMT and host when operating with static IPs.

    and an explanation:

    When you configure the vPro machine with static IPs, AMT will use the mac address called manageability mac which comes to play only in static IP mode. Manageability mac address is different from the mac address presented by the host.

    I confirm that using DHCP with both AMT and Host leads to routing problems. e.g. ping mislead:

    64 bytes from 192.168.1.11: icmp_seq=18 ttl=64 time=0.559 ms
64 bytes from 192.168.1.11: icmp_seq=18 ttl=255 time=0.614 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=19 ttl=64 time=0.579 ms
64 bytes from 192.168.1.11: icmp_seq=19 ttl=255 time=0.630 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=20 ttl=64 time=0.553 ms
64 bytes from 192.168.1.11: icmp_seq=20 ttl=255 time=0.602 ms (DUP!)
    • 2

  3. Won't packets returning from the remote host get "blackholed" and never reach the OS?

    All packets from the remote host with "AMT-ports" never reach any OS. They are intercepted by Intel ME/AMT. By default they are ports 16992-16995, 5900 (AMT ver. 6+), 623, 664.

    • 1

  4. What should be noted is, that AMT is intended as client OOBM technology not server one. Therefore yes, it may happen that that your computer decide to use AMT ports, but only in case that you specifically configured it to do so. Most of OSes come with preconfigured ephemeral ports at range 49152 to 65535 as suggested by IANA specification, some Linux distros with 32768 to 61000 and old Windows with 1025–5000.

    So from my perspective it is save to use shared IP for AMT since its ports are not in ephemeral range (unless you know what you do, and change this particular setting) and should not be used as listening port by any application.

    • 1

  5. One solution might be to set the ports for the Windows TCP stack by using netsh.

    By default, Windows uses port 49152 >> 65636 (or whatever the upperlimit is) So you're very safe to use AMT. You can set the port range with netsh. For instance, I always use about 1000 ports for perimeter machines.

    Furthermore, Intel strips off the AMT commands and passes all other traffic on those ports (16991-16995 actually!) to the OS (If an OS is present). So if you would have an application that opened up a port in the AMT range, the traffic will still pass through the OS to the application, because like I said, Intel only strips of the AMT management commands. Its unlikely your application is sending AMT commands.

    • -2