NASLite Network Attached Storage

Hello all forum members:

Almost exactly one year ago I wrote a script that became a sticky. ( "SCRIPT for Proper Manual or Automated Shutdown" posted at http://www.serverelements.com/phpBB2/viewtopic.php?t=810 )

It's time for a sequel.

I have created a new script which runs on WinXP and can Turn ON your NASLite system -- if your motherboard (and although I have not tested this, it should work with an appropriate PCI Ethernet card) supports WOL (Wake-On-LAN). I combined it with the script from a year ago (NASLite shutdown) -- which still works for version 2.04 as well as it did when I wrote it for NASLite+ v1.5. I call this ability SysRC (System Remote Control). It can also wakeup a WinXP system (with minor limitations), and I plan a future extension that will also shutdown a WinXP system.

The script can be run interactively and provides a GUI for the user, but it also runs in batch mode triggerable from Windows TaskScheduler. It took quite a bit of debugging time ... but now what happens at my place is ... once-a-day, TaskScheduler wakes up my second NASLite which is configured to perform a Mirror of my first NASLite server, then after some sufficient (pre-determined) time TaskScheduler shuts down the Mirror system. All unattended ! (The actual Mirror performed daily by NASLite rsync takes only a few minutes for the daily file changes on the main server.)

The script runs to 832 lines (half of which is documentation or blank lines for clarity). A very compact third-party auxiliary EXE program is needed to send a "Magic Packet" for the WOL function, and a simple TXT file containing a system list is also needed. I will hold off posting this new script (and associated files) for a few days until I get clarity about where/how to make this script available to everyone in a most convenient manner. ( I do not have experience uploading stuff like this ... when I did the original script a year ago it was short enough for simply posting within the associated thread. Any suggestions are appreciated ... and I'll hold off for some of our members' collective wisdom how to handle this the best way ... assuming other members are interested in this feature. Eventually it might even become another sticky )

What say you ? Is there interest in this feature ?

Georg

Bring it on..... please.

Absolutely!! Can't wait jeffjohn

Ok guys,

georg has kindly allowed me to give his scripts a home.

Go get them http://www.nasbox.me.uk

I am sure georg will be awaiting your thoughts.
please direct questions to georg in this thread.

thanks

georg / gaiden ... thanks for the script and hard work and thanks for the professional posting. I'm looking for the Roseta Stone regarding WOL. I understand the "what and why", I'm fuzzy on the "how". Questions: (1) How do you enable WOL on a PCI NIC already seated in a NASLite server? Move it to a Windows PC and enable it there? Or can it be done from NASLite? (2) When you enable WOL in BIOS it waits for the "magic packet", then wakes up ... how do you put the system to sleep in NASLite? Just power down normally? (3) Any other questions I sould have asked and just don't know about?
Thanks (as always).
Jim

Hello Grumpa

Good questions all around ... let's see if I can help.

1] I have no experience with PCI version of NIC (with a working WOL). But I'll try anyway. If the card is a type that has to be specifically enabled (or disabled) it should come with a driver disk (floppy or CD), and it may be bootable. So ... no need to move the card to another system. An alternative might be to use Knoppix or other Live CD Linux to boot from, enable the card, then reboot NASLite. Possibly you could also create a custom UBCD4Win to do something like this. I am curious enough about all this that I'd be willing to purchase a WOL-enabled PCI ethernet card to monkey around with. Could someone suggest one ?

To enable WOL from NASLite ... we need Tony or Ralph involved.

2] "Putting to sleep": There really is no option to do so at the moment. Instead you would do a Shutdown: a] with my script; b] push the power button (if you have version 2+); c] telnet and go through the admin menu manually. The WOL would be a complete-from-scratch fresh boot. There are other posts discussing spin-down of the hard disks to save power (and prolong life of the disks). There are many pros and cons. Serverelements could, I suppose, implement a "sleep" function, just like in Windows (standby or hibernate). But my personal opinion is, very little is gained with a NAS system. In Windows that is different. Because of the lengthy boot-up process with Windows, and because a desktop is something you're sitting at wanting to respond quickly, coming out of "sleep mode" quickly is a valuable feature. Although that might seem valuable too for a "storage" system, I don't think it is practical. The bootup process does take time, but it's not so crucial. And if you were looking to come out of "sleep" in a matter of 3-4 seconds so that you could resume a file write or read or data-base update ... that might either not be possible or be too hard to implement while guaranteeing full stability (keeping track of what files were open etc). Those other posts discuss a lot more details as to pros and cons.

