Intel vPro Expert Center Blog

Fun facts about the Intel AMT serial port

ylian.saint-hilaire@intel.com — Fri, 25 Jul 2008 07:30:15 GMT

I often get questions about the Intel AMT serial port. Ever since the DTK started to make heavy use of it, serial-over-LAN has gotten a lot of attention. First, how do you change the COM port number of the Intel AMT serial port? The COM number (COM3: for example) is assigned by the operating system, so you don’t see that is any AMT/BIOS/MEBx option. You have to go into Microsoft Windows Device Manager, go to the properties of the “Intel(R) Active Management Technology – SOL” port. Then go into the “Port Settings” tab and press the advanced button. There, you can change the COM port.

Also, it’s often useful for application to be able to automatically detect the AMT serial port. In Intel AMT Outpost, I scan the device drivers looking for the “Intel(R) Active Management Technology – SOL” device and read the COM port number that follows in that string. Sofar, it seems to work great, even in non-English countries, something I am always worried about.

The Intel AMT serial port is much like any other serial port, but it has a PCI device identifier that is not normally known to Microsoft Windows and so, Windows does not know what to do with this device. On Intel’s web site, there is an SOL driver available. The serial driver itself is just a small .INF that tells Microsoft Windows to load and use the standard serial driver. In fact, one can manually force the standard Windows serial driver to be used for this device. You need to go in the device manager and pick a driver from the list, select Microsoft as the manufacturer and you will see it. Even if it’s possible, I don’t recommend it because the DTK code will no longer recognize that COM port as being the AMT port, it’s going to work but will have the wrong name for auto-detection.

Lastly, if someone needed to know if a computer is AMT enabled without having to load any drivers, one way to do it would be to detect the presence of the Intel AMT serial port. It is always present even when AMT is un-provisioned, and it can’t be turned off, unless AMT is disabled entirely in MEBx. This can be a good way to figure out if you need to start considering a computer for AMT setup.

Ylian

(Intel AMT Blog)

Top 5 things Intel AMT does and was never designed to do

ylian.saint-hilaire@intel.com — Tue, 26 Feb 2008 06:34:24 GMT

Years before I started working on Intel AMT, designers where creating a list of usages that would be enabled by Intel AMT. The list included, I presume, usages around 3PDS, remote reboot to BIOS, disk redirection, etc. Many of the Intel AMT usages that are promoted on the Intel web site. When I started work on the DTK, a personal challenge had always been to find new ways of using existing features to do different and sometimes unexpected things. Create new usages for Intel AMT that it was never originally designed to do. I now present my top 5 abuses of existing features.

TCP-over-Serial-over-LAN. The Intel AMT serial port I am told, was originally designed as an easy way to remotely take control of the BIOS and recovery OS remotely. Designers needed a way for BIOS to be able to send test display data to a remote console. A virtual serial port was a great solution. It so happens that in the original design, this serial port was always enabled and usable, even when the normal OS was running. This allows a serial agent to talk to a console while bypassing the OS’s network stack. This is interesting on its own and I started work on a serial agent of my own. Things took a weird twist when I started sending binary data and sending files over this serial port, making it very valuable. It’s only a few weeks later that I realized I could also send TCP traffic over this serial link, making it possible to contact TCP services on the Intel AMT computer even if the network stack was disabled. A few days later, I showcased the first demonstration of VNC-over-SOL, and turning this abuse of the serial port into an instant hit. To this day, VNC-over-SOL is still, one of the most impressive demonstrations of Intel AMT.

Reverse Watchdog. When Intel sales people demonstrate Intel AMT to customers, they often get asked if you can shutdown gracefully an Intel AMT computer using Intel AMT. The simple answer was no, Intel AMT will perform a brutal shutdown or reset upon request. To perform operations like a clean shutdown or reset, sleep or hibernation requires the involvement of the OS. You could tell a serial agent like Intel AMT Outpost to perform the shutdown, but that required opening the serial connection and could be a problem if you had to shutdown many computers. I needed a way to pass a small amount of information to a running Intel AMT agent on the PC, do it using SOAP/WSMAN only and if possible get confirmation of reception. We could store the command into 3PDS and have the agent read it periodically, but 3PDS required setup and that little amount of data would have required allocation of a 4K flash page. The solution came when looking at the agent presence feature. When a console creates a new agent, the agent can now register this agent locally. The agent also get the timeout of the agent in seconds (from 1 to 65535), this would be the key. By constantly trying to register a known GUID, Intel AMT Outpost could see if the agent existed or not. If suddenly the registration works, the timeout value would indicate that type of shutdown operation to perform. Better yet, the simple fact that registration occurred changes the state of the agent to “Running”, confirming to the console that the message was indeed received. Today the Intel AMT Terminal has “Agent Commands” in the remote control that allows a user to perform soft operations when the agent is running, even if the OS network stack is not working.

