Automatic Wake-on-lan Of Sleeping Computers

[phillipsjk256]

Back-story

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)

1. Freesco receives a packet to be forwarded to a computer on a LAN.
2. 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
3. While waiting for a reply, Freesco holds the received packet while decrementing the TTL field every second.
4. 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".
5. When the sleeping computer wakes up, it sends an ARP request to make sure it still 'owns' it's address (RFC 5227)
6. Upon seeing activity from the destination host, Freesco releases the received packet: if it has not expired.

While in theory the TTL field may allow the packet to be held for up to 4 minutes, in practice, TCP will time-out after 2 minutes.

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.

1. 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.
2. If any machine is suspected to be sleeping, Freesco examines every broadcasted frame (or packet) for a (per-host configurable) "wake event".
3. 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:

[Lightning]

That does sound very ambitous, however not completely unreasonable. I can definitly see the usefulness of this in some specific aplications. But I am doubtful the use would be very wide spread, however if you need some help with system changes possibly needed for this package, just let me know. To be clear I don't see this as a built in feature, although I did entertain the thought of WOL built in. But the space requirements versus usage in a floppy application was not worth it and there is already a hard drive package for it.

[phillipsjk256]

Because of the complicated packet matching (and manipulation) required by my proposal, I looked into netfilter/iptables available for the 2.4 and later kernels. Linux nefilter Hacking Howto

The good news is that it can be done in user-space with the newer kernel, the bad news is that 68k (or even 200k) is not enough extra space on the floppy. That ignores that fact the all the old firewall rules would have to be re-written because the emulation can only be used if you are not using the new style as well.

Essentially, you would watch for interesting packets on various interfaces. You can put matching packets in a queue that is handled by a user-space program. When the user-space program is finished with the packet, it is put back in the chain just after where it was sent to the queue (if I read that right). The packet is then dropped if a certain flag is set, or proceeds through the rest of the filters.

It seems obvious that this user-space program should be able to call the "wakelan" program when appropriate. Holding the packets in a queue may be tedious, but doable.

Another reason for looking into the newer kernel is better hardware support (like full-duplex support for my one 3c509 card). As you know, every feature has a certain space penalty attached to it.

I tried test-compiling the 2.4.37.1 kernel with options similar, but slightly more functional than the Freesco kernel. Even with Bzip compression, my first attempt weighed in at over 800k. I haven't been able to get it under 600k. It is around 2MB before compression. Does including hundreds of modules significantly affect the size of the kernel?

I was using the 4.1.2 gcc compiler which is *NOT* supported (too new), but it only generated warnings, not errors. (I figure close enough for seeing how big the kernel image is)

I was going to attach the .config file I was working with, but that may be disabled in this sub-forum.

[Lightning]

Does including hundreds of modules significantly affect the size of the kernel?

It increases the size of the kernel with each module built into the kernel, but does not effect anything if it is just a loadable module.

As for looking at a newer kernel you will easily figure out why FREESCO is running the 2.0.40 kernel and also why it is still using a very stripped down version of libc5 instead of libc6 like newer systems use. So as nice as this project sounds I am doubtful you are going to be realizing it on a FREESCO system in the near future. I do have plans on going to a newer kernel and lib6 or variant at some point. But so far I have not been satisfied with the alternatives when trying to do it. Most likely my standard of a floppy format will have to disappear, but for now they have not.

[phillipsjk256]

To stretch an analogy/mix metaphors, I think we are on two sides of the same page.

I see the floppy disk as an efficient, mature and cheap medium that does not yet have a good replacement. I suspect you enjoy the scope limiting and challenge the small format affords. I really don't see the need for such an arbitrary limit, but I have yet to contribute patches, so can't really complain.