3] I don't know ... try using the script if you haven't already (and have a WOL NIC). That might generate a few.

Appreciate your thoughts and questions ...

Georg

FWIW I've set this up and it works great!

I have a PCI nic on my old abit atx mobo. Its a cheapo realtek NIC (8139 I think) that I noticed had the 3-prong female plug on it that I assumed was for WOL. I checked the BIOS on the mobo and there was an option for WOL as well as a 3-prong plug on the board itself next to the PCI slots.

I just happened to have one of those WOL cables from an old Compaq PC that fit the nic and mobo plugs perfectly. There must be an accepted standard for these.

After that I ran the script SysRC.hta after I modified the SysRC_SysList.txt file to reflect my nas-lites mac and IP and BINGO! Works great!

From the hta utility I can shutdown to a totally shut down state and boot it up from that same state to fully powered on. Interestingly, just for curiosity after I shut down the server from the utility I unplugged the power cable and hit the power button a couple of times to clear out the capacitors (or whatever) then hooked it back up and tried to turn it on and it didnt work. However if I shut it down remotely and dont touch it, it boots up fine. I can only assume that there is some residual power thats needed to detect the magic packet. When I power down remotely it certainly LOOKS like its 100 percent off (no fans, lights, noise, nothing) not sure.

Anyway it does exactly what I want now. Im setting up an option on my homebuilt DVR (snapstream) to turn on/off the NAS-Lite server for when I want to use it. That way its not running when I dont need it, which is most of the time.

Thanks much for this, its really cool!

risk1994:

Thanks for your report -- appreciate the detailed extra info.

Interesting info on the residual power/capacitor ... I am wondering if the "residual power" eventually does discharge completely while connected to AC, and if so, how long that takes ( a few minutes, hours, days ? ). If you don't mind running a test or two and reporting back, that would be great. Of course, a different PSU may give different results. ( I am currently out of country and can't test my own systems. )

Glad you like it ...

Georg

Yes, that was my plan. Im going away for 5 days. Im going to power it off via your script, then power it back on the same way when I get back. Very curious to see if it will work.

I suppose a different PSU could work but I dont see how, If the mobo needs some kind of power even when off for WOL to work, pulling the plug should make it fail regardless. I wish there was a more detailed explanation out there for wol's requirements.

Regarding that "residual power - capacitor - what have you".

Try this - power the system off, and immediately wake it remotely, to make sure that the WOL works, and then power it off again and leave it for an hour or so, with the power connected and then try to wake it a second time.

If it wakes, the problem may be power related, if it doesn't wake then it's caused by a flaw in the WOL implementation.

Here is where I'm coming from -

If the WOL is not implemented properly, it may work immediately after the system is powered off, but not if the system has been off for more than a few minutes. This is caused by the WOL packets being sent to the host using it's ip address, rather than as a hardware broadcast.

The explanation of the how and why and perhaps how to fix is fairly complicated, it's a combination of network basics, tcp/ip networking and WOL - so let me know if it wakes or not - and then I'll go into detail.

I did this, the first time, I powered off then on within a few minutes via WOL and it works fine. Then did the same with an hour wait and the machine didnt turn on.



This makes sense. Although I tried manually waking the machine (after the hour wait) with mc-wol.exe and the mac address and still no luck. Any way you can think of to work around this fordem? FWIW the nas is on a static IP set at my router and the nas itself.

Hello risk1994 & fordem:

Ok ... I'm back.

In fully remote mode I don't have any troubles over 24 hour period (the server is off 23 hours and on for 1 hour each day). Both WOL and remote-shutdown are completely automated ... I never even go near the server in the closet. It looks like in the original post (Tue May 01, 2007 8:46 am) that risk1994 is similarly successful. So I assume when you say "Then did the same with an hour wait" that you mean manually powering it off with the power switch. I will run some tests tonight to see what happens if I disconnect the power cable (simulating a variable length of time power outage) and report back.

But for now I want to point out a couple of things. a] With mc-wol.exe I have never used anything other than a MAC address. I don't use IP addresses with this command -- don't like to rely on routers, etc. b] risk1994 should repeat the "after a few minutes" and "an hour wait" tests with the 3-pin WOL cable removed. Of course, the system may not wake without the cable, but if it does, then the cable may be a contributing factor.

More later.

Georg

I dont know what you mean here. I shut down with WOL then woke up with WOL 2 minutes later, that worked great. Then I shut down with WOL and attempted to wake with WOL 1 hour later and it wouldnt wake. Never used the power button at all...that was the whole point.



I removed the 3-pin WOL cable. I then shut down with WOL then woke up with WOL 2 minutes later, that worked great. Then I shut down with WOL and attempted to wake with WOL 1 hour later and no luck, wouldnt boot. Looks like no matter what I have tried, if its off for an hour or more WOL wont turn it back on.

risk1994:

Thanks ... that helps. Sorry ... my confusion ... when you first refered to "I powered off then on within a few minutes via WOL", because your earlier May 1 8:46am post seemed to indicate you were happy with my script ... I assumed you were not using my script this time around.

You did report using mc-wol.exe in standalone mode without success. I read over your May 09 6:07 am post a second time ... apparently you did use MAC address (not IP address). And since the cable seems to be unnecessary, I can think of three possibilities: 1] as fordem suggests, incorrectly implemented WOL (on the NIC or the BIOS or the motherboard), or 2] the cable IS necessary but incompatible or non-functional.

fordem ... any comments or ideas ?

Georg

The problem usually lies in how the WOL magic packet is sent.

Many years ago I did extensive research into how WOL worked and discovered that several common WOL utilities are poorly written and documented - they ask you for the MAC and ip addresses, and most people assume that they need to enter the MAC and ip address of the host they wish to wake - one that I have then repeatedly pings the ip address provided until it receives a response, after which it tells you that the host has been successfully awakened.

What actually needs to be entered is the MAC address of the host to be awoken along with the broadcast ip address of the LAN segment the host is attached to - the WOL packet MUST be sent as a broadcast.

That's the how to make it work - you can stop reading here. If you want to know the why it didn't work, read on.

Data transmission on a LAN is not done using ip addresses, it uses MAC addresses. The ip stack compares the destination ip address to the ip address of the transmitting host (the source ip address) and the subnet mask, to determine if the destination is local, in which case it sends the data directly to the destination host using it's MAC address. If the destination is remote, the transmitting host will send the data to the default gateway, using the MAC address of the default gateway, for onward transmission.

How does the transmitting host know what the MAC address of the destination host is? It doesn't. It sends a broadcast packet known as an arp request - essentially asking "who has ip address aa.bb.cc.dd?" and the host with that address answers - the transmitting host now knows what MAC address to use. The transmitting host also stores this information in it's arp cache for future use. If the transmitting host is sending a broadcast, it will use a broadcast MAC address (FF-FF-FF-FF-FF-FF)

The receiving host sees data traffic and examines all the traffic it sees looking for it's MAC address in the destination address field, if it sees data addressed to any MAC address other than it's own OR the broadcast MAC address, it discards the data - if it recognizes it's own address, or the broadcast address, it passes the data up the stack for further processing.

If the two hosts communicate with each other frequently, both of them will always have the necessary details in their arp cache and arp requests will be unnecessary - but if the communication stops, after a period of time, the information will be considered stale and flushed from the arp cache.

This flushing of the stale information is what causes WOL sent to a specific ip address to work for short periods of time and fail when longer periods are involved.

When the MAC address/ip address pair is in the arp cache of the host sending the WOL packet, the host has a MAC address that it can use to transmit the packet - when that information has been flushed, the host, not having a MAC address will send an arp request, and because the host with that ip address is not powered up, with OS loaded and ip stack functional, it will not respond, and the transmitting host will discard the WOL packet.

If the LAN broadcast ip address has been entered, the host sending the WOL packet, having compared the ip addresses and the subnet mask, it will know that the packet is a broadcast packet, and will not use arp to find a MAC address, it will send the WOL packet using the broadcast packet.

All the hosts on the LAN receive the packet, but only one will recognize the "magic" sequence in the data field and respond by sending the wake command to the system board to power on the system.

BTW - this "magic " sequence is nothing more than the MAC address of the card repeated sixteen times consecutively - a properly constructed magic packet will be a data packet containing the MAC address of the transmitting host in the source address field, the broadcast MAC address in the destination address field, and the MAC address of the host to be awoken, repeated sixteen consecutive times in the data field.

One last comment - the above explanation is a simplified one - entire sections covering how WOL works if the WOL packet is not being sent on a local network segment, but is being sent across a wide area network of some sort, where it will have to traverse one or more routers, have been omitted.

Using WOL across a WAN can be done, but is not a trivial task - it requires not just the hardware to be configured, but also the routers and firewalls and most consumer routers and firewalls specifically omit the necessary features for security reasons.