Mouse over serial. A few months back I started work on a smaller version of Intel AMT Outpost called Intel AMT Guardpost. The idea was that if a serial agent was going to be useful, it was going to need to run on a recovery OS, run in the background with no dependencies and with as little footprint as possible (Is it not annoying to have all there background processes running?). The C/C++ version of Intel AMT Outpost was on its way. One feature I always wanted to work on was a remote Windows command prompt; it took over a week to finally pull this off. I could now remotely shell to DOS and perform basic command line operations. I could also enter the command like editor with the “Edit” command at which point, the temptation to support the mouse-over-serial-over-LAN was a must have. Using the binary serial protocol, I added the support to the terminal in a few hours. To this day, it’s still a fun and amazing demonstration of outstanding remote manageability.

IDE-R within the OS. A few days after first enabling IDE-R within Intel AMT Commander, I stumbled upon something I had not noticed before. If an administrator where to start IDE redirection and the OS was to re-scan its plug & play devices, the additional floppy and CDROM drive would show up in Microsoft Windows. This was immediately interesting since transferring files over the serial port was limited to 115kb/sec a very slow speed in today’s world. With IDE-R, you can copy files at around CDROM 4x speed on a local network. All I needed was a way for Intel AMT Outpost to cause the OS to rescan its plug & play devices. A few hours later the “HWRESCAN” command was built and for the first time, an administrator could mount a CDROM remotely and install a patch as high speed without ever using the OS’s network stack. This feature also turned out to be an excellent compliment to VNC-over-SOL.

Fast data path using IDE-R. This is not an idea I never built into the DTK, but I wanted to add it to this list since it would also be an interesting was to use existing features in new ways. The serial-over-LAN feature turned out to be extremely valuable, but it is also slow. Serial ports are very inefficient. One way someone could speed things up is to use IDE-R as a fast by-pass to the OS. An administrator would mount a virtual floppy disk drive containing a single file. This file, would not really exist, it would contain different data each time it was read, making it possible to send data to an OS agent thru Intel AMT at much higher speeds. Also, since the floppy is a read/write device, the agent could write into the virtual file data that it wants to send to the console. It would be quite a bit of work to pull this off, but it certainly seems possible. Someone would just have to know the internal format of an .img file.

That’s my top 5. I realize this is probably a rather advanced blog article, but this is proof that you can have a lot of fun to any technologies.

Ylian (Intel AMT Blog)

A history of converting console text to VT100

ylian.saint-hilaire@intel.com — Sun, 11 Nov 2007 22:21:00 GMT

One of the tasks every BIOS vendors has to do when building a BIOS that sits on top of a Intel AMT enabled computer is to convert the text-mode display into a series of VT100 codes that are sent into the Intel AMT serial-over-LAN port to a terminal console. As I noticed when building IAmtTerm.exe , BIOS vendors do this very differently and sometimes very inefficiently.

The BIOS is in a position to capture displayed text when it's on the screen, something that the management engine (ME) on which Intel AMT runs can't do. Simply put, display and keyboard information does not flow thru Intel AMT. In order to provide text display and keyboard input remotely, Intel AMT provides the pipe (the virtual serial port) but needs the BIOS to do the rest. BIOS vendors where left to build code that would convert incoming VT100 codes into user key strokes and display changes into VT100 codes. As a result, how this operation is performed varies greatly from vendors to vendors, even for different BIOS from the same manufacturer (mobile vs. desktop).

The first difference is the handling of keys such as F1 to F10, there are no less than 3 different ways BIOS perform this conversion and so, IAmtTerm.exe provides 3 different mappings. Users have to change the key mapping manually and try them out. Secondly, some BIOS vendors tested against different VT100 terminals, notably terminals with only 24 lines instead of 25 lines. A real display and IAmtTerm.exe both have 25 lines, but many terminals have 24 since it was the convention during the modem days of the 80's to use the bottom text line as terminal status line. Some BIOS will try various tricks to display only 24 lines, hiding the top line, etc. Users that use IAmtTerm's "Terminal Analyzer" will also notice that different BIOS vendors convert text to VT100 differently. Some BIOS will send a full line whenever anything on that line has changed. Sometimes the codes for moving the cursor will be sent when the terminal cursor is already at that exact position on the screen. In one case, I even saw all of the display attributes (foreground and background color) be sent before each character on the screen, slowing down the display significantly.

In the latest versions of the Intel AMT Developer Tool Kit (DTK), I added Intel AMT Guardport, a light-weight C/C++ based serial agent. This new agent allows the user to shell to a command prompt and for the first time, Guardport also includes most of the same VT100 conversion that BIOS perform. When building Guardport, we took care to support all 3 F1 to F10 key mappings, and optimize VT100 display conversion to provide the best possible display speed. As a bonus, we also added proprietary mouse support, so you can enter a mouse enabled text application such as "Edit" and move the mouse over the application.

Ylian (Intel AMT Blog)