I am paranoid and lazy. I just want to be able to "set and forget" my router for the most part. This means I was using a locked floppy before (I found) the "read disk only once" mode. To make changes, I have to restart in setup mode. The idea is I can simply reboot the router if some cracker exploits some unknown vulnerability in the 2.0 kernel the would allow then to write to the filesystem; regardless of permissions. A CD-R in a standard CD-ROM drive would meet the security criteria, but breaks the "lazy" criteria due to the difficulty of making changes. I suspect a CD-ROM would use more power as well: spin-up on demand has been a standard floppy feature for as long as I have been alive. That, and I tried running from a Live CD for about a year. Pros: clean system every boot; I can install flash for one site and not worry about annoying ads the next day. Cons: Slow, performance of moving parts got worse with time, relies on fileserver (or other storage device).

I think the most promising floppy replacement candidate I have seen is the "Secure Digital Card." It is about the size of a postage stamp and has a write-protect tab. SD Association general technology description However, I have had nothing but problems: either due to faulty card readers or digital rights management; I have not determined which. If you trust Linux (even under duress from buffer overflows or CPU back-doors) to honor read-only mounted filesystems, a CF card installed with an IDE to CF adapter is a much better choice (took me years to find one locally).

I think the whole concept of installing a floppy-based router on a hard disk is a little silly, but enough people use the feature to install large packages to make it worthwhile. Currently, I am using a 486 with 24MB of RAM (expandable to 32) and 3 ISA NICs. If needed for routing between two nets at 100Mbps, IPv6, or QOS, I have an unused Pentium 90 (passive heatsink) with 96MB of RAM and approximately 1GB of disk. If I move to the more power-hungry machine, I will probably start with a minimal install of Debian rather than Freesco. Actually, what would be more useful in the near term is to use it to test how well NICs play together. I could possibly even do a Linux from Scratch distro for that.

Personally I think routers and fileservers should be kept separate, but some disagree:
I need RAID because I can't justify another box

[Lightning]

I suspect you enjoy the scope limiting and challenge the small format affords

Almost anyone with a minimul amount of skills can start adding various aplications together and make a OS from scratch. Which means that at each new feature the system just keeps getting bigger. All you have to do is to look around and it is obvious what almost all of the major distributions have done. The problem with that in my eyes is that nothing is ever made more efficient or smaller. That is why CPU's must keep getting faster and necessary system resources must keep getting higher. That is why I discovered a long time ago that setting and keeping a size requirement (1.44 floppy) made me look at every single detail under extreme scrutiny and forced making things run using less.

There are probably hundreds of router OS's around that will do all sorts of various things. There are even some that fit on a floppy, but none of them fit on a floppy and have the versatility that FREESCO does. Also the real appeal of FREESCO is that it is a small enough OS that it is not overwhelming to understand and it is very easy to modify to suit what ever you want it to be and expand if someone wants it to, which is what has made it popular. However regardless of any of those facts the primary thing to understand is that doing this has maintained my interest for a decade and I am absolutely certain without the challenges of 1.44Mb it would not have. Because as stated anyone can just keep adding more stuff.

[phillipsjk256]

I was not aware of how large "Linux from Scratch" was now. When I was trying to follow it, the instructions included building floppy images with a ramdisk: no partitioning required. I got stuck because I was trying to use a pair of 1.2MB floppies instead of one large 1.44MB floppy (and could not get past a certain point in the lesson).

When I said "Linux from Scratch distro" above, I meant floppy based. I guess my shock and sense of loss really brings your point home.

Edit: After some research, I have determined that even the 1.0 version of the Linux From Scratch guide was hard-disk based. The Guide apparently replaces the Linux Linux From Scratch HOWTO. I was not able to find a copy on Archive.org (only goes back to 2002 for tldp.org). I used Google with to exact title to track down the original Howto: 1.0 December 16th, 1999 - Initial release. That document does not look too different from the 1.0 version archived on The Linux From Scratch site.

It appears I was mistaken about the name of the document I read. The document I read was probably based on The Linux Bootdisk HOWTO (or vice-versa), but instead focusing on a floppy-based mp3 player as an example.