This is one of those problems that can be solved with new and shiny hardware, like Intel's NICs that can wake based on the first 128 octets of a frame. But, Freesco is a floppy-based router: "new and shiny" doesn't even use floppies anymore.
I also have selfish reasons for wanting this feature, but I don't think I am the only one. Yes, I know I can log into the router and send a magic packet using the wakelan_1.1_dingetje.pkg, but it is too inconvenient for daily use.
I am still trying to set-up a fileserver. Just recently, FreeBSD added WOL support for the NIC I am using. Ideally, I want the server to shut itself off if there were no client computers seen on the network for about 40 minutes, then wake up when a client gets its IP address from the router (DHCP broadcast). Thing is, the card is so old it only supports the "traditional" WOL packet with its MAC address repeated several times. Last time I checked, the server draws 37W idle, 3 watts off. While not huge compared to the 33 watts for the router, modem, and switch; the power savings would make me feel better about my computing hobby ^_^
Proposal (remote case)
- Freesco receives a packet to be forwarded to a computer on a LAN.
- Freesco, having not seen any computers active on the network for about an hour, sends an ARP request asking who has the target (Internal) IP address
- While waiting for a reply, Freesco holds the received packet while decrementing the TTL field every second.
- If no ARP response is received within 5-8 seconds, Freecso uses the MAC address listed in the static DHCP leases to send a "Magic Packet".
- When the sleeping computer wakes up, it sends an ARP request to make sure it still 'owns' it's address (RFC 5227)
- Upon seeing activity from the destination host, Freesco releases the received packet: if it has not expired.
Proposal (local case)
Freesco can can be used to "upgrade" "standard" WOL machines to "advanced" WOL machines able to wake based on any broadcast. Note that the fancy card mentioned above can respond to a unicast (layer 2) frame the the router may not be able to see.
- Freescro keeps track of the last time various hosts (MAC addresses) were seen on the LAN. Freesco has been configured to "know" how long it takes before the machines may be asleep.
- If any machine is suspected to be sleeping, Freesco examines every broadcasted frame (or packet) for a (per-host configurable) "wake event".
- If Freesco sees a "wake event" for a host suspected to be sleeping, a "magic packet" is sent. A configurable per-host sleep timer is used to control the number possibly spurious WOL packets.
Some relevant references
I found reading a few RFC's instructive. For example, I initially wanted to abuse the initial 3-way TCP handshake for setting up a connection. However, RFC 1122 says:
1.1.2 Architectural Assumptions
. . .
( b ) Gateways don't keep connection state information.
To improve robustness of the communication system,
gateways are designed to be stateless, forwarding each IP
datagram independently of other datagrams. As a result,
redundant paths can be exploited to provide robust service
in spite of failures of intervening gateways and networks.
I also realized that the TTL field is at the IP layer: by holding the packet at the IP layer, you get TCP, UDP and ICMP for free.
Requirements for Internet Hosts - Communication Layers
Ethernet Address Resolution Protocol
IPv4 Address Conflict Detection (Proposed Standard)
Possible Challenges
I think my proposals would be messy to implement. My proposals involve either a diluted Static DHCP lease configuration file, or several inter-dependent configuration files leading to configuration errors.
Another possibility with the LAN monitoring proposal is possible problems if more mulitcast bandwidth is used on the LAN than the NIC on the router can handle. I'm sure such a situation may cause problems anyway

Another thing that concerns me is that my last two posts appeared to be ambitious as well. I hate being "All talk, no action." :mellow: