Ups on tsvinc

Enable Wake-on-LAN on Fedora with a Realtek r8169 NIC

Mon, 02 Nov 2026 00:00:00 +0000

This sets magic-packet Wake-on-LAN on the wired NetworkManager connection of a Fedora-family host with a Realtek r8169 NIC, so the NIC stays awake after shutdown and the host powers on when a MikroTik router sends /tool/wol.

Tested on: four Fedora-family hosts with Realtek r8169 NICs (the workstation and a mini PC on Fedora, the gaming PC on Bazzite, the storage box on Fedora), set with the script below; wake from power-off tested on two of them with a MikroTik router's /tool/wol. The setting was re-checked on the workstation on 2026-11-02 (Fedora 44 NetworkManager 1.56.1, ethtool 7.1, kernel 7.2.13).
Not verified: OS, NetworkManager, ethtool and RouterOS versions of the first run [UNVERIFIED: not recorded]; a wake test on the other two hosts; the rollback.
Needs: root on the host; Wake-on-LAN enabled in the BIOS/UEFI setup (check it there; I know of no way to read it from Linux); a wired link to the same LAN segment as the router; a RouterOS login that may run /tool/wol.
Time: 5 min per host, plus one power-off test.
Risk: the test powers the host off. After the change, anyone on the LAN segment who knows the NIC's MAC can power the host on: these NICs report Supports Wake-on: pumbg, with no s, so they cannot check a SecureOn password, and RouterOS's /tool/wol cannot send one either. Reversible: see Undo.

Before you start#

Placeholders used below:
- <IF>: the wired interface name (mine: enp1s0).
- <CONN>: the NetworkManager connection on that interface (mine: Wired connection 1).
- <MAC>: the MAC address of <IF>.
- <BRIDGE>: the router interface that faces the host's LAN segment (mine: bridge).
Check that the wired NIC uses r8169:
```
$ readlink -f /sys/class/net/enp1s0/device/driver
/sys/bus/pci/drivers/r8169
```
Expected: a path ending in r8169. The steps set generic NetworkManager and ethtool options, but r8169 is the only driver I ran them on.

Find the active wired connection and its device:

$ nmcli -t -f NAME,DEVICE,TYPE c show --active | grep 802-3-ethernet
Wired connection 1:enp1s0:802-3-ethernet

Record the current values; Undo sets them back. In a root shell, run nmcli -g 802-3-ethernet.wake-on-lan c show '<CONN>' and ethtool <IF> | grep Wake-on. On all four of my hosts the first printed default, and ethtool showed Supports Wake-on: pumbg and Wake-on: d, with Wake-on-LAN already on in the BIOS. d means the NIC wakes on nothing; ethtool(8) lists the letters, and g is the magic packet.
Note the MAC for the router step: cat /sys/class/net/<IF>/address.

Steps#

Save the script as enable-wol.sh. It walks every active wired connection, sets 802-3-ethernet.wake-on-lan magic in NetworkManager (stored in the connection, applied on every activation) and wol g with ethtool (applied now, no reconnect), then prints both values back.

#!/bin/bash
# Enable Wake-on-LAN (magic packet) on the wired NetworkManager connection. Run as root.
# Persistent: NM applies it on every activation. Immediate: ethtool, no reconnect.
set -euo pipefail
E=$(command -v ethtool || echo /usr/sbin/ethtool)
nmcli -t -f NAME,DEVICE,TYPE c show --active | while IFS=: read -r n dev t; do
  [ "$t" = 802-3-ethernet ] || continue
  nmcli c modify "$n" 802-3-ethernet.wake-on-lan magic
  "$E" -s "$dev" wol g
  echo "$(hostname) $dev '$n': nm=$(nmcli -g 802-3-ethernet.wake-on-lan c show "$n") $("$E" "$dev" | grep -E '^\s*Wake-on:' | xargs)"
done

