Wake on lan ssh

Enabling Wake-On-LAN (In Ubuntu 20.10)

Table of Contents

Note: The systemd configuration here isn’t quite right, but since this post is kind of long and convoluted I made a standalone update about the systemd configuration file in this post.

Beginning

These are my notes on getting Wake-On-LAN working in Ubuntu 20.10. I have a server that I use to run most of the computation on when I use emacs/jupyter but I have it in a corner upstairs and although it’s only a little walk, I find that the fact that I have to stop what I’m doing and go upstairs to push that little button on the front makes me lazy and so it ends up running more than it has to so I thought I’d enable Wake-On-LAN so I can suspend it and wake it up whenever I need to. I’m only going to use suspend (APM S3). When I tried to use hibernate (S4) it ended up shutting down my machine (S5). Interestingly, my BIOS menu has an option to enable waking up from shutdown, but since my disk is encrypted, and I didn’t set up a separate SSH server, I have to go enter the passphrase to unlock the disk before the operating system can boot up, so it kind of defeats its own purpose.

Middle

Ethtool

The command I used to set up Wake-On-LAN on the remote machine is called ethtool. It’s in the Ubuntu repositories but wasn’t installed on my machine so I had to add it.

Checking the Interface

From what I’ve read, not all ethernet interfaces support Wake-On-LAN (although I’ve never seen one that doesn’t) so a quick check might be useful. First, find the name of your ethernet interface.

My machine shows four interfaces so I’ll just show the output for the interface I’m interested in rather than the whole output for the command.

Ethtool uses the name of the interface, in this case it’s enp4s0 , so we’ll need to note that. Additionally, the machine that I used to wake up the machine needs the MAC address ( 38:d5:47:79:ab:0b ) so it’d be useful to write that down someplace. I’m waking it up from the LAN so the IP address isn’t so important, and to be able to SSH into it I need to know it anyway, so it’s really those two pieces of information that I need. Now to check if it supports Wake-On-LAN.

Ethtool will give you some information if you don’t run it as root but for Wake-On-LAN you need to run it as root. The important lines in the output is near the bottom and it looks something like this if it supports Wake-On-LAN.

The man-page for ethtool tell you what that cryptic pumbg means — the letters are different options that this interface supports for Wake-On-LAN. In this case they are:

Option	Description
p	Wake on PHY activity
u	Wake on unicast messages
m	Wake on multicast messages
b	Wake on broadcast messages
g	Wake on MagicPacket messages

There’s an additional option which is what the interface was set on – d – as you can see in the last line of the output. This means Disable (wake on nothing). This option clears all previous options. I don’t have many devices on my network, so I don’t know that there’s a lot of broadcasts, multicasts, etc. that would be waking it up all the time, but since one feature of Wake-On-LAN is that it only wakes the machine when it gets the «Magic Packet», only the g and d options matter. Now that I knew it was supported, it was time to try it out.

Turn It On Temporarily

The ethtool will turn on Wake-On-LAN, but (supposedly) everytime you reboot the machine it will reset to disabled. I haven’t really tested this out, but I’ll document how to make it permanent later, anyway.

So, as you might guess, we changed the Wake-On-LAN setting to listen for MagicPacket messages. You can check using the ethtool again.

The Wake-on line should have changed to:

Now to suspend the machine so we can test it out.

Test It Out

Now, on my local machine I needed to install wakeonlan. There’s a surprising number of programs to send the Magic Packet, but this just happened to be the one I used.

The default way to use wakeonlan is apparently to just pass it the MAC address of the computer to wake up, and it will send the Magic Packet out as a broadcast, so that’s what I did.

And then I pinged the machine and I waited. And I waited. And I waited… Eventually I went upstairs and saw that it was still sleeping so I pushed the power button to wake it up and went back downstairs.

Take Two

Something wasn’t right so I SSHd into the server and started up tcpdump to see if the packets were going through.

Which gave me this output:

And then I sent the Magic Packet again.

…And nothing happened. For some reason the packets weren’t getting picked up by the machine. Luckily, wakeonlan lets you pass in an IP address as an option. The man page recommends using a broadcast address, but I have the IP addresses of my machines on the LAN reserved on my router/access-point so I just passed in the full address (I did try the LAN broadcast and it worked too).

I have my machine’s IP address aliased in my /etc/hosts file so erebus is just an alias for the machine’s IP address. The subnet broadcast version looked like this.

The output from tcpdump for the first packet looked like this.

