NASLite Network Attached Storage

fordem:

Wow ! And THANKS ! (Great "teaching".)

Ok ... I understand most of it (except maybe the part about why an arp request would be required on a local LAN if the MAC of destination is already known). Now ... how can we help risk1994 ?

In my script the function used to WAKE the server is implemented by a program called "mc-wol.exe" which I found after some search on the internet (http://www.matcode.com/wol.htm). I can't speak for the quality of that program, since I did not create it. But it has worked fine for me on my local LAN specifying MAC only (without providing an IP -- which (per its documentation) is not needed for local LANs). Since the system to be woken is OFF, I am not sure its NIC even knows what the system's IP is (assigned after NASLite boots). It only knows its MAC (hardware coded in the NIC).

fordem please correct me, but I would assume that the IP may not have to be known to the card -- only to routing equipment for non-local WOL. I don't know if "mc-wol.exe" properly implements what fordem has written (broadcast, etc), but it has worked across a large variety (a dozen ?) of built-in NICs for me. I have woken both WinXP and NASLite giving only MAC. I do not have a PCI NIC to test, and am not sure if the WOL behaviour varies in that case. But I have to assume that the program is relatively well written (at least for local LAN) due to my successful testing.

If the IP is not required, and if the program correctly send a broadcast, then either the NIC is not correctly listening (implementing) the requested WOL, or a few minutes after prior shutdown there is insuffcient power to the PCI NIC (whether via the bus or the 3-pin cable).

Another scenario (if the IP is required): I don't kow if NASLite "tells" the NIC what the IP is after booting. Then after shutting down (as opposed to a sleep state) when the NIC "hears" the WAKE request after the first few minutes, it is also possible that the NIC has "forgotten" the IP (or it is cleared out by some other network activity from a master browser ("flushing of the stale information") ??), and does not wake, because it no longer has its IP to compare to one that it expects to be supplied in the magic packet.

UPDATE: I have now tested the server after disconnecting the power cable for 20 minutes (simulating a power-outage), but I did not "discharge capacitors" or otherwise touch the power button). SURPRISE ! SURPRISE ! The system did NOT wake as normal using "mc-wol.exe". However, the front-panel power LED did come on. Additional WOL requests did not help; only pushing the power-button started the POST and boot process. The next step was to see if a BIOS power setting has anything to do with the problem. ( I generally set the BIOS option "After Power Fail" to "Remain Off" as opposed to the alternative "Former Status". ) Changing this option in BIOS to "Former Status", power-button off, then disconnecting power cable for another 20 minutes ... when I re-connected the power cable the system booted, which is not a good test. I will run some more simulated power-outages (and also mess with ACPI settings) and report back again. (My apologies to users of my script ... simulating a power outage had not occured to me during testing.)

So in summary: my server wakes normal 23 hours after remote shutdown using the "mc-wol.exe", but does not (yet) deal with a power-outage. risk1994 NIC does not wake after a few minutes.

More later ....

Georg

Thanks much fordem, excellent explanation!



This MUST be what it is, it describes whats happening to me exactly and it makes perfect sense.



I understand what your saying, you were correct that I had my clients IP entered in the SysRC_SysList.txt but I wasnt sure if that IP was actually used for the wake part. As a test, I shut down the nas with WOL, waited 1 hour then tried to wake using mc-wol.exe in command line....

mc-wol.exe <mac address> /a 192.168.0.255

I had hoped that adding the IP with the 255 at the end would tell the mc-wol app to send it as a broadcast but no luck...it didnt wake up the PC.

Im wondering if I need a different app to transmit the packet the proper way, either that or there really is an issue with my power supply, but I tend to think its the former.

Testing Update:

1] An Intel motherboard will wake even after 15 mins simulated power-outage (power cord removal), but two different SuperMicro server boards (with NASLite) will NOT under those conditions. ( I tried playing with a bunch of power/APIC/ACPI options in BIOS. I should add that the Intel mobo is a WinXP system which shuts itself down (not sleep state) nightly via TaskManager. )

