AMT remote network connection error

[aclarke7]

Im using the Intel System Defense Utility v1.7 on a Windows Server 2003 R2 computer to remotely connect to an Intel AMT supported computer with a DQ35JO motherboard. The board has the latest BIOS as of 4/2/2008. My problem is that when I connect through the internet to this computer, I get a Network Error dialog box that says, Please check network connection for the system or Power ON the AMT System and try after some time. Despite the error notice, I do get connected and Im able to access the Asset Management tab and read the remote computers hardware information. But if I click the Remote Control tab and try to perform any command such as power on/off, or boot the computer from a CD image file, I get the same error dialog mentioned above. I have no problem if I run the System Defense Utility on the same inside private network to access the computer but from the outside world via the public IP address, I get the error. Ive tried each of the following on the remote router with no success: map ports 16992-16995, put the computer in the DMZ. I thought perhaps the ISP is blocking some critical protocol so I tunneled in via a VPN but got the same error. What am I doing wrong?

[Sreelekshm_S_Intel]

Hi,

What is your AMT version?

Thanks,

Sree

[Gael_H_Intel]

Did you get a chance to read through the Readme file for the System Defense Utility 1.7? Here is the link:

http://downloadmirror.intel.com/15362/ENG/IntelSystemDefenseUtilityver1.7_readme.txt

It looks like the error message is a known problem. Also, is your OS supported with this utility? (From the readme it doesn't look like it.)

Operating System:
Microsoft* Windows* XP Professional with Service Pack 2
Microsoft Windows XP Home with Service Pack 2
Microsoft Windows Vista*.

Known Issues:
-------------
1. Connection may fail without giving error. Please make sure that you provide the correct password in the Connection & Settings window.



Network Discovery Feature:
--------------------------
Scan the Intel AMT system found in the local network, say if AMT system system's are in the network (192.168.1.x) then System defense utility would start scan AMT systems from 192.168.1.1 to 192.168.1.254 and the discovered computer's would be displayed in the "Network Discovery" tab. In this tab user can able to connect or disconnect the AMT system found during scan operation.

Connection & setting Feature:
-----------------------------
User can able to connect or disconnect the AMT system.
If the system is in connected state then this tab would show following info:
Version of Intel AMT system,
BIOS Version,
User Accounts and
Web Interface link.

Network Settings Feature:
------------------------
This feature has following options, the applies to AMT system
1) Obtain IP Settings Automatically (DHCP IP)
2) Use the Following IP Settings (Static IP)

Note:

i) When the Intel AMT Computer is configured to DHCP enabled mode, the host OS must be configured to use DHCP, as well
ii) When changing DHCP mode from disabled to enabled with the OS present, the Intel AMT device will establish connectivity only in the next host DHCP negotiation. It is advised to renew the hosts DHCP address in this case.


I hope this helps - note that we do not support this product in this forum so if this does not answer your question, we will need to find the appropriate place for it.

[aclarke7]

The version of AMT is from the latest BIOSdownload: BIOS Update 0757 [JOQ3510J.86A] (6183KB) 0757 1/30/2008.

[aclarke7]

I got the same error when running the System Defense Utility from Windows Vista. Could you direct me to the correct forum for posting my questions?

[Sreelekshm_S_Intel]

Hi,

Please post your question at VPro Expert center at http://communities.intel.com/community/vproexpert;jsessionid=7AE512427A06B3C787CBD849BEB1E581

Thanks,

Sree

[Ylian_S_Intel]

Hi there. I am going to take a guess at what the problem is. it is possible that the Intel System Defense Utility (ISDU) has very short timeouts for it's HTTP calls. When using it localy, it will work fine, but remotly, Intel AMT and the network lag make it so that some of the HTTP calls don't return in time and this error shows up.

Your not doing any wrong, and I bet that if you use the build in AMT web page to perform remote commands, everything works well. This is because normal web browsers have no timeouts, they will wait for the HTTP response practicaly for ever.

I did enconter this same issue with the DTK. i long time ago my timeout was 3 seconds, it is not 10 seconds, must higher than the ISDU (I think). Can you try the same scenario using Intel AMT Commander or Intel AMT Defender (my small ISDU clone). I will bet that the DTK works and so, the timeout is the issue. We can forward this to the ISDU team.

Ylian (Intel AMT Blog)

[aclarke7]

Yilian,

Your suggestion was right-on. I successfully booted a computer 5 miles away from a CD image on my local computer through a VPN connection. For the boot to complete, about 77MB of files had to be transferred. (see www.atechworld.com for the boot image.) For the future, should the ISDU v1.7 have an editable timeout?

Alan Clarke

[Ylian_S_Intel]

I hope Gael is keeping score, I am not going to often claim I am "right-on". Thanks for the data, I will forward this thread to the ISDU guys so they can fix it. This reminds me that I will make my timeouts configurable in Commander and Defender in the next version. As a rule of thumb, longer timeouts are better, especialy with embedded devices like AMT that are not very quick. It's also my understanding that TCP buffers in AMT are very small and so, it does cause many more round trips.

For IDE-R, I would suggest performing IDE-R for another local computer when possible because IDE/SATA commands where not intended to be sent over the Internet. Still, when you have no choice, it's a real lifesaver.

Ylian (Intel AMT Blog)