> The first problem I see is that machines don't wake on ARP. > Ultimately I believe we don't want our machines to wake on ARP, we > really want firmware that can handle ARP and only wake when our > address is ARP'd. I don't know how unreasonable a request that is.
It's completely reasonable, and we've put together most or all of the parts to get it working for IPv4. See: http://dev.laptop.org/ticket/3732 If we fix the wake-on-multicast problem then we'll fix IPv6 ARP as well (it uses multicast for "neighbor discovery" packets that replace the ARP protocol): http://dev.laptop.org/ticket/4616 > Another problem appears to be lost wakup packets while collaborating. http://dev.laptop.org/ticket/6528 > This should be able to be fixed by using an iptables queue. If we > queue collaboration traffic that isn't responded to, we can quick of a > script when the queue gets X long that tries various methods to wakeup > the machine on the other end. We should fix the real problems, which are low-level, straightforward, and easy to reproduce, rather than building crazy workarounds at higher levels. > Be smarter about how we track network traffic. Other than just > checking if there is network traffic, we should be tracking where this > network traffic is from or to. We shouldn't need to check whether there is network traffic when desiring to suspend. If no process has run in N milliseconds, the kernel should autosuspend. N should be tuned to avoid constantly suspending and then immediately reawakening, e.g. between packets in an active HTTP connection. John _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
