Did you enable WOL im config?
I assume you are refering to the firewall of VMWare? As there is no windows firewall when it is turned off, only BIOS (and WOL works when sent from another machine) 
No the firewall of the pc they are trying to turn on
Tom, Francis… the WOL is working fine when send from any other machine…so there is nothing wrong with the target… he only cannot get it to work from HA 
2 Likes
Please format your post correctly or it won’t help anyone. https://community.home-assistant.io/t/how-to-help-us-help-you-or-how-to-ask-a-good-question/114371#oneone-format-it-properly-16
The most likely errors are a missing configuration of the VMWare NIC to allow the magic packet to be routed (magic packets are normally not routed and hypervisors normally make their own internally LAN) or the broadcast_port, which needs to be correct for the magic packet to be send (if the HA installation only have one NIC, then leave it out).
1 Like
You might be the only one who potentially read through my full post here 
.
I believe this tracks with what I’m observing, although I have no resolution to the issue at hand (which is frustrating).
The VMWare Fusion Network Adapter is setup as such:
And similarly the Ethernet bridge interface is set to essentially be a bridge:
The external Hassos address is a 192.168.7.255 subnet (being a separate virtual assigned Mac address over the host machine).
From here, I’m just a bit stuck.
Iteratively speaking, I’ve attempted using a broadcast address amongst other fields… maybe I should play with the host address?
1 Like
Unless you’re looking for log (there are no log emitting for wake_on_lan:) I’m unsure of what you’re asking for or looking for. . .
Bingo – you read my post!
Correct. The GUI would emit errors if I didn’t.
As noted in the original post:
I have no issue calling the appropriate command from separate applications on multiple devices or respective terminal commands outside of hassos.
I have 2 current use cases, my PC and my lg tv – both I’ve verified work with every other tool.
I’m unsure where to fix it but I’m nearly 100% sure Wally has it. If the WOL packet works somewhere else this is purely a sending issue. And as Wally said Hypervisor network stacks usually don’t pass that stuff.
Love the vote of confidence. It’s interesting because I’ve read through a ton of posts with WoL issues, no one seems to mention the virtualization portion. The only “solution” I’ve seen involves bridging host networks 100% within a Docker container which:
A.) Isn’t an option on macOS with Docker (or certain other OS’s)
B.) Is a crippling change if you want separate interfaces/traffic/NICs/etc
C.) Removes the benefits of running a dedicated hassos with powerful hardware
D.) Removes a loooot of benefits of using a dedicated VM over a striped down Docker instance.
Unsure of why this isn’t discussed more, maybe people just don’t dive in enough?
Because you’re trying to mix enterprise scale network controls with consumer grade gear. Sometimes it doesn’t translate.
It was a reply to a post that the author has since deleted.
Ah, I didn’t see that
That’s not true. I have host bridging on my macbook containers (for work) using named networks in my docker-compose stacks. Perhaps you are referring to Docker Desktop, which is limited in it’s execution (by design)?
Also not true as you can have multiple docker stacks that are bound to individual NICs and interfaces.
Also also not true. I have HA Core (docker) running on “powerful hardware” (Ryzen7 3700 with 64GB of RAM). The container takes as many resources as it needs. It runs in a separate stack connected to a central swarm across multiple hosts.
This one is partially true, but also not. Yes, you do lose some management benefits, but at the same time, there’s an ease of use factor going on as well. The only benefits that I know of that I lose are things like explicit CPU bindings and perhaps some over-simplicated things (like privileged mode execution for containers).
With all that said, it’s been a long time since I’ve used Fusion, but IIRC, you do need to bridge the hypervisor’s internal lan with the host LAN. Otherwise, VMF just swallows the outbound magic packet and it never gets broadcasted.
1 Like
Not to dive too far into the Docker vs full VMs
That’s not true. I have host bridging on my macbook containers (for work) using named networks in my docker-compose stacks. Perhaps you are referring to Docker Desktop, which is limited in its execution (by design)?
The option I’m referencing is quoted here.
The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.
This has been a crippling limitation for some time now…
Also not true as you can have multiple docker stacks that are bound to individual NICs and interfaces.
This might be true, but I’m referencing where you’ve bound the networking traffic to the host’s network. At this point, you’re much more constrained and will inherit the same IP address/Mac/etc as the host – aka no multi NIC use-age with designated traffics without some form of VM mapping.
Also also not true. I have HA Core (docker) running on “powerful hardware” (Ryzen7 3700 with 64GB of RAM). The container takes as many resources as it needs. It runs in a separate stack connected to a central swarm across multiple hosts.
Last time I benchmarked Apple’s Virtualization framework, on Apple Silicon devices, Docker was notably resource constrained and didn’t perform nearly as well as full VMs. I might want to revisit/check this.
This one is partially true, but also not. Yes, you do lose some management benefits, but at the same time, there’s an ease of use factor going on as well. The only benefits that I know of that I lose are things like explicit CPU bindings and perhaps some over-simplicated things (like privileged mode execution for containers).
Snapshot states amongst how interfaces work for management are powerful. Docker is also a pain-in-the-a** when it comes to maintaining/updating/etc software. I don’t want to dive too far down this rabbit hole, but I do not have nice things to say to people who call Docker less hands on – Docker is very hands on. I can’t express how many features have broken without any sort of response/updates/communications on macOS from Docker stuff – with no ETAs on fixes and skew on docker version support. These issues rarely happen in a proper VM.
With all that said, it’s been a long time since I’ve used Fusion, but IIRC, you do need to bridge the hypervisor’s internal lan with the host LAN. Otherwise, VMF just swallows the outbound magic packet and it never gets broadcasted.
Yeah, this is where I need to find a solution.
Note, definitely would like to avoid #holywar territory on this front
lol agreed. 
True, but if you’re still using Docker Desktop to manage your stack, there are bigger problems to deal with.
Eh, in my instance (I have a LOT of containers spread across multiple hosts), the real hands-on work was building it all out (which I spent way too much time on). After I got all my extends and docker-compose files done, it was simply spin up the swarm and deploy. I haven’t had to actually touch anything aside from adding/removing containers for a couple of years now. All my pulls and monitoring are automated.
I’ve faced the same issue with hypervisors on Mac with the only 100% reliable solution I’ve found is (laughably) Parallels. I will agree, Mac support for containerization SUCKS and has for many years. But unless it’s for work (where I have a dedicated devops/entops team to fall back on), I don’t run any of my smart home kit on Mac. Everything here is Linux. I even have a couple of older Mac Mini boxes running Ubuntu serving as hosts lol.
Ha! Same. We’re good.
Anyhow, I’m going to spin up a VMF instance and see if I can get WOL to broadcast out. I’m not entirely hopeful, but I’ll give it a shot.
2 Likes