In the SDK, samples/configuration/ztclocalagent directorythere is a file named PTHICommand.h which contains the following...
const UINT32 SET_ZTC_MODE_REQUEST 0x0400003A;
Question... how to derive the hex code for this and all of the others as well.
This command was mistakenly left in the header file in 3.0SDK but is not available to ISVs. Please refer to the available commands in Developers Guide to Sample SCA in the latest SDK (3.0.1).
Thanks... so it says... "the remote configuration local agent communicates with the intel amt device using functions that are a part of the intel host interface" Is there a complete description of the "intel host interface" that describes these, as well as any others available? I am wanting to testreading and writing 3PDS via something other than the oob soap/xml interface... if it cannot be done with this interface, then it would even be acceptable to me if it wasimplemented in bios code. Hope this is not too silly of a question. ;)
Not all of the host interface API's are documented in the SDK currently. Only the API's related to remote configuration local agent are currently documented. For your purpose, you can browse through the soruce code provided for storage library in the SDK and use the relevant portions. Some of the storage operation requires mutiple API's to be called and so they are abstracted in the storage library.
If you do not want to use the OOB soap/xml interface, please refer to the Network Interface guide in the SDK for the interfaces that allow local access. You can write a local agent that can issue the soap commands through the local interface. Chapter 7 - Supported Network Interfaces, lists out the various interface along with local access and network access information. Storage is allowed via both local and netowrk interfaces.
Please let us know if you have further questions.
Thanks for using the forum.
I have already seen that... I think the hardware engineer I am working with wants to be closer to the metal for his test... I am not clear on his objective and he is also aware of LMS... so we will discuss...
Also, while we are on the subject I was always curious why storage admin is not given local access. It has been easy for me to write a diagnostic that writes and reads the storage via the OOB interface... the same application that makes the storage admin calls to create a eacl, fpacl and register the application, makes the storage calls to allocate the block and write and read storage. Not givingstorage admin localmeansmy storage diagnostics will not run via LMS but rather they have to run on a remote machine. I would have to break it up into two parts, the remote storage admin part that would somehow have to communicate the admin parameters... enterprise name, application name, vendor name, etc... to the local agent part that would actually do the writing and reading. I think the engineer I am working with wants to stress the bus more andreading and writing via the LMS might be faster than doing it OOB style... it should be anyway.
I think there is a need for a ME SDK... seriously... IMHO the SDK is good for ISV's but does not allow low enough level acess to the hardware forcomputer developers and folks whodevelope software to test the hardware... think about it... the only AMT bugsI findhere are with test software...Is there a ME SDK coming out anytime in the future?
StorageAdmin realm is supposed to be used only over the remote interface to create the ACL, register the application. The local interface for storage is meant to be used by the in- band agents to write and read data to the 3PDS. You are correct that now you need to make the in-band agents that use the local interface, need to be aware of the some parameters to read/write to/from the 3PDS. All of the storage operations performed by the in-band agents using the local interface arerouted to MEvia LMS.
I am not aware of any ME SDK in the future roadmap. What are the things you would like to do with the ME SDK?
Local access to Storage administration realm is not allowed as per the network interface document. For that reason, all of the SA operations need to be done over the remote network interface. Read/write of datato 3PDS is not considered as administration operation andis allowed via both interfaces.
All of the administration/managementrealms are only available over remote interface. This would allow fora centralized location toconfigure many AMT clients with same set of configuration parameters. Inthis particular example of Storage Administration,an IT administrator can setup the permissions for local applications, addition ofeacl, fpacl to many clientsat once.Also this allows the IT administrator to manage these permissions as needed in the future and can beupdated remotely without thedependancy from the local in-band agents, which needs the OS to be up and running.
Some example use cases why you need read/write access from both interfaces:
- Local agent writes information about current system stateto 3PDS. Remote management consolereads information from 3PDS and updates inventory database.
- Remote management console writes information about needed patchesto 3PDS and local agent reads it from 3PDS, verifies the system state and initiates a patch download process.
Hope this clarifies your question. Please let us know if you havefurther questions. Thanks for using the forum.
The GeneralInfo APIs provides general (read only) information for various (local or network access) management applications. Please refer to the GeneralInfo API section in the Network Interface Guide in the SDK.
I do not understand your answer... please allow me to try my question again... I am not asking you what service should I call to get general information... I think I am asking you a different question... I think I am asking you, what api call can I make to determine if AMT is available... to find out if it does even exist on the machine or not... so thatI can determine if I can actually call a locally provided service... such as the general info service. Do you see the difference now in what I think I am asking versus what you think I am asking?
The GeneralInfo section in the network interface guide clearly mentions the API's available and the description. In your case, you need to use GetCoreVersion API defined in section 184.108.40.206. A string is returned if the AMT exists on the system. More details about the format of the string can be found in the network interface guide.
Please make sure that the HECI/LMS are installed when using this API.
Just a few more details please... if AMT does not exist on the machine, what will be in the string and what will the return value be? Additionally, I do not see in your netork interface guideany requirement that HECI -or- LMS should be installed or are required to be installed on the system... in what sectionis that mentioned please?
Please refer to section 5.1 in the network interface guide. The programmatic interface that allows access to Intel AMT features is through SOAP RPC-based. Local applications communicate with Intel AMT by encapsulating commands in a SOAP/HTTP message. LMS intercepts these messages to the host and route it to Intel Management Engine Interface (MEI formerly known as HECI)driver. So this mandates the requirement for LMS/MEI driver installed on the systemto usethe API's.
Coming back to your question about the return code. To the API you will be providing a string, so if there is no AMT the string value is unchanged. Also you will receive a SOAP error code because there is no body on the other end to process the SOAP message. SOAP error is determined by the SOAP stack you are using.
This function call will be encapsulated as part of the SOAP/HTTP message, when there is not AMT, this function will not be processed and instead you will be returned a SOAP error message such as 404- not found. Please read through sample codes provided in the SDK for further clarification. GeneralInfo sample uses the GetCoreVersion API.
I do not have AMT on my machine... the function is processed... and I do get a code back from the soap call...rc = soap_call___inf__GetCoreVersion(soap.GetSoap(), soap.GetIp(), NULL, &request, &_GetCoreVersionResponse);
rc = 0x16.
In the call below:
rc = soap_call___inf__GetCoreVersion(soap.GetSoap(), soap.GetIp(), NULL, &request, &_GetCoreVersionResponse);
rc is the return code from the soap stack. The return code 0x16 is SOAP_HTTP_ERROR. The status code from the SDK can be found in GetCoreVersionResponse.StatusCode.
Can you please confirm if this is the same error code you are seeing when you call GetEACStatus using EACA realm in another thread you have opened?