These are ``Video cards with an ethernet socket on the back''
Two Models so far:
Copyright 1999,2000 66Mhz i960 2.41a/b is the lastest firmware ~October 2001
Copyright 2001,2002 200Mhz PowerPC (G405e?) v1.02 rebrands it from "Compaq" to "HP"
I mostly don't know the pin-out and certainly not the pin-outs of the internal umbilical (ribbon cable) that connects to genuine Compaq boxes. The ribbon cable comes in two variants, a 16-pin standard 1/10th inch spaced connector on the first version (also on the second version) and a newer high-denisty 30-pin connector only available on the Edition II.
These ribbon cables carry Keyboard, Mouse, ATX power-button and presumabley USB (for faking the floppy drive). The 30-pin cable also appears to carry sound and some motherboard-monitoring data pins. Importantly, both cables carry a continuous, always-on voltage from the power-supply (much like wake-on-LAN [WOL] requires).
On the backplate is a 9-pin mini-DIN that is used by the loopback to the PS/2 ports that passes the keyboard and mouse signals sent over the network, back out of card and into the machine. The break-out lead (`Y' cable) features two male 4-pin mini-DIN plugs (which plug back into the motherboard) and a pair of 4-pin female mini-DIN sockets (aka PS/2) that can be used to plug a local keyboard and mouse into the machine without unplugging the loopback from the card.
When the card is being used to manage the PC, it overrides the local keyboard by not passing the signals through.
Finally, there is a little white 4-pin ``CD-Audio'' connector at the far end of the card which is the ``Virtual Power Button'' (VPB) connector. This is the useful one...
Note: The card doesn't know or do *anything* with the motherboard reset--it only uses the ATX power-button.
This four pin cable has the following layout; pins 1 & 4 (top and bottom) are bridged together and used to detect the presence of the cable. If the cable is detected, the reset and power-button option pages within the web-interface are enabled. Pins 2 & 3 are then connected through a relay on the board.
Bridge top and bottom pins (cable detection)
Attach middle pins to ATX [Soft] Power Connector
___
| . | 1 <-+
| . ] 2 <-|--------> ATX Power these two are bridged by the relay
| . | 3 <-|--------> Connector
| . ] 4 <-+
|___|
Reseting the machine through the Lights-Out card is achieved by toggling the relay (bridged across the ATX soft-power button pins (the Button on the front of the machine). The patterns are:
| Power On | 0.5 seconds on | Normal power-on |
|---|---|---|
| Power Off | 5 seconds on | Forced power-off |
| Reset | 5 seconds on; 2 seconds off; 0.5 seconds on |
Forced power-off, Pause Normal power-on |
| Controlled Reboot | 0.5 seconds on | Software power-off (eg: Needs OS) |
The Compaq/HP Lights Out card is a standard video card (it has a VGA port on the back) but also has a network port. An alternative, the eRIC is a half-length PCI card, which regardless of other considerations has the advantages that it fits in short (300mm-600mm depth) rack-mount cases with less problems.
The second card out there is much more about making a PeeCee work like a Sun or Apple box, in that you can get full system control to the BIOS/Prom level through the serial port. It doesn't provide a network port, but is designed to be hooked up to a terminal server to provide the remote access transport.
The Lights Out cards are both in the category of management cards that can handle and transmit graphical framebuffers. They can cope after the video card is switched out of text-mode (for example, after Windows NT boots; or an X-server / VESA framebuffer mode is used under UNIX).
From what I've seen, Compaq must have produced some cards that were only able to handle 80x25 VGA text mode. These I think were branded as simply "Remote Insight" boards and may actually prove to be more useful for Linux since they don't appear to mess about with anything to do with silly Java/HTML interfaces and just have an external RS-232 serial port.
Any information gratefully received. Any spare cards received, doubley so.
The real problem with these cards is that they unnecessarily use a lot of Javascript and Java everywhere. Annoyingly, where it is completely pointless;
The original Lights Out Edition uses a Java Applet to RSA hash a username and password with a session key produced by the card. This is then stored in a Cookie and transmitted back to the card with every futher page access, until the session times-out (15 minutes of inactivity).
The Edition II uses a similar setup, but this time the MD5 hashing is done by a massive piece of Javascript sent in the inital login page. The two cards use a further Java Applet to display the console or GUI on the remote machine.
Both cards feature `iPAQ' handheld access to a limited set of
the features (basically all the logs and the reset/power options,
that don't require the full Java VM. The original ``Edition''
uses plain `.htaccess' over SSL (aka HTTP Basic
Authentication), whereas the Edition II still insists on
using a Javascript-generated cookie for authenication, even in
Handheld mode.
Lets recap that. The browser connects to card using secure
HTTPS; then downloads a Java applet that runs locally on the users'
machine. The applet then connects back to the card using an
unencrypted TCP connection to the telnet
port (23).
Personally, I think the designers were too busy worrying about the splinters to notice the gigantic plank of wood aready there. The silly Cookie business is just hassle and pure ``Snake-Oil''.
There is alot of marketing acess about being able to use an
iPAQ PDA (also manufactured by Compaq and running PocketPC/WinCE).
There doesn't appear to be anything specific to the ``iPAQ'' part
of it, other than Compaq happen to manufacture them. After a bit
of hunting there is indeed nothing specific and the card is merely
checking for the presence of the string
``Windows CE'' in the `User-Agent:'
HTTP header passed by the requesting browser.
The easiest way to tell whether you are logging-in from a handheld (um, piece of M$ Wince) is to check the index page on the plain HTTP output from the card (the one that normally directs you straight to the HTTPS secure login). The wording changes slightly and includes the phrase ``Please Tap here to login'' (instead of ``Please ClickUser-Agent:'' string in a couple of Linux browsers.
The simplified pages still insist on using some javascript
(like dynamically writing the <form> with the button you
can click to continue!). I used Lynx for my initially debugging
which allow its identity to be set:
$ lynx -useragent='Mozilla/2.0 (compatible; PIE 0.6; Windows CE)' http://riloe.card/
The is also a strange `hang' and the page never quite finishes
downloading without the `-source' parameter. I'm
wondering wether the HTTP server on the card is setting the
`Content-type:' is something strange as Lynx is
complaining.
I got slightly further with Konqueror, the Browser written for
the KDE desktop, which also allows setting arbitrary identities
and in addition has Javascript support. I have some screen-shots
showing what I discovered in the ./screenshots/
directory.
My ultimate hope is to workout what I can minimally preform
with `telnet-ssl' or `lynx-ssl' to effect
a reboot by jumping directly to the CGI page that is responsible
for the reset.
It is one of those things they could have left really simple and easier and instead decided to over-complicate; and then add hacks so that specific lower-spec devices could access it. Keep It Simple Stupid.
The cards only eat CRLF, the Windows-style line-ending sequence
(ASCII 0x10, then 0x13) which is somewhat annoying as both the MS
Telnet application and Putty running on Windows work fine, but
when using any Unix client it is not possible to get past the
login phase, although once in it works fine. No amount of
`mode crlf' type fiddling will make it work; the only
kludge I have so far is:
$ (echo -e 'Administrator\r\nXXXX\r\n' ; cat) | nc 192.168.0.1 telnet
This of cause can't send control characters, nothing fancy can
be sent although you can log into a `getty' login
prompt and run a couple of commands from the shell.
This is still useful: I have used it whilst working a colo'ed machine in a data-centre by plugging a [Happy Hacking] keyboard into the PS/2 ports on the motherboard and then using a small Libretto as an output device over the network. In this case it's quite amusing that the keyboard was bigger than the monitor!
I wish they'd just implemented SSH, or even SSL'ed telnet. I would have really like the ability to send a hot-key to activate a menu with the reboot options. The hardware is *perfect*, I really wish I boot some alternative, decent firmware on it for I would to do--which is use Secure Console access, access the Pre-OS BIOS config like I can do on a Sun box and have a forced reboot option.