Wake up a computer over Internet using another computer in the same local network

I have two Arch Linux-powered computers, 'A' and 'B', connected to the Internet via the same router. I have configured and tested Wake-on-WAN on both of them. Both computers are shut down most of the time.

I'd like to connect to them without sending magic packets from outside. NIC of the computer 'A' supports waking up by the unicast activity, so I've enabled it. The problem is, this isn't the case for the computer 'B' - it can be woken up by the magic packet only.

Can I make the computer 'A' to wake the computer 'B' automatically when there is TCP/UDP connection attempt to the latter? I'm thinking about a solution like this:

Configure the router and the computer 'B' so all of the 'B' traffic (on specific ports) goes through the computer 'A'.
Set up a script on 'A' that triggers on a connection to 'B' somehow, checks 'B' state and sends magic packet.

Maybe there is a simpler way?

EDIT:

It would be good if it was possible to re-route everything so no 'B' traffic goes through 'A' after wakeup of the former, therefore enabling the latter to auto-shutdown.

ivanp7

Posted 2018-09-11T23:09:38.167

Reputation: 21

Answers

You could make a bash-script on computer A that generates and sends a magic packet to computer B over local network.

Once you wake computer A by unicast traffic, the script could trigger automatically or you can SSH into computer A and run it.

This answer on StackOverflow describes how to make such script.

VL-80

Posted 2018-09-11T23:09:38.167

Reputation: 3 867

I don't want 'B' to wake up when I access 'A'. The script needs to detect if there is a connection to the ports reserved for 'B'. Anyway, this answer is a refinement to my solution, thanks. – ivanp7 – 2018-09-12T00:32:04.420

I don't want 'B' to wake up when I access 'A'. OK. Then do not make the script run automatically. Whenever you need to wake up B you first wake up A, SSH into it and run the script that wakes up B. In this way waking up A would not automatically wake up B. – VL-80 – 2018-09-12T00:39:44.903

This is what I do now, but I want to get rid of the manual wake procedure. – ivanp7 – 2018-09-12T00:43:05.857

I'm going to try something like if [[ "$(ss -anp | grep $PORT | grep ESTAB | wc -l)" -gt "0" ]]; then wakeup.sh; fi – ivanp7 – 2018-09-12T00:50:44.073

1@ivanp7 Why don't you let the router send the magic packet? You've got a nice shell-enabled router right, with at least busybox? – Xen2050 – 2018-09-12T00:55:51.633

@Xen2050 This would be the best solution if I bought the router myself. It is a cheap Huawei HG8245H-256M, installed by my ISP. Someday I'll buy a real router, but currently I want to get as much as possible from the present hardware. – ivanp7 – 2018-09-12T01:18:56.513

@ivanp7 Could try using your own router (or any other low power device with a shell, raspberry?) connected to the ISP's Huawei as another client, or daisy-chain your own router after the Huawei & have all your devices connected to your router – Xen2050 – 2018-09-13T01:17:18.400

Can I make the computer 'A' to wake the computer 'B' automatically when there is TCP/UDP connection attempt to the latter?

You'd need to proxy the ARP requests to B while B is asleep, then listen to connection attempts for the IP of B, and send the wakeup packet.

That's doable, but difficult enough I'd write a small C program using packet sockets for the initial ARP proxying and the connection attempt snooping. It would also need to manage state about B saying if B is asleep or not, for example by looking at whether B sends out anything, and responds to ARP requests.

You'll need a fair bit of understanding of network protocols to write this (or stare at wireshark captures long enough until you understand what is going on.

dirkt

Posted 2018-09-11T23:09:38.167

Reputation: 11 627

I have static ARP entries for A&B, therefore, I believe, the router won't send ARP packets? Why not just NAT some reserved port (let it be X) on A to B and have a daemon on A that detects connections to X, sending magic packet if neccesary? The main drawback of this approach is that A won't shut down while B is still in use. – ivanp7 – 2018-09-12T10:31:03.927

You have static ARP entries for B on all computers who are on the local segment and may make requests or forward packets to B? If yes, then you shouldn't need to deal with ARP, but I'd wireshark an actual request to make sure. This small C program basically would be a demon on A that detects connections to B (and handle ARP on top, if necessary). If you can redirect (NAT) all requests to B to A on some router in front of A and B, then yes, you can do that, too (and NAT it back to B on A), but you didn't indicate where the requests can come from. Also, with static ARP, you will have to NAT. – dirkt – 2018-09-12T11:02:01.327

Requests are coming from outside, and there are only two computers, A and B, in the LAN. I own all the hardware, no operation restrictions. – ivanp7 – 2018-09-12T11:19:07.113

I'd be tempted to do the waking up in the router, then - the router will be on anyway, you won't have to deal with ARP (or even use a missing ARP response as an indicator to send a WoL packet). Again, a C program with packet sockets, monitor ARP requests and responses, timeout state. I wouldn't be surprised if someone had already written that somewhere... – dirkt – 2018-09-12T11:43:58.487

I'm afraid, my Huawei HG8245 router with Dopra Linux won't let me do that. It has a solid static native firmware and too few memory to install OpenWrt. Otherwise, it'd be the preferred way. – ivanp7 – 2018-09-12T12:31:27.053

But NATing B to A on the HG8245 will work? What about generic iptables rules? – dirkt – 2018-09-12T14:03:16.747

Sorry for delay. It supports simple port forwarding, not much else. – ivanp7 – 2018-09-13T12:08:26.123

If you can't NAT B to A on the HG8245, then static ARP won't work (attempts to connect B will only end up at B, and never at A), so I'd use the original idea in the answer (arp proxy until B is woken up). If you would have to port forward to B anyway, you can port forward everything to A, and then cobble something together to either listen and send the WoL, or activate NAT via iptables, but I'm not sure if this will be simpler. – dirkt – 2018-09-13T12:21:45.233