Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools

Other Reviews

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.

Boot screen

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.

BIOS access

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.

More Stuff

Wi-Fi System Tools
Check out our Wi-Fi System Charts, Ranker and Finder!

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

Continuation of. . .
Hi all, I'm hoping someone can help. My Google Wifi (GW) mesh performance has slowed ton a crawl lately. Even with all the pucks in the same room, I w...
I read in another thread that updating to a newer firmware fixed the issue, which seems to be that dnsomatic switched to https only updating. In the l...
v2.5.1 Updated 2020-05-10 Run an NTP server for your network. Graphs available for NTP accuracy on the Addons page of the WebUI.Inspired by kvic's p...
This thread is for the discussion topic : unbound_manager script. As per the GitHub Hints/Tips: Differences between the operational modes​ E...

Don't Miss These

  • 1
  • 2
  • 3