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

Solution 1:

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!

Solution 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!)