NIC no longer responsive to Wake On Lan when powering off from IncusOS

IncusOS
1

Not sure I understand this one and haven’t poked around much yet, myself, but just a quick wonkiness report to mention that WOL is no longer responsive after powering down from IncusOS on my device with the default network setup. BIOS settings are all good, can wake this device when poweroff-ing from two other distributions (Ubuntu Core, Fedora).

Interestingly, the lights are still on the ethernet port after poweroff like they are when the device does wake from lan so I don’t think the NIC is being placed in a totally powered down state.

Any info that would be helpful or any steps I should try? Will play with it later today to try to better understand, regardless. Thank you!

2

Did you enable wake-on-lan in the IncusOS network configuration?

3

… whelp. Sorry about that. Hah.

Will check the source before lazily firing off a post next time. Thanks as always!

4

It’s a pretty new setting, I think it’s only been there 2-3 weeks.

Basically:

ethernet:
  wakeonlan: true

Within an interface entry, so looks like this in a more complete config:

config:
  interfaces:
  - addresses:
    - dhcp4
    - slaac
    hwaddr: 10:66:6a:16:e4:a1
    lldp: true
    name: enp5s0
    strict_hwaddr: true
    ethernet:
      wakeonlan: true
  time:
    timezone: UTC

We also support setting the specific Wake On LAN mode and some other stuff, but the syntax above enables the most common (magic packet).

5

Great! Thanks for the example.

I’ve already said it in fewer words but I’ve never been truly satisfied with the existing offerings that serve as a low maintenance hyper visor so have been doing my own thing on various base systems for tens of years. IncusOS is the first real contender in my book. Thank you so much!

1 Like
6

I may have spoken too soon. Added wakeonlan but it’s still ignoring the magic packet. Have also tried with disable_energy_efficient.

Poked around a bit and wonder if I’m doing something wrong. The reported hwaddr is the factory nic address which is what I’m sending but noticed MACAddressPolicy=random. Don’t see any other address but am I sending the wrong one?

7

I guess the first thing I’d check is whether the NIC turns off when the computer is shut down. For wake on lan to function, the NIC should maintain a link with the switch.

8

The port remains on as far as I can tell. The power led is constant and the activity led flashes at the same cadence as when shutdown from the other distributions.

9

You could try:

wakeonlan_modes:
- phy
- unicast
- multicast
- broadcast
- arp
- magic

Effectively explicitly turning on every single type of WoL on the NIC, except for secureon which would require a password be set.

10

Note that most of those would result in the machine being brought back up almost immediately as they’d basically trigger on any network activity.

11

Added all modes, machine stayed off. Current config (x’d out last half of the mac):

config:
  dns:
    domain: lan
    hostname: incusos
  interfaces:
  - addresses:
    - dhcp4
    - slaac
    ethernet:
      wakeonlan: true
      wakeonlan_modes:
      - phy
      - unicast
      - multicast
      - broadcast
      - arp
      - magic
    hwaddr: 00:e0:4c:xx:xx:xx
    name: enp2s0
    required_for_online: "no"
    roles:
    - instances
  time:
    timezone: UTC
state:
  interfaces:
    enp2s0:
      addresses:
      - 172.20.10.181
      - fdd5:4d68:3c2a:6e55:2e0:4cff:fe01:1b68
      hwaddr: 00:e0:4c:xx:xx:xx
      mtu: 1500
      roles:
      - instances
      - management
      - cluster
      routes:
      - to: default
        via: 172.20.10.1
      speed: "1000"
      state: routable
      stats:
        rx_bytes: 256723
        rx_errors: 0
        tx_bytes: 95741
        tx_errors: 0
      type: interface
12

Okay. That’s pretty odd. Anything wake on lan related in incus admin os debug log?

Sadly I don’t have any system that I can test that on here as on the physical side of things, I either have laptops using dongles for ethernet or servers with bonded 100GbE cards which aren’t terribly likely to do WoL :slight_smile:

1 Like
13

Powered off a second time it and it started waking up instantly. Set the modes back to “magic”, powered off, instantly restarted. Powered off a second time, now not responding to a magic packet.

So I guess applying the network config isn’t enough and a power cycle is required to have modes take effect. But my nic is still not responding to magic packet alone.

(and nothing interesting regarding wol or the nic in the logs.)

I’m still leaning toward MACAddressPolicy=random maybe contributing. I’ll try to build with persistent or none and see if that does it.

14

Unrelated but I think I spotted a (super minor) bug. I think these properties are swapped, no?

Edit:

15

That would cause problems of its own though. On IncusOS, we operated everything through bridges. The reason why we give a random MAC address to the physical NIC is because we’re giving the physical MAC address to the host interface instead.

Basically you have a setup like this:

<physical NIC> -> <bridge> -> <host interface / bridge side> -> <host interface / host side>

_p112233445566 -> enp5s0 -> _i112233445566 -> _venp5s0

That assumes an interface named enp5s0. In this scenario, the interface actually carrying the physical NIC is _venp5s0 which is par of a veth pair. Everything else is on random MACs as they shouldn’t themselves originate any outside traffic.

1 Like
16

Did you try using the secureon mode for Wake-On-LAN? This seems to use a magic packet with a user controlled secret (MAC formatted), so maybe that works regardless of the configured MAC?

17

Ah! Will give that a go when I’m back on my machine in a few hours.

18

No luck with secureon and sending the packet with password. Will keep tinkering.

19

@stgraber found something! I have tailscale enabled and it logged out the interface properties, including the reported hwaddr of the physical nic (which was random, consistent with your explanation). Sent a magic packet with that address and it started right up.

Logged addresses with some masking:

_i00e0deadbeef : ae:e1:d3:xx:xx:xx
_p00e0deadbeef : 2e:24:d1:xx:xx:xx
_venp2s0       : 00:e0:de:ad:be:ef
enp2s0         : 86:1a:fe:xx:xx:xx

Sending 2e:24:d1:xx:xx:xx worked but that address is randomized on every boot so it’s only useful once.

20

Okay, I’m looking at adding some logic to restore the MAC address of physical interfaces on system shutdown for any interface that’s got WoL enabled, that should take care of that.

1 Like