Lantronix SecureLinx Spider Review: Tiny, powerful IP KVM

In Use - more

We’ve connected and powered up the Spider, and it works as advertised. Let’s try out BIOS access. BIOS access for most motherboards is a matter of hitting a key (on my host, it is the Delete key) during the power-up/boot sequence. To do so remotely, we need to tell the host to power cycle, be able to see the screen changes on the host, and then hit the Delete key at the appropriate time. The SLS Remote Console makes this easy, exactly as if you were in front of the host machine. 

Choosing Windows’ Start, Turn Off Computer, Restart triggered a normal reboot. From the SLS Remote Console, you can watch Windows on the host machine shut down, and then start the boot process. From there, you can go into the BIOS, exactly as if you were there. Figure 9 is a screen shot of my host server during boot up, taken from a remote PC. Notice that the BIOS screen is within a browser window, showing that I had access to the target machine’s BIOS from my laptop.

Figure 9: The remote machine booting up, as seen through the Spider

Everything is as if you’re at the keyboard of the machine you’re working on. Hitting the Delete key put me in the BIOS (Figure 10), and I had full normal access to make any changes I wanted, just as if I was on the local keyboard.

Figure 10: Accessing the remote machine's BIOS through the Spider

Since the Spider is powered by its host, I was curious how the device functioned during reboot of its target host, so I ran a little test. I initiated a reboot of the server while running a continuous ping (ping <ip> -t) to the Spider’s IP address to test whether the Spider lost connectivity when the server rebooted. The Spider stayed online through the whole reboot with only one or two dropped pings through the reboot cycle. Its indicator lights remained lit, as well. It appears the device can sustain momentary power interruptions without losing its memory or connection.

Doing a shutdown of the server is a different story.  Turning off the server results in the Spider going down, including its Ethernet ports. Without power from its host USB connection, the Spider is down, and so is its Ethernet switch. Thus, downstream devices connected via the Cascade port are inaccessible. I verified this by plugging in a live Ethernet device into the Spider’s Cascade port while the target server was down, and could get no link lights or connection. As soon as the target server is powered up, the Cascade port comes alive again.