On Sat, 19 Sep 2009, Garrett D'Amore wrote:
> The biggest problems I see with Wake-On-Lan:
>
> 1) Not every chip supports the same magic-packet to wake up. Some don't
> use a packet, but rely on link status changes!
NIC's that are WOL capable all support the "Magic Packet" definition
(six 0xff's followed by 16 repititions of the "target" MAC address).
Some, however, do have link change WOL and allow for a programable
"Interesting Packet".
> 2) Many (most!) magic-packet formats are not routeable. Many of
> them don't include
The "Magic Packet" format is in the payload, and routability will be
based on the headers, and interesting packet would likely be a typical
network packet. There are, though, ARP considerations (only slightly
touched on below).
> 3) I know of no network gear that can automatically tell that a system is
> down or hibernating and send a magic packet to wake up a system. (Not saying
> such gear doesn't exist, just that I don't know of it.)
This, however, is true. From a network, there is no way of knowing
if it is asleep, off, or just disconnected. The only thing that
*might* know, is the thing that put it to sleep in the first place
(Data Center Management software *could* be written for this purpose,
but I haven't see anything yet for this space).
> 4) Hence, apart from special use cases, on private networks, magic-packet
> is basically useless. You can't use it with hibernate or sleep to
> automatically suspend machines and wake them back up when they need to be
> servicing work.
For the request of keeping standby machines, I suspect that these
would be on a local network (or at least one that, in theory, could be
configured to route the packets), and could be as usable as network
power switches. But WOL in itself will not suspend a machine, and can
only be used to wake a sleeping one.
>
> Without #4, there is no tangible use case. Item #4 IMO requires special work
> -- it requires the NIC to recognize directed ARP traffic and use such to wake
> up the machine. Because of #1 above, this doesn't work usefully with current
> equipment.
So ARP is the interesting issue here that makes WOL not too terribly
useful. I can configure a card to wake on an HTTP SYN packet (already
done this - and in Solaris), however, if the ethernet address of the
sleeping machine is not known to the waking machine *or* the routers
in between, there will be an ARP request to which there will probably
not be an answer as the "waking packet" is never sent (or multiple
wakeups occur as the machine is waking on the ARP packet, and never
sleeping).
For Magic Packet to work, it would need to be a broadcast packet so
that there isn't an ARP. So for the most part, it is little more than
an experimental feature looking for the infrastructure that can make
it useful.
>
> If folks are using Wake-On-Lan with Windows or Linux or other platforms, I'd
> like to hear a lot more about the use cases... I'm not adverse to spending
> time to make this work better, but until I understand what people want from it
> (and whether hardware can achieve it), I remain rather conservative about
> spending time implementing WoL.
I too would like to here the use cases. As of yet, all I have been
able to get (which is why I don't push it more), is that this is some
checkbox on someone's list because the EPA says it should be. I am
really unaware of anyone who is actually using it in production (even
the "experimental" case menioned previously showed that there were
real problems with deploying it).
>
> The use case that I think most people want is #4. (Let your fileservers go
> into sleep mode until they are called upon to perform some real work...)
If the infrastructure issues were ever resolved (and FWIW, SP's on
the same network could help solve this), I see an excellent case with
webservers configured with interesting packet filters (the HTTP
packets described above). If in and out of S3 were quick enough, let
a machine sleep between visits. A user would only see a little delay
on the first access (and from personal experience, they might anyway
and just think it were extraneous network latencies). While sleeping,
the machine is saving 95% of it's runtime power.
But I am not holding my breath (but would be one to revisit should
the use cases both you and I are looking for).
>
> - Garrett
Cheers!
---- Randy
_______________________________________________
networking-discuss mailing list
[email protected]
