Answer ARP on behalf of another device
ignaciovidalfranco opened this issue · comments
I have the following use case:
- A power hungry server that provides services both to the internal home network (Samba, backup server) and the Internet (WAN).
- Dumb router and devices that don't like and unanswered ARP reply and are flooding my network.
Now I'm asking myself... since this software already monitors for ARP requests and issues WOL packets when certain rules are triggered, would it make sense to reply to the ARP request on behalf of another device that might be currently offline?
Timeline would be like this:
- Server shuts itself off/goes to sleep on inactivity.
- Server's NIC is configured to Wake on Unicast
- Broadcast ARP request comes from the router or from any other device
- This software sees the broadcast ARP request and replies on behalf the server (which is currently on sleep and unable to answer)
- Router now has the correct MAC address on its ARP table.
- A unicast packet is issued from within the LAN and the server is awakened.
I guess this would upset a wide range of network devices, but I think it would be quite a hack. Also, I see this being weaponized...
I don't know. I just want to lower my electricity bill.
I would recommend a different name for a tool which replies ARP requests for foreign IP addresses.
But how would this lower an electricity bill? I mean, if routers are blocked from the ARP to WOL translation the flood of router issued ARP requests will just be ignored by every network member and these little requests shouldn't be measure able in power consumption or did I miss something?
Offtopic: Do you have Windows clients? I would like to know how you prevent unnecessary Server wake-ups, because even if using network links instead of mounted network folders, explorer does try to resolve recently used files and folders even if you don't click on them. I use lots of workarounds to remove my server from recent files. I didn't find any registry setting to turn off SMB connects if nobody clicks on these files or folders.
My biggest problem is that I can not turn off SATA spin up on wake-up, even if any SATA access is removed from the kernel SATA drives still get woken up. Like it would happen before the kernel executes anything. My windows explorer issue wouldn't be a big deal if the SATA drives somehow would stay turned off to just serve this stupid SMB metadata requests.
This could be added but may also be considered feature creep, it's best to keep this separate because the tool was designed with only one job in mind.
I like the notion of being able to avoid issues like that but maybe I should add an option to fire an additional hook (like with most linux package managers) in order to handle a situation like that.
That way you're gonna be way more flexible in terms of what you are able to do without necessarily adding too much complexity to this piece of software. I could make it call a simple call where it executes a script like so:
./yourscript.sh $tgt_mac $src_mac $tgt_ip and so on.
How does that sound?
I'm interested to read the reason for the request, maybe both of us are missing the point of this idea.
@ignaciovidalfranco We still want to know your thoughts about this topic. How could an ARP request without response lead into measurable more power consumption?
Would be nice if you have some time for my off-topic question as well.
@ignaciovidalfranco feel free to check out https://github.com/danielpgross/friendly_neighbor, which I developed for this specific purpose. It's also IPv6-ready, with support for responding to NDP requests in addition to ARP.
@danielpgross thanks for sharing your blog post.
But it doesn't make sense to me why going through all the hassle of avoiding wake on unicast issues instead of using wake on arp
wake on unicast issues:
- you need to reponse on ARP requests to hack the availability of unavailable devieces
- special hardware needed to configure port replication in order to debug what unicast packages did trigger an unwanted wakeup
- very strict control of network clients needed to make sure nobody is sending unwanted unicasts
- special firmware needed for some network gear to avoid unwanted unicasts
wake on arp issues:
- you need to install wake-on-arp service on a server to translate ARP requests to magic packages to support wake on arp on network adapters which don't support wake on arp
- you need to install wake-on-arp service even if your hardware supports wake on arp because wake-on-arp translation service makes it way more easy to ignore unwanted arp calls from routers
I mean yes, your way was way cooler. 👍
But is there actually a reason to prefer wake on unicast over arp?
Maybe you know which use cases require answering ARP on behalf of other devices: I interpret your blog post like this hack is only needed to get unicast working in order to trigger your complicated wake on unicast setup. But with wake on arp you don't need unicasts anymore, so no need to hack arp responses, right?
Or does some mac software stop working because the first arp request wasn't answered? All applications I know are repeatedly sending requests as long enough until the target wakes up. Since I never heard from software which stops after the first network request it is confusing for me why anybody wants to simulate ARP responses.
Since @ignaciovidalfranco doesn't want to spend timing share his use case we would like to hear from you, @danielpgross when it would be useful to have at least one use case for such a future :)
Thank you
@Falcosc it's a great question, thanks for the thoughtful writeup.
I did look into using wake-on-arp as a solution before moving on to using wake-on-unicast instead. At that time, there was a dealbreaker for me: I didn’t like the idea that trying to resolve a device’s physical address should trigger the device to wake up. It felt more correct to me that only a network packet sent directly (unicast) to the device should wake it up.
Aside from that theoretical preference, I also had a practical concern. I was seeing a lot of ARP chatter on my LAN in Wireshark captures, much of it seemingly unrelated to any specific application requests to my server. A lot of the ARP chatter instead seemed to be various devices performing automatic scanning/information gathering about what’s on the network. This seems to be what @ignaciovidalfranco was also experiencing.
So my hesitation with wake-on-arp, in a nutshell, was that it would have too many undesired wakeups due to ARP chatter.
Having said that, these were assumptions that I did not fully test. I didn’t end up trying out wake-on-arp because I managed to get wake-on-unicast working first. If I had tried wake-on-arp instead, maybe it would turn out that the ARP chatter is not actually an issue, and that there would not be undesired wakeups.
As for your question about use cases: I think wake-on-arp and wake-on-unicast are both valid approaches to solving the wake-on-demand problem, with their own pros/cons. It seems like wake-on-unicast might be simpler to set up on LANs with lots of ARP chatter, while wake-on-arp might be simpler to set up on LANs with minimal ARP chatter but with unwanted unicast traffic to the server.
And by the way, I think the problem of unwanted unicasts could be solved with friendly_neighbor just like it was cleverly solved in wake-on-arp: by setting up a blocklist of IP addresses for responses to ARP/NDP requests. If those blocked hosts can’t resolve the server's physical address, they also can’t send unicast packets. So I wouldn't consider this a fundamental flaw in the wake-on-unicast approach, but rather something that hasn’t been implemented yet 🙂
Could we conclude that nobody would mix wake on unicast with wake on arp?
Because if wake on unicast is the only reason, then it would be confusing to add this feature in the wake on arp tool and should only be implemented outside the wake-on-arp project.
Yes, I think that’s a fair conclusion.
Yeah, those seem like two separate solutions for different needs. I haven't been active since I had quite a bit going on atm.