2] All three systems respond to WOL as desired after extended (several hours) shutdown SO LONG AS power is not removed ( I have all systems on UPS ).

( All three systems have on-board NIC and same PSU manufacturer (slight differences in wattage). Only the Intel mobo has BIOS options for WOL, but it does not use a 3-pin cable. )

Scenario 2] above is really what I am after, and for those purposes the "mc-wol.exe" applet works fine. I am unable to duplicate risk1994's problem where WOL fails after a few minutes, even if power is NOT removed.

As to risk1994 post above:

a] In my opinion, the info should not be "stale" after two minutes.
b] Yes, my script uses the MAC address for WOL (and only the MAC address) that is listed in the SysRC_SysList.txt for that system. The IP is used for NASLite shutdown (with telnet) and PING to check status.
c] I rely on mc-wol.exe to do its thing correctly (broadcast for the LAN segment) INTERNALLY in its code, and the command you show I don't think is valid, if I understand correctly how mc-wol.exe works. I think the /a parameter needs to specify the actual destination IP without taking into account masking of the IP octets.
d] If you (or I) find a different (free) WOL applet I'd be happy to try it out and incorporate it into my script. I can do the testing with simulated power-outage on my systems, whereas risk1994 can do testing on the PCI NIC.


CONCLUSION: the Motherboard and its BIOS options is a definite variable that can make a difference.

SUGGESTION: risk1994: try a different mobo ?

May be fordem has some more ideas at this point.

Georg

Ok - let me try to clear up a few gray areas.

Georg -

There is no reason for an arp request if the MAc of the destination is already known. However, there will be a first transmission after the host is powered on when that information is not known, and an arp request will have to be done, similarly, if there is no communication between hosts for a period of time, the unused entries are removed from the arp cache - I did a crude test with Windows XP and it appears that the time frame after which stale entries are removed from the arp cache is just about two minutes.

As you point out MC-WOL - as per it's documentation - does not require an ip address to be entered, I believe this may be where risk1994 is getting into trouble.

You are correct in stating that when the system to be woken is off, the ip address is not known

With regard your testing - onboard NICS will never require the 3-pin cable, that is only used with early PCI spec equipment - later PCI spec provides the +5v standby power directly through the PCI slot.

The motherboard and BIOS options do play a great part in WOL, I don't remember all the power states, but there are either two or three different low power modes, in addition to the fully off, and not all systems support wake from all of them.

Alright, I tested a "newer" server that I have with a built in NIC and newer power supply. This one runs windows, so after a normal shutdown (start, shutdown) I waited over 1 hour and tried to start using mc-wol and it started up fine.

Since the mobo of my nas box has a Wake on Lan option in the bios I'm guessing its not the issue. I'm thinking its not getting the power it needs from the power supply. I noticed the box that works has a light that glows green even when the server is off, the Nas box doesnt do that, the led is off when the server is off. Ill switch out the PS and let you know what happens.

Thanks much to fordem and georg for all your help. Its been an informative and fun little project.

Risk

risk1994: Take a look at "http://www.serverelements.com/phpBB2/viewtopic.php?t=1870".

A new version (1.10) of the SysRC script is nearly complete and I'll attempt to have Eden post at his page (http://homepage.ntlworld.com/lou.greyfaulk/ in the Scripts section) by tomorrow (5/31) if he is able.

Changes:
1] Fixed a Vista issue (won't run because Vista breaks a function call).
2] NEW FEATURE: you can include a password, either on the command line for the single target system (to be shutdown via telnet) or in the text file that lists all your systems (different password for each if you like).

Georg

As soon as the file is ready I will make sure its online.

its ready, http://www.freenas.info scripts section.

Version 1.10A: Bug Fix update: (Will upload shortly.)

1] "NAS_SHUT.vbs": Disabled EXIT & enabled SHUTDOWN. (Accidental left-over from testing phase. ) (THANKS tony_a !)

2] "SysRC.hta": Increased DELAY from 1000ms to 2000ms. (Occassional issue on VISTA system.)

Georg