I have been trying to set up an environment for my hypervisor, which is just a Debian Bookworm running qemu.

I have been using the web interface Cockpit to help me see things when the terminal is too arid. But in doing so, I had to switch from using systemd-nerworkd to NetworkManager.

Recently, I learned how to create a bridge network so my VMs and the host can communicate with each other. But after doing that my wakeonlan stopped working. I understand that this is expected because the router now 'sees' the MAC address of the bridge instead of the one from the nic.

From what I understand, wakeonlan works at the MAC level of the networking model. I tried using arping from other clients in the network and they cannot "see" the MAC address of my hypervisor (bridge).

Now I'm starting to think it might not even be possible to have a bridge at the same time as wakeonlan. Is this possible? If so, how can I do it? preferably using NetworkManager.

  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – Community Bot
    Mar 24 at 13:21

1 Answer 1


Wake-On-LAN is a hardware feature: it's not intended to reach the main interface participating in routing: the bridge, but always the physical interface: the actual NIC interface set as bridge port. The usual method used for Wake-On-LAN is to use the Magic Packet (original 1995 AMD white paper: PDF), rather than other methods (such as unicast, broadcast or ARP) to avoid spurious unwanted wake ups.

Normally, Wake-On-LAN can be enabled using ethtool (eg: on eth0) with:

ethtool --change eth0 wol g


# ethtool eth0 | grep -i wake
    Supports Wake-on: pumbg
    Wake-on: g

But actually, NetworkManager, if not told otherwise, will probably disable again Wake-On-LAN on the interface it manages either before or after a suspend making it fail either the first time, or the 2nd time (and after reboots). So this is not enough. NetworkManager has to be told to use Wake-On-LAN on this interface.

nmcli commands below could be done using the GUI applet instead if a GUI is available.

If for example NetworkManager has these connection names: Bridge connection 1 and as slave interface Ethernet connection 1, the feature has to be activated on Ethernet connection 1.

# nmcli connection show id 'Ethernet connection 1' | grep -i wake
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --

which is documented in nm-settings-nmcli(5):


The NMSettingWiredWakeOnLan options to enable. Not all devices support all options. May be any combination of "phy" (0x2), "unicast" (0x4), "multicast" (0x8), "broadcast" (0x10), "arp" (0x20), "magic" (0x40) or the special values "default" (0x1) (to use global settings) and "ignore" (0x8000) (to disable management of Wake-on-LAN in NetworkManager).

While there might be a default somewhere else, setting it explicitly to magic will make sure Wake-On-LAN stays enabled on this interface.

Set it to magic like this:

nmcli connection modify 'Ethernet connection 1' 802-3-ethernet.wake-on-lan magic

Because this setting might not be applied immediately by NetworkManager (even including after nmcli connection reload) it should also be set manually, just once after having configured this, as described above (change the interface name as needed):

ethtool --change eth0 wol g

Now about usage. There is no reason the bridge's Ethernet MAC address will be the same as the NIC's Ethernet MAC address. This is even explicitly not the default in modern systemd systems (though NetworkManager itself might choose to copy it to the bridge). So ARP even if it's still in the cache of a system in the same LAN will never be the correct method to have a Magic Packet reach the physical interface. When suspended one can't rely the physical interface to be kept in promiscuous mode (because it's a bridge port) anymore. Anyway such ARP would also fail if the cache entry is evicted from that system's cache.

If using IP as payload mechanism, just always use a destination that will resolve into a MAC Ethernet broadcast destination (FF:FF:FF:FF:FF:FF) and not attempt an ARP resolution: either the LAN broadcast or the directed broadcast (eg in LAN that would be

For example, if the NIC's MAC address is 12:34:56:78:9a:bc, using wakeonlan, just do, from the same LAN:

wakeonlan 12:34:56:78:9a:bc

or if the system has access to multiple LANs, eg and and the system to wake is in the latter:

wakeonlan -i 12:34:56:78:9a:bc

Other tools may have or lack other features. Eg: etherwake requires instead to specify an interface and won't use IP but Ethernet type 0x0842 which is a de facto type reserved for Wake-On-LAN (but doesn't have to be used), and requires root or adequate capabilities to be used:

etherwake -i eth0 12:34:56:78:9a:bc

This is outside the scope of the question but to give pointers, wake from remote over internet requires help from the Internet gateway: it has to run custom software, or to do NAT to a broadcast and enable routing directed broadcasts which is always disabled by default for security reasons. As described above, setting a permanent ARP address usually doesn't help with a bridge, but it could be a fake permanent ARP address for the purpose of waking the system, by reserving a fictive IP address (not used anywhere, including not present on the bridge interface) in the LAN for such purpose.

  • Tested this on an actual physical system (running nothing fancy) that was able to be woken up before, and was still able to be woken up after configuring it with a bridge and its NIC as (single) bridge port through NetworkManager.
    – A.B
    Mar 24 at 11:39
  • Thanks for your detailed answer and for all of the in-depth explanations of how things work. I'll try this tonight. Mar 26 at 2:15
  • Ah, about your last comment, fortunately I don't need over-the-internet wake-on-lan. I can do that using a VPN server I set up. But it is always good to know more about a particular technology. Thanks again. Mar 26 at 2:17
  • It all works beautifully! Thanks. I think I was missing the command from ethtool and NetworkManager was not saving the config on reboot or something. :) Mar 27 at 5:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .