I have an HAOS-VM running on a machine attached to my router via cable, and another (wifi attached) machine that I want to WoL from HA.

Apparently, my router does not forward WoL packets from wired ethernet to wifi, so I just plugged in a usb-wifi dongle and connected HAOS via the dongle - wifi works, no problem.

WoL in general also works, I can wake the machine up from my MacBook without a problem. I can also use the very same dongle on a Debian desktop to send WoL packets.

However, doing it from HA fails. My configuration.yaml looks like this:

wake_on_lan:
switch:
  - platform: wake_on_lan
    name: wake_<machine>
    mac: <mac>

I tried deactivating the KVM brigde, so that the VM really only connects via wifi, but no changes here either.

There are no errors in any logs, so it doesn’t look like it’s failing per se.

To me it looks almost like the packet is send to nirvana, but there’s no way to configure the network interface in the WoL platform either.

  • SwingingTheLamp@midwest.social
    cake
    link
    fedilink
    English
    arrow-up
    0
    ·
    5 months ago

    For troubleshooting, start at the destination and work back. Run a packet trace on the target machine, and other machines on the WiFi network to see if any WoL packet comes through at all. If not, then look at the VM host.

    How does HAOS access the USB network adapter? By pass-thru, so it’s like a USB device connected to the VM, or through a bridge on the VM host? If it’s the latter, a Linux network bridge device is often configured not to pass broadcast packets by the firewall rules. (Things like Docker will enable firewall filtering.) Check that the bridge allows broadcast packets through. If it’s the former, the USB pass-thru, do a packet trace from HAOS to ensure that it’s actually sending the packet, I guess.

    • AggressivelyPassive@feddit.deOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      5 months ago

      It’s USB pass through, so there shouldn’t be any filtering.

      Wireshark could be an idea, I’ll check that tomorrow.

      • SwingingTheLamp@midwest.social
        cake
        link
        fedilink
        English
        arrow-up
        0
        ·
        5 months ago

        I realize that I forgot to answer the question! The wake_on_lan integration has a broadcast_address parameter. It doesn’t explicitly let you pick a network interface, but it might be worth trying to set it to the broadcast address of the Wi-Fi subnet. Then the routing table would ensure that the packet goes out on the correct interface.

      • CondorWonder@lemmy.ca
        link
        fedilink
        English
        arrow-up
        0
        ·
        5 months ago

        I second the packet capture idea. Did you remove the virtual nic in the vm or just disconnect it? I’d you just disconnected it the packets were likely still directed to it as it’s the first network device.

        I suspect you’re going to need to use a command line service to do a wol command as the integration doesn’t work let you pick a nic.

  • grue@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    5 months ago

    Huh, I’m surprised that the idea of wake-on-wifi makes conceptual sense to begin with. I mean, with a wired LAN the network card can listen for the magic WoL packet while otherwise being in a very low-power state, but with wifi I’d expect that the thing would have to be fully “on” because of all the transmission overhead needed to maintain the connection. Wired wake-on-lan is a purely OSI layer 2 thing (the card just listens for its own MAC address), but how would wake-on-wifi even know which SSID it’s supposed to be listening to without the OS running?

    • 4am@lemm.ee
      link
      fedilink
      English
      arrow-up
      0
      ·
      5 months ago

      Wake-on-LAN is certainly a thing for WiFi, the problem here might be that the USB bus gets shut off when the device is sleeping, thus disconnecting the WiFi.