Wake on LAN not as easy as it sounds!

[#1]

I know most of you won’t be interested but I just thought I’d get this out of my system as I find it quite annoying.

I wrote some C++ code yesterday to ping a range of IP addresses and when I get no response I send the machine a Magic Packet to WoL now all of this was working fine and smug mode was in operation.

However, this morning I started the daemon that contained this code, waited and tried to RDP to the machine; nothing, so I waited and tried again, still nothing! After a bit of rummaging I saw that the ARP cache entries had expired so I now need to add code to check the ARP cache and see if the entries I need exist and if not add them.

And here’s me thinking it would have been easier than this.

[#2]

why not just disable sleep mode if all you are doing is waking a machine up that the script notices that has went to sleep.

[#3]

Good idea @chenks76, but it's all to do with control and saving as much power as I can. I have 4 (soon to be of these machines I want to control. The daemon that controls them sends them work to do, so when there is not enough work I want to shut them down to save the power, and as these machines come up in just a few seconds it makes sense to economise their power consumption.

I've just completed the code for the ARP cache using a datagram socket and an ioctl SIOCGARP request and it tells me it can find the addresses, but I wonder what it will tell me tomorrow morning!

[#4]

Just add static entries to the ARP cache as they're not going to be changing so don't need to be added on the fly.

[#5]

Static entries are of course the answer but they only live as long as the machine is up and / or if the NIC is dis/enabled they’re lost. So I still needed the code to add these entries to cover this instance, which is what I did yesterday. So now when they can’t be found in the cache they’re created using a ATF_PERM | ATF_COM flag value allowing them to persist overnight as my test this morning now proves.

The system these are on may well be restarted over the weekend subject to what updates are applied, so with a bit of luck it will still all work on Monday.

[#6]

You could, possibly, use a table of MAC addresses and a consecutive block of IP address to use a pointer for the ARP task - since you are using the IP address to find an "off" machine. (Not yet "up" in v6 addressing )

Phil

[#7]

Static entries are of course the answer but they only live as long as the machine is up and / or if the NIC is dis/enabled they’re lost.

---

What OS are you using? On most Unix-like OSs you can put static entries in /etc/ethers and arp -f will populate the cache with them on boot for a persistent mapping.  Alternatively you can automate the additions with arp -s in a boot or interface configuration script. From a quick Google search it appears that on Windows that might be the only option for some reason.

[#8]

Thinking about this a bit more, it may be worth you taking a step back though and fixing the cause rather than the symptom. You shouldn't have to be messing around with ARP caches as the WOL packet alone should be waking the target machine up and the ARP cache being populated either as part of the target machine's duplication check and/or general chatter, or immediately following your subsequent connection attempt. WOL wouldn't have the prevalence it has if we all had to mess around doing what you're having to do!

[#9]

Not to sure what you’re meaning @PeeGee.

@MJN - The OS in this instance is Arch Linux, and I could do as you suggest, however, the point of this effort is to make the system (daemon) as machine independent as possible. The current list of Clients (Windows R2) are stored as an array of JSON objects in the daemon’s .conf file and the file is read at startup or when sent a SIGHUP signal.

This allows me to add new clients and or to ‘move’ the controller in the event of a hardware / system failure and not have to worry about the state of its ARP cache. In the event of the controller being moved while the clients are active is of course already taken care of in their software as they have a primary, secondary and tertiary end points in their config files. So when the connection is broken they’ll iterate their config until they get a connection or timeout (when they’ll start a timer and re-try later).

[#10]

While we're on the subject of WOL and ARP, someone tell me... how does windows get an IP address from a router when it does not have one and has just connected?

Can't be TCP or UDP so whats going on there and can I use indy sockets to replicate this behaviour in delphi or lazarus?

[#11]

It's done using a protocol called DHCP, no point in re-inventing the wheel so here's a link:

https://kb.iu.edu/d/adov

[#12]

---

7up wrote: ... can I use indy sockets to replicate this behaviour in delphi or lazarus?

---

What do you mean by this?

[#13]

---

@7up wrote:

While we're on the subject of WOL and ARP, someone tell me... how does windows get an IP address from a router when it does not have one and has just connected?

Can't be TCP or UDP so whats going on there

---

It sends a DHCP discovery request as a broadcast over UDP. With you saying it can't be UDP was this because of the lack of a source address? If so, this is catered for by the client setting the source address to 0.0.0.0 in its broadcast and the DHCP server responding also with a broadcast that the client is then able to pick up.

and can I use indy sockets to replicate this behaviour in delphi or lazarus?

I'm not familiar with either I'm afraid, but I would suggest that the functions almost certainly already exist and so don't look to reinvent the wheel if you don't need to.

[#14]

Yeah I know about DHCP but I figured that there must be another sort of protocol if the computer has no source IP address. MJN has just answered the question nicely, I didn't realise that UDP could still be used without a source IP.