So, something was different. I suspended the machine again and sent the Magic Packet and this time it worked. Go figure.

Making It Permanent

Set It Up

The reasons that I said earlier that the Wake-On-LAN setting «supposedly» is temporary is that:

1. I haven’t really re-booted that machine to test it out (I have rebooted, but I haven’t disable the systemd service that I’m documenting here).
2. The machine that I’m typing this on had Wake-On-LAN enabled and it doesn’t have a systemd service enabled.

But, really, I don’t remember even enabling Wake-On-LAN on this machine so maybe it just was the default and I didn’t realise it… another thing I should look into one of these days. Anyway, to make a service that always enables Wake-On-LAN the first step is to find the path to ethertool .

In my case the path was /sbin/ethtool , so once you know this you can create a file at /etc/systemd/system/wol.service (I think you can use another systemd sub-folder, and you can name the file anything you want, within reason, but this one seems to work well enough). In this file you put settings that look something like this:

The only thing specific to my machine is enp4s0 , the name of the ethernet interface, although it’s possible that the path to the ethtool executable might be different too… but it should be the same on Ubuntu 20.10, anyway.

Enable The Service

To enable it you can do this:

Where wol.service is the name of the file you created with the settings. You can check its status if you want.

So, that’s how I got one machine working with Wake-On-LAN. Hopefully I won’t have to look so hard the next time. Here’s the pages that I stole this from.

• TechRepublic on using ethtool and setting up a systemd service for this (don’t use the systemd file here, though).
• Stack Overflow on how to suspend and hibernate from the command-line
• Stack Overflow on what the difference is between suspend and hibernate
• Stack Overflow on using tcpdump to look for the Magic Packets on the remote machine
• Stack Overflow on editing remote files as root with emacs (not documented here, but maybe later)
• Stack Overflow on editing a local file as root with emacs (not used here, but I can never remember the syntax)

Источник

Cloud is not free, Wakeup and SSH to your home computer remotely

Recently I had to run some Q-learning algorithms on my home desktop (running on Ubuntu 18). These workloads, depends on the model and hyper parameters, could take a while to finish. If I’m away from home and still wants to work on this project, my options would be:

• Run the algorithms on my Macbook pro and thus starting a fire somewhere
• Run the algorithms on the cloud, cheapest computation optimized instance costs $0.085/hour on AWS
• SSH into my desktop remotely, and continue my workloads, for free (well, plus the electricity cost)

In the rest of this post I will walk through how I set up my desktop for SSH and WOL(Wakeup On LAN).

SSH within the same local network

1. Find the ip of destination machine: run ifconfig and you want to find the interface with your local ip, something like 192.168.0.10
2. Verify sshd service is running and find the ssh port (default is 22)
3. Test ssh: ssh user@192.168.0.10

SSH from external network

In order to access the desktop from external network, we need to:

1. Find the temporary public ip assigned by the ISP, dig +short myip.opendns.com @resolver1.opendns.com let’s say 1.2.3.4 is our public ip
2. Now that we have the public ip, can we ssh to our desktop remotely? Well, not yet, our home devices all share the same public ip, this is called Network Address Translation (NAT). So we need to explicitly tell our router to forward all incoming traffic of a port to a specific local ip and port, this is called Port Forwarding. In our case we need to tell our router to forward all traffic heading to port 22 of our desktop. All routers should have this functionality and this can be setup on the router admin web ui. We need to add a port forwarding rule so that it forwards source port 22 to destination, our desktop’s ip, 192.168.0.10 and destination port 22.
3. Test ssh, ssh user@1.2.3.4
4. Tighten up the security. Internet is a dangerous place and we don’t want our machine compromised. In my setup I disabled password authentication and root login, so that the only way to ssh into my desktop is through public key authentication. To disable password authentication, in /etc/ssh/sshd_config , change the following lines to no

5. Before we restart sshd and apply the changes, we need to create a ssh key pair and copy our public key to user’s authorized_keys : ssh-copy-id user@1.2.3.4

6. Now restart sshd on desktop and test ssh again, this time it should not prompt for password.

Setting up Wakeup On LAN (WOL)

I set my desktop to suspend after 15mins of idle to save electricity. But the problem is that we can’t ssh back to it after it goes to sleep. The router sees the device is offline and stop forwarding anything to that local ip. Luckily, there is a feature called Wakeup On LAN that’s supported by most motherboards.

1. This feature is usually disabled by default, we need to enable it in our BIOS
2. Enable WOL with ethtool in the OS level, sudo ethtool -s eth0 wol
3. Verify WOL is enabled for our network interface eth0 . g indicates wake on Magic Packet is enabled

3. Now we need something to send the magic packet, I use wakeonlan but there are many alternatives. To send the wake up our desktop, we need the mac address of our desktop network card. This can be found in the output of ifconfig :

This tool basically boardcast to all devices under the same network and wakes up the device that matches the mac address

4. Suspend the desktop and test WOL from laptop

I can hear my desktop spinning up right after sending this command, we can ssh again! But wait, can we run wakeonlan from an external network? How do we wake up the desktop remotely?

Unfortunately most home routers do not support this feature, as the above ARP query only works within the local network. This left us a few options:

• Leave the desktop on 24/7 (this might be more expansive than cloud)
• Running a device with low power consumption 24/7 and use it as a jump host to wake up our desktop
• Run Teamviewer WOL if the target computer is connected to the router via a network cable.

Luckily I have a raspberry pi sitting around, we can follow the same steps above to setup port forwarding and ssh. Note that we already used port 22 for our desktop, we need to run sshd on a different port, so that we can ssh into raspi from external network. To do this, change Port 22 to Port 2223 in /etc/ssh/sshd_config and restart sshd.

Then setup another port forwarding rule to forward all incoming traffic to port 2223 to raspi’s ip and port 2223

5. Test ssh to raspi using our public ip and test wakeonlan from raspi

Nice, desktop is up again! We can now wake up and ssh into our computer remotely.

Future Enhancement

Our public ip is not permanent, it could be changed when the DHCP lease is renewed. We can add a cron job on our raspi to commit our public ip to a private git repo if ip is changed.

Источник

Wake-on-LAN (tutorial)

From DD-WRT Wiki

Contents

[edit] Introduction

Wake-On-LAN (WOL) provides the ability to wake a slept/suspended, hibernating, or shut down computer, but the support for this (especially the latter) is dependent upon the hardware and BIOS/UEFI settings. Most modern computers have the WOL feature — it might be listed under PME (Power Management Events).

Reasons to use WOL with DD-WRT:

• You do not want a computer on all the time, yet you want to use it from outside your home or office, and there is a DD-WRT-enabled device as the Internet gateway for that computer, powered on all the time.
• The computer is a media server that auto-sleeps, but you want it to wake automatically for file access.

[edit] Preparation

1. A PC which supports WOL. Most modern PC’s can be set-up this way.
2. Administrative access to the computer you want to sleep/wake-up.
3. The WOL computer should have a static IP address, one manually assigned or through static DHCP. In the example below, we assume your router LAN is 192.168.1.x (the default) and the static IP WOL computer is 192.168.1.254.
4. Ideally, a second PC to test the WOL abilities of the first one. You can also use the DD-WRT device’s Web Interface to send test packets, in place of a second PC.

[edit] Enable WOL on the Computer

1. On the LAN adapter of the computer (physical ethernet adapter and/or wireless, given BIOS support), choose Properties/Configure.
2. Power Management tab (far right). Check the second and third boxes to enable WOL. Press OK until you are back at Network Connections. Now the computer can normally be started from Hibernate, Standby, or PowerOff modes via a special management packet.
3. Get ready to test your set-up by using a utility like WOL Magic Packet Sender http://magicpacket.free.fr/ (free). Install it on both the computer you are using and a second PC on the same physical LAN.
4. On the WOL computer, open WOL Magic Packet and on the Receive tab, click the green Start button.
5. On the second computer, open WOL Magic Packet and on the Send tab, put in:
   1. IP Address of WOL computer for Host Name
   2. 0.0.0.0 for Subnet Mask (select from drop-down)
   3. MAC address of LAN adapter on WOL computer. Use the command ‘ipconfig /all’ if you don’t know what this is.
6. Click the green Send button. The WOL computer should respond with a pop-up box showing a packet was received.

Repeat the previous steps and go over the trouble-shooting tips until they work before proceeding.

[edit] Test that WOL works within the LAN

Hibernate, Standby, and Power-off the WOL computer, while clicking Send on the second computer, to test each mode to make sure WOL is working.

Once this step is working, you can go on to making WOL work when you are outside your LAN, such as at a cafe or another remote location.

[edit] Troubleshooting

Wake On LAN is usually disabled by default in most PCs. This feature, if optional, must be enabled in your BIOS otherwise WOL isn’t going to work. Consult your motherboard’s manual and BIOS screen (DEL at startup, usually). If you don’t see the WakeOn-type options in your BIOS, usually somewhere in Power Management, your motherboard may not support WOL.

• A good place to start is here: [1]

[edit] WOL Methods

[edit] WOL through Telnet/SSH

Note: This is the preferred method to send WOL magic packets remotely.

If you have local or remote Telnet/SSH access to your router, you can wake up a machine on the LAN by using the following command:

Note that the full path to «/usr/sbin/wol» is important. Simply «wol» will not work.

Substitute AA:BB:CC:DD:EE:FF with the actual MAC address of the computer which you wish to boot remotely. Likewise, replace 192.168.1.255 with the actual broadcast address of the network (192.168.1.255 is the broadcast address when the machine has an IP of 192.168.1.x and subnet mask of 255.255.255.0). Replace «PP» with the port number your machine listens on (usually 7 or 9).

[edit] Remote Wake On LAN via Port Forwarding

To remotely wake up a computer over the Internet using Wake On LAN— follow these instructions:

1 — Create a port forward rule on the Web Interface (Applications & Gaming -> Port Range Forward) to the chosen ip:

• Here, 9 is the default, but you can use any port number so long as your client wake-up application can talk to a port other than 9. Most WOL services will use either UDP port 7 or 9.
• 192.168.1.254 is just an IP address in your LAN’s subnet; it can be any IP, as long as it is not assigned to any device on your network.

2 — Add a static ARP entry by typing the following line into the Administration -> Commands section of the Web Interface and then saving with Save Startup.

• Do not change the FF:FF:FF:FF:FF:FF MAC address; this is a special MAC address used when broadcasting. WOL magic packets are constructed using the MAC address of the target computer, but should be and almost always are sent via broadcast; the MAC address used here controls with how the packet is sent, not how it is formed.
• The 192.168.1.254 IP address should correspond with the IP address you used in the previous step. Again, this IP should be in your LAN’s subnet, and you must not assign this IP address to any actual device on your network.
• Explanation/rationale for this setup: Normally, WOL magic packets are sent to a special broadcast IP—to the final .255 in a subnet or to 255.255.255.255. Since port-forwarding to these special dedicated broadcast IPs does not work, what we need to do is create our own broadcast IP by taking an unused IP and assigning it a broadcast MAC and then port-forward to that.
• As an optional alternative, instead of arp, you can use ip neigh (which does the exact same thing as arp). Support for ip neigh was removed from DD-WRT starting with build 17650, and arp is unavailable in DD-WRT builds older than 5672.

• NOTE: SOME BCM USERS HAVE REPORTED ISSUES WITH ARP. SEE THIS:

3 — Reboot the router, or execute the startup commands manually.

• To wake your computer from the internet using the DD-WRT device DynDNS name (or if you know it, the public IP of the router), try one of the following services;

1. Mestrona’s online WOL. You need to forward port 9 udp in step one, to use this service.
2. Wake-On-LAN Online. It works both on ports 7 and 9 and allows WOL by a single URL of the form: http://mobile.wakeonlan.me/?ip=HOSTNAME&mac=MACADDRESS. It also allows for scheduled wakeup over the internet.
3. To use the WOL Magic Packet application from a second PC:
   1. Host Name: DynDNS name of your DD-WRT device.
   2. Subnet Mask: 255.255.255.255
   3. MAC Address: WOL computer MAC address, not the DD-WRT MAC.
   4. Click the green Send button.

[edit] Automatic Wake-On-LAN Daemon

The Automatic WOL daemon will send out a periodic wake on lan packet at the intervals you specify. This may be useful to keep a system online most of the time even if it is turned off. (eg: A Media Center PC).

For Interval you can enter a value in seconds as low as 15 seconds and as high as 86400 seconds (1 day). Host name should be the broadcast address for your LAN. eg: 255.255.255.255 or 192.168.1.255. SecureON Password is computers that have a BIOS feature that secures the WOL function. If you do not have a BIOS that requires this form of password then you can leave the box blank or type in 00-00-00-00-00-00. MAC Address(es) should contain the MAC address of the networked machines you want a WOL to be sent to on your LAN.

The packets generated by the WOL daemon are sent to UDP port 40000. You likely will not need to worry about this unless the system you are attempting to send the WOL packet is on another subnet or you are trying to monitor the packets.

note: the UI says that the Interval accepts a range of 1-86400 seconds but it will only send out a WOL packet at a minimum of 15 second intervals. All values below 15 are accepted but the interval will still be every 15 seconds.

Источник