Re: Re: Shares on sleeping MacOS X machines

On Wed, Aug 04, 2004 at 02:22:21PM +0200, Peter Gutbrod scratched on the wall:
> Wake on LAN (with the OS X apps Wake550 or WakeUp) works on my LAN with Macs
> and PCs (Windows, Linux). I didn't try it over the internet so far.

  Wake-on-LAN depends on knowing the system's Ethernet MAC address.
  It is pretty trivial for systems that are on the same subnet to
  discover this, but this information is not easily available to
  systems on a different network.  You can still generate a
  Wake-on-LAN packet from an off-network system, it just has to
  discover the MAC address somehow (e.g. have someone type it in).
  The question is if that packet will be delivered.  Some routers won't
  pass a packet on to a sleeping host, since it can't properly ARP for
  the MAC address.  It depends on how stale the ARP cache entry is
  (e.g. how long the machine has been asleep), and what the router's
  cache-flush policy is.

  This makes it (sometimes) possible to use Wake-on-LAN from a different
  network (e.g. across the Internet), it just isn't easy to do-- you cannot
  use Wake-on-LAN to DoS a remote network, for example, unless you have
  prior knowledge-- and even then, there is some question on if you can
  do it or not.

> In good old OS 9 there were two wake up checkboxes in the energy control
> panel, "wake on administrative network access" and "wake on network access".

> Another idea would be using an ethernet/USB device (kind of switch), that
> listens for network access requests to the sleeping Mac and, in case there
> are any, wakes the Mac via the USB port (or via WOL). That device probably
> could send some initial information back to the requesting machine to
> prevent a timeout. Someone should invent this device in case it doesn't
> exist yet ;-)

  The basic problem with all of these schemes is that there is a lot of
  network access you don't care about.  Most networks send a sizable*
  number of broadcasts-- it is a normal part of network operation.  I
  suppose you could choose to ignore broadcasts, but many unicast
  transactions start with a broadcast transaction (ARPing for the MAC
  address-- remember, we are talking about a machine that can be
  assumed to be asleep for some time).  There's also the problem of
  scans (both virus and such, but also stuff like AppleTalk and service
  discovery protocols). 

	* sizable in the sense of "packets per hour", not in
	  terms of total bandwidth

  I suppose such a system could be built, but the rules for what you
  consider "wakeable" and what aren't would be pretty complex.  You'd
  also need a semi-operational network stack, so you couldn't really
  truly put the machine to sleep.  Using an external device, like a
  USB dongle of some kind, introduces a lot of other problems, like
  switch port isolation and MAC address cloning and stuff.  Its a lot
  harder than it sounds.

  I think the real solution is better power management on the host
  machine.  If you want the machine really truly asleep, it should be
  asleep and it should be fairly hard to wake.  If all you want it
  something that will go into a low-power mode, you really just want a
  highly efficient machine that is capable of shutting disks down and
  idling the processor back-- features found in most modern laptops.

    -j

-- 
                     Jay A. Kreibich | Integration & Software Eng.
                        [email protected] | Campus IT & Edu. Svcs.
          <http://www.uiuc.edu/~jak> | University of Illinois at U/C