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.)
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):
Negative test case (using a port used by AMT):
(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!