Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > 2008 > June > 17
Currently Being Moderated
2

Critical Usage Defect with AMT Reflector

Posted by Matt Ford on Jun 17, 2008 2:28:33 PM

Upon testing Intel's new AMT Reflector tool I was greeted with a cryptic error message. When attempting to connect to the server, the client failed with error code -4 (The AMT device is unprovisioned or provisioned in Enterprise Mode). But first, my setup. My test configuration consists of two Intel whitebox machines, each with Windows XP SP2 installed, AMT configured and provisioned in small-medium business mode running AMT 3.0. The entire network is isolated (no outside internet) and is administered by a DHCP server running on Windows Server 2003.

 

 

The left machine (hostname: gbit-vpro-01) is running the server application and the right machine (hostname: gbit-vpro-02) is attempting to run the client application (although both machines should be able to run either component). The right machine is provisioned in SMB mode, which is confirmed by accessing it through SyAM Provisioning Server

 

 

 

 

 

This is further confirmed by remoting into the client machine's BIOS:

 

 

 

 

 

 

 

 

 

 

No Luck

The listen and communication ports have been configured correctly. The server app is started, and begins listening. When I attempt to start the client application, I receive a notification:

 

I'm at a loss, because all other signs indicate that I am correctly provisioned in SMB mode. I tried unprovisioning and resetting to factory defaults and then setting up the ME from scratch.

 

And now it gets stranger...

When I attempt to run the reflector client on the same machine as the server (after reconfiguring the ports for localhost listening), I get some strange behavior.

 

  1. The server is run, configured, and started

  2. The client program is started. At this point, there is no response (no windows opens, no error, etc). But when the server is stopped, the same error message as before appears (and if the client was started multiple times while the server was running, the messages will stack.)

  3. Lastly, the server reports that multiple connections have been made. It records hundreds of in-packets, but 0 out-pakcets.

I've provided all the relevant information I can think of that would affect this usage situation. If anyone can think of a reason why this would not work in our specific network, please let me know. Overall, I'm interested by the potential of this tool, but disappointed by its non-functionality.



Add a comment Leave a comment on this blog post.
Jun 17, 2008 3:52 PM Timothy Duncan Timothy Duncan    says:

Hi, We have seen issues with port routing when the machine running the Intel(r) AMT Reflector "Server" is povisioned. you can test this by either un-proviisoning the computer running the Reflector Server or you can configure the 16992 port setting to redirect to something other than 16992 - anything really.

 

...td

DOPD SWE Tool guy

Jun 17, 2008 6:42 PM Guest Brett McKown  says:

To further expand on Tim's comments, the system running the Intel(R) AMT Reflector Server component shouldn't be an AMT system, or has the AMT features disabled, or the Reflector server's port mapping changed from the defaults. If the system hosting the server component is a provisioned AMT system (or has the AMT features enabled), then any incoming AMT commands over ports 16992-16994 would be picked up by the underlying AMT device and not by the server component executing in the host OS. So, in this setup, the client system would wind up talking to the server's AMT device and not the Reflector server component (which would reflect the messages back to the client's AMT device).

 

If you want to leave the server system with AMT enabled/provisioned, then you should change the incoming/inbound ports to another value (leave the outbound ports the same so the client's AMT device is targeted). Then the Reflector client software should attempt to communicate with the Reflector server on the new port value.

 

Now, for your original question: What is the meaning/cause of the error message? Assuming that you're following the above rules (regarding whether you re-assign the port mappings or disable AMT on the server system), then we would need to examine your setup in more detail to determine what may be causing this issue. As an additional test, you could attempt to connect, through the Reflector server, to the client's AMT device using either samples from the AMT SDK, the AMT Commander from the DTK, or using the SyAM management console. Just be sure to use the correct port number when connecting through the Reflector server.

 

Also, if I understood the last part of your post, you shouldn't attempt running the server and client components on the same system with the intent of managing that same system.