Run it as root.
```
sudo bash ./enable-wol.sh
```
Expected: one line per wired connection, in the form <hostname> <IF> '<CONN>': nm=<VALUE> Wake-on: <LETTERS>, ending in nm=magic Wake-on: g. All four hosts printed that ending. I did not keep the full lines, so none is shown here. The script runs with set -euo pipefail: if a command fails, it stops there with a non-zero exit, without a line for that connection.
Power the host off.
```
sudo systemctl poweroff
```
Expected: the host shuts down. Leave its power cable in: Wake-on-LAN needs standby power at the NIC.
Send the magic packet from the router.
```
/tool/wol mac=<MAC> interface=<BRIDGE>
```
Expected: the host powers on and boots. In my test I powered two hosts off at 22:45:53, sent the packet at 22:46:21, and they booted at 22:46:40 and 22:46:45, 19 s and 24 s after the packet. If it stays off: see Failure modes, row 1.

Verify#

After the wake, in a root shell on the host, run ethtool <IF> | grep Wake-on. Expected: Wake-on: g. On my woken hosts Wake-on: g was still set after boot. NetworkManager applies magic on every activation of the connection; the ethtool call in the script only sets it right away, without a reconnect.
The NetworkManager value can be read without root. On the workstation on 2026-11-02:
```
$ nmcli -g 802-3-ethernet.wake-on-lan c show "Wired connection 1"
magic
```
Expected: magic.

Undo / rollback#

In a root shell, set back the values you recorded in Before you start (mine: default and d). The script changed every active wired connection: repeat this for each <CONN> and <IF> it printed.
```
nmcli c modify '<CONN>' 802-3-ethernet.wake-on-lan default
ethtool -s <IF> wol d
```
[UNVERIFIED: rollback not exercised]

Failure modes#

Symptom (exact message)	Cause	Fix
The host does not wake from power-off although the BIOS has Wake-on-LAN on; root `ethtool <IF>` shows `Wake-on: d`	the connection had `802-3-ethernet.wake-on-lan default`, and the NIC was powered down at shutdown	steps 1-2: set `magic` on the connection
`netlink error: Operation not permitted`, and no `Wake-on` lines in the output	ethtool run as a normal user: reading Wake-on needs root	run `ethtool <IF>` from a root shell

Field notes#

2026-11-02, the workstation, Fedora 44 (KDE Plasma Desktop Edition), kernel 7.2.13-200.fc44, NetworkManager 1.56.1, ethtool 7.1, r8169 on enp1s0: re-checked as a normal user. NetworkManager still had magic on the wired connection. ethtool printed netlink error: Operation not permitted and the rest of the link settings, with no Wake-on lines at all, so a user-level ethtool cannot show the NIC's Wake-on state. I did not re-read Wake-on as root this time.
2026-10-20 [UNVERIFIED: date from my project notes, not from the run's output], four hosts (the workstation and a mini PC on Fedora, the gaming PC on Bazzite, the storage box on Fedora), all Realtek r8169, versions not recorded: Wake-on-LAN was on in the BIOS of every host, and none of them stayed wakeable: ethtool showed Supports Wake-on: pumbg with Wake-on: d, and the wired NetworkManager connection had 802-3-ethernet.wake-on-lan default, so the NIC powered down at shutdown. I ran enable-wol.sh on all four; each printed nm=magic Wake-on: g. Then (same day or later, the test's date was not recorded) I powered two of them off at 22:45:53, sent /tool/wol mac=<MAC> interface=bridge from the MikroTik router at 22:46:21, and they booted at 22:46:40 and 22:46:45. Wake-on: g was still set after boot.

Notes#

Why I needed it: the hosts run on power stations that keep their outlets live through an outage, so a host that upsmon shut down never sees power disappear and never comes back by itself (the observer design post). That design has the observer send Wake-on-LAN after an outage; here I sent the packet from the router by hand. When a station's output did drop on 2026-11-02, the storage box came back by itself, probably through the BIOS power-on-after-AC-loss setting, which I have not checked (three shutdowns, three causes). The upsmon side is in Run upsmon as a NUT secondary on Fedora and Fedora Atomic.
Only g: the NICs also support p, u, m and b (wake on PHY activity, unicast, multicast, broadcast); each of those can wake the host on ordinary traffic. I enabled the magic packet only.
default is not "off" by name: per the nmcli settings reference, default means "use global settings", and ignore stops NetworkManager from managing Wake-on-LAN at all. A global value in NetworkManager.conf (ethernet.wake-on-lan) is another way to set it for every connection; I have not tried it.
ethtool path: the script uses ethtool from PATH and falls back to /usr/sbin/ethtool.
Router without interface=: per the MikroTik docs, RouterOS then sends the packet as an IP broadcast from the default gateway interface. I always gave the interface.

Sources#

nmcli settings reference, 802-3-ethernet.wake-on-lan: the flag values magic, default (use global settings) and ignore.
NetworkManager.conf: ethernet.wake-on-lan as a global per-device default.
ethtool(8): the wol letters p u m b a g s f d.
MikroTik RouterOS: Wake on LAN: /tool wol with mac and interface; no SecureOn support.

The DJI went silent for four hours

Mon, 02 Nov 2026 00:00:00 +0000

Part 4 ended on a rule for the observer, the Go service on my router that turns two power stations' readings into NUT (Network UPS Tools) status for the machines they keep running: a DJI that stops answering for minutes is an alert in its own right, never a sign that the grid is fine. On 20 October the DJI Power 2000 stopped answering at about 13:10. It answered again a little before 18:00, after I power-cycled it. While the grid was up, nothing alerted me to the silence.

The UPS said 2 minutes at 95 %

Mon, 02 Nov 2026 00:00:00 +0000

My storage box and gaming PC run on a DJI Power 2000 power station used as a UPS, and a monitor on my router decides when they shut down. At 11:39:39 on 1 November, twenty-three minutes into a power cut, my alert channels got this from it:

ups dji2000-t2: LOW BATTERY, its hosts should shut down (runtime 2m0s <= 20m0s (ABC))

And the same for the third tier, against its 8-minute limit. Two minutes of runtime left on the DJI. I could see the station's display at the time. It said about 95 %.

Three shutdowns, three causes

Mon, 02 Nov 2026 00:00:00 +0000

My storage box sits on a DJI Power 2000 used as a UPS. Over two days, 1 and 2 November, it went down a few times. Some of those had an obvious reason and some had none, and every time I looked, the DJI showed about 95 %. I went in looking for one fault: something that turns a full battery into a dead machine.

There were three, and only one of them was clearly the station.

Pulling plugs on purpose

Sun, 18 Oct 2026 00:00:00 +0000

A test that passes tells you the thing works. That is the reading everyone defaults to, and the first power-bank test of the ESP32 bridge was a clean example of why it's wrong.

The bridge from the second UPS post runs off a USB power bank, which charges from the wall. The worry was simple: when the grid goes and the power bank stops charging, does it hold its output steady, or does the board reboot right at the start of the outage it is supposed to report? I cut the power bank's charging, and the board's uptime counter kept going, from 14160 seconds to 14180. No reboot.

The alert about the blackout needs the internet too

Sat, 17 Oct 2026 00:00:00 +0000

Part 5 left the observer able to shut machines down and unable to tell me anything, with one item still open: an alert for an observer that stops. The alerts looked like one function. Log the line, and if a notifier is configured, hand it over:

func alertf(format string, a ...any) {
	msg := fmt.Sprintf(format, a...)
	log.Print(msg)
	if alerts != nil {
		alerts.Send(msg)
	}
}

That function hasn't changed since. The file around it, notify.go, is now 217 lines, and its tests are another 197. Most of it comes from one inconvenient fact: a message about a power cut leaves through an internet uplink, and the cut can take the uplink with it. I can keep the router running on battery. I can't vouch for anything upstream of it.

A null battery reading cleared the low-battery alarm

Fri, 16 Oct 2026 00:00:00 +0000

Here is the first version of the observer handling a station at 12 % charge, on battery, followed by a reading where the bridge couldn't decode the charge:

=== RUN   TestProbeNullSoCClearsLB
    probe_test.go:20: soc 12 -> "OB DISCHRG LB"
    probe_test.go:25: then soc null -> "OB DISCHRG", battery.charge present=false
--- PASS: TestProbeNullSoCClearsLB (0.00s)

OB DISCHRG LB is the line that makes every machine on that tier shut down. One reading later, it was gone. A null in the bridge's JSON means "I couldn't read this field", and the observer had treated it as "nothing to worry about". With no charge in the latest reading, the low-battery check had nothing to compare against its threshold. LB dropped and battery.charge vanished from the replies. In a real outage the hosts would have been stood down while the battery kept draining.

The pin template was for a different plug

Fri, 16 Oct 2026 00:00:00 +0000

The smart plug's vendor app put its energy monitoring behind a subscription. The metering chip inside measures voltage alongside current and power all the same, whatever the app agrees to show. I wanted that voltage. Read off a plug on wall power, it says whether the grid is up, and my power-station UPS needed exactly that: a second opinion on the grid from something not behind a battery.

So the plug had to leave Tuya's firmware for OpenBeken, an open firmware for the Beken chips in most Tuya plugs. That took one evening. Getting the pins right took the next day, because the template I borrowed was for a different plug, and the plug's own leftover settings were the only thing that knew.

The DJI's grid flag is labeled charge type

Thu, 15 Oct 2026 00:00:00 +0000

Update, 2026-11-02: The station's minutes field has a second meaning. Byte 4 of its battery record (tag 0x3020) is a time type, and while it is 1 the minutes are a recharging time, the time to full charge, not a runtime. The bridge now leaves runtime_min out whenever that byte says recharging, and the observer ignores the field while input power flows. The story is in The UPS said 2 minutes at 95 %.

Secure session ready. Battery: ?

Wed, 14 Oct 2026 00:00:00 +0000

Porting a key exchange from Python to C++ should be the boring part. The Python works, it is already validated against this exact station, and mbedTLS ships every primitive it uses: MD5, AES-CBC, P-256, ECDSA, ECDH. Translate, compile, flash. The first run on the ESP32 went along with that, right up to the last line:

found AC180<redacted> XX:XX:XX:XX:XX:XX rssi=-57
connected, mtu=517
KEX: challenge answered
KEX: challenge accepted
KEX: pubkey sent
KEX: pubkey sent
KEX: secure session ready
handshake 1913 ms
RESULT BATTERY_SOC=? DC_OUTPUT_POWER=? AC_OUTPUT_POWER=?

Every step of the handshake reported success. Then came the reads, the part that was supposed to be easy, and the first three came back as question marks. The capture ended there.

The power went out twice. My UPS log saw it once.

Wed, 14 Oct 2026 00:00:00 +0000

Thirty lines of log, one outage. Twenty-two lines on grid, seven on battery, one back on grid. Clean, readable, and short by one event: the plug came out of the wall twice.

The setup itself works. A BLUETTI AC180 portable power station sits between the wall and my workstation as a UPS. Linux reads it over Bluetooth LE, through an encrypted link, with no account and no pairing, in about nine seconds per read. What it can't do is tell you about anything that happens between two of those reads. Neither can anything else built on polling. This one put it in writing.

Twenty-five percent is a countdown

Wed, 14 Oct 2026 00:00:00 +0000

Update, 2026-11-02: The thresholds in this design (60, 35 and 15 % for the three tiers, with the first tier also acting after 5 minutes on battery) are no longer the deployed ones. Since 2026-11-02 all three tiers act at 15 % or 8 minutes of runtime, with no on-battery timer. Why is in Three shutdowns, three causes.

The NUT client's man page has a sentence that decided most of this design before any of it was drawn: