I get it now, you are a bit cheap weird and decided to go full AMD with the R9700 AI PRO GPU. Which probably means its installed on a Linux Machine build with LLM in mind that stays full time powered up somewhere in your office or your house ready to generate rally kitten drivers for your pleasure.
At least this is what I did and my workstation — a desktop with a Ryzen 5 5600 and a Radeon AI PRO R9700 (32GB) serving coding models through Lemonade — was never meant to run 24/7. It’s a 300W card sitting in the office: great when I’m actually pushing tokens through a local model, completely pointless when I’m not around. The trap everyone falls into is “I’ll leave it on so it’s always there.” Which means a 300W-capable rig humming away, warming up an empty room, doing nothing. Sure, I could stop the workstation remotely, but guess what, AI work was needed right after.
So I needed a way to start and stop the workstation remotely from my laptop from anywhere.
What do you need to start and stop the AMD R9700 AI Pro remotely?
The good news is that you dont need much to do this remotely and secure:
- an Always On Raspberry Pi in the same network with the LLM workstation – but I opted for a HP Elitedesk G3 which you can source for cheap (I anyway had it for a small Proxmox homelab)
- a way to connect safely from outsite (Free tier Tailscale)
- some Linux knowledge (but hey, you bought the AMD AI Pro, so you already know AMD GPUs are mostly running on Linux)
I already knew about Wake on Lan, so my first instinct was: I’ve got Tailscale, the workstation is on Tailscale, so I’ll just send it a wake packet from the laptop. Nope. When the workstation is off, its Tailscale daemon isn’t running. It isn’t on the tailnet at all. There’s nothing to send a packet to.
This is where the Always On Machine comes into place: the laptop reaches the always-on relay (the Proxmox host) over Tailscale, and the relay — which is on the office LAN — fires the magic packet locally. Tailscale carries my intent across the internet; the relay does the actual wake up call.
I keep talking about Tailscale, and maybe you don’t know what it is.
Tailscale is a service build on top of WireGuard that builds a small private network, called a tailnet, from machines available in different locations without port forwarding, no opening ports on your router, no public IP. Its Personal plan allows up to 6 free users in a single tailnet. So it’s you plus up to five other people (family, friends) who can access shared resources.
Good, so basically you sign up with Tailscale and install it on each machine – Windows laptop, Always On machine, the AI workstation and they will get their own Tailscale IPs and makes the machine available no matter how they are connected to the internet.
Setting up WOL on the AI Workstation BIOS
I thought that is an easy one, but there are 2 things. Not every bios calls WOL as WOL, for example on my Asus Motherboard Wol is under Advanced → APM Configuration, and it’s called “Power On By PCI-E” (on some boards “Power On By PCI-E/PCI”). Secondly a lot of boards have a power-saving option — usually ErP, EuP, or Deep Sleep — that cuts standby power to the NIC on a full shutdown. With it on, the card is completely dead when the machine is off and nothing can wake it, so you need to disable deep sleep.Quick physical check: with the machine powered off, the Ethernet port LED should stay lit. If it’s dark, the card has no standby power and you’re fighting ErP.
The next thing I looked after this was how I could send a wake up call from my laptop to the AMD workstation remotely via Tailscale. This is where I spent some time understanding how this could actually work. I discovered that you need an Always On machine on the same physical network where the machine you want to wake is. For me, that was easy, as I already have a small homelab with Proxmox in my network that I already access via Tailscale. Can be a simple Raspberry Pi, but if you want way more power for cheap you can go with any cheap miniPC. In my case it is a HP Elitedesk G3 which I bought for arouns $100 some time ago.
How things work
First you need to install some things on the Proxmox machine (which by the way, could be any Linux flavour, say Ubuntu if its easier for you. And considering you are probably already connecting via SSH to the Always On machine (if not, its easy to enable) actually you need to install just one thing:
apt install wakeonlan
And I though that was all. NOT.
You need to go back to the AI workstation and do 2 easy things: find the MAC of the workstation and secondly make sure the OS Wake on Lan is enabled. Say what? What the OS has to do with a BIOS WOL feature?
I had WoL enabled in BIOS and it still wouldn’t wake. The reason: the OS network driver also programs the card’s wake register, and it gets the final say at the moment the machine powers down. Many Linux drivers default WoL to off and actively clear the magic-packet flag on shutdown — overriding whatever BIOS set. By the way, wakeonlan sends a thing called “magic packet”. A magic packet is a deliberately odd little frame that a sleeping network card is built to recognise
How the card catches it. When the machine is “off,” the network card isn’t really fully off — it’s drawing a trickle from the standby power rail (this is exactly what the BIOS “Power On By PCI-E” / non-ErP setting keeps alive). In that state the card runs a minimal receiver that scans every incoming magic packet. When it sees the sync stream followed by its own MAC sixteen times, it asserts a hardware wake signal (PME#, Power Management Event) to the motherboard, and the board powers up.
NOT.
This is the part that cost me time. I had WoL enabled in BIOS and it still wouldn’t wake. The reason: the OS network driver also programs the card’s wake register, and it gets the final say at the moment the machine powers down. Many Linux drivers default WoL to off and actively clear the magic-packet flag on shutdown — overriding whatever BIOS set.
So, lets enable WOL – the software part. My AMD workstation is running Ubuntu so I needed to find out the MAC and enable WOL.
First find the real interface name for the network card:
ip -br linkMine was `enp6s0`. Then:
sudo ethtool enp6s0 | grep -i wakeMine showed (and I thought that was what I needed):
Supports Wake-on: pumbg
Wake-on: d
but apparently, D doesnt mean its on. You need G. And you need it to make it survive shutdown.sudo ethtool -s enp6s0 wol gTo make it stick, a tiny systemd service:
sudo tee /etc/systemd/system/wol@.service > /dev/null <<'EOF'
[Unit]
Description=Enable Wake-on-LAN for %i
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -s %i wol g
Next, is time to test from the Always On machine using the MAC of the Workstation I got from the ip -br link command (that works of course if you dont forget to shut down the workstation first):
A magic packet has to go to the subnet's broadcast address, so it floods the whole segment and the sleeping NIC can pick out its own MAC. My LAN is `192.168.1.0/24`, so the broadcast is `.255`:
```bash
wakeonlan -i 192.168.1.255 AA:BB:CC:DD:EE:FF
Well, well, well, it worked. Shut it down again and switch to the Windows Laptop, open Powershell, and send this command to the Always On machine:
ssh root@100.x.y.z "wakeonlan -i 192.168.1.255 AA:BB:CC:DD:EE:FF"(of course, you should replace root with the username you have on the Always On, the first IP is the tailscale IP for the Always On, the next IP is the subnet broadcast address, and the MAC of the Workstation).
If it works, its nice, but I will never be able to remember all these gibberish Ips and mac and so on. So I went further:
On the Always On machine I’ve made a small script to hold the wake command:
sudo tee /usr/local/bin/wake-rig >/dev/null <<'EOF'
#!/bin/bash
wakeonlan -i 192.168.1.255 AA:BB:CC:DD:EE:FF
EOF
sudo chmod +x /usr/local/bin/wake-rig
And being lazy, I could even remember how to call it from my laptop, so I’ve added an alias to ~/.ssh/config (on Windows: C:\Users\<you>\.ssh\config) – you will have to replace the users with your own
Host prox
HostName 100.x.y.z # or the MagicDNS name "prox"
User prox
Host workstation
HostName 100.y.y.y # the workstation's Tailscale IP
User AMD
And to have the commands in every new terminal, drop them in your PowerShell profile. Open it with notepad $PROFILE (let it create the file if it doesn’t exist) and add:
function Wake-Rig { ssh prox wake-rig }
function Sleep-Rig { ssh workstation "sudo systemctl poweroff" }
Done. From now on I just type Wake-Rig to start it and Sleep-Rig to stop it — no IP, no MAC to remember. The addresses live on the relay and in ~/.ssh/config, not in my head.