Server won't wake up

Has it suspended recently?

When a client successfully resolved the MAC address of a server host, either with ARP or NDP, it will cache this value for a limited amount of time (usually for about 2 to 5 minutes). During this time no new address resolution request will be broadcasted through the network. Because ARPergefactor relies on this, to detect connection attempts to the watched hosts, there is no way to step in and wake the sleeping host until the cached MAC address expires and a new address resolution is attempted.

If you use the lazy impersonation mode (this is the default), there will be a short window in which ARPergefactor is not able to wake hosts in response to a connection attempt. If your use case requires your hosts to suspend and wake up in a frequent manner, you should consider enabling the eager impersonation mode. In this mode ARPergefactor will regularly check if the watched host is alive and will claim their IP addresses as it's own, as long as their rightful owner does not respond. You can read more about this on the page about Impersonation.

Allowing external access

When ARPergefactor becomes aware of routers on the local network, it will refrain from impersonating other hosts in front of them (it still has some respect for authority). This is done to minimize the amount of confusion created in their mapping tables, because the impact on your network is unpredictable. Probably nothing will happen. But considering the amount of available routers and the limited capacity to test them all, it's better to be safe than sorry.

Unfortunately this can be a problem, when you configure a port forwarding inside your router to one of the watched hosts and also expect them to wake in response to requests from remote hosts on the internet. If we don't answer for address resolution requests, our router will think these hosts are offline (what they are), but also won't attempt to establish a connection, which we need in order to wake the host. There are some attributes to configure at the router level, to bail you out of to this predicament:

1. allowWakeByProxy="true": This attribute advises ARPergefactor, that it should indeed respond to address resolution requests issued by the router, if it queries a watched host that is asleep. This will signal your router, that the device in question is alive and can receive directional IP traffic. If no following IP packets from a different host will be observed, the WakeRequest will end unsuccessfully, though. This is to make sure, that your router won't start waking up devices on it's own.

2. allowWakeOnLAN="true": This attribute advises ARPergefactor to make an exception, if it receives a Magic Packet for the watched host prior to any connection attempt. Some routers can be configured to send a WOL request when someone tries to access a forwarded service from the internet. Of course this will only be helpful, if the target host is not waken by that Magic Packet in the first place. Configure this, if you want to wake physical hosts when one of their virtual hosts would receive a Magical Packet directed at the MAC address of their virtual network interface.

3. allowWake="true": This attribute removes the block of router based requests completely. Also use this if you need your hosts to wake in response to some request by the router itself (e.g. access to a file share) or something still doesn't work and you don't know of any other help. Keep in mind, that this can have unforeseeable side effects.

Hot reloading doesn't work

If you are on Linux and use symbolic or hard links in your configuration directory, please note, that if you change the linked files through a path outside of the configuration dir, these changes cannot be detected. This is a limitation of the utilized FileSystemWatcher and how it uses inotify.