Wake on Lan issues

Hello,
I have forwarded your questions/problems to the Stardock Support team for their assistance. Please keep an eye on this thread for any updates. We appreciate you feedback and patience.

Thank You,
Basj
Stardock Community Assistant.

I trust you have the setting enabled on a per Secondary basis:

Or are manually sending it:

What examples can you give of WOL working in other situations?

Are the Secondary PCs on wireless or Ethernet?  If the former, if you have them connected via Ethernet, does it work then?

Sean Drohan
Stardock Support Manager

I have the same issue.  Wake on Lan works just fine using WakeMeOnLan application, but doesn't work with Multiplicity Pro KVM.  Neither the direct seamless "Send Wake-on-lan message" nor Connect through the "which computer would you like to control?" window wakes anything up anymore.

They are all connected via wired Ethernet.  And once the machines are awake, I can control them just fine with Multiplicity (seamless as well as remote).

Note that the WakeMeOnLan default settings for the magic packet is using the "Send the Wake on Lan Packet to"/"broadcast address according to IP address" option.

All machines are fully updated and all settings are standard except that IPv6 is off for most/all of my machines.  Could the IPv6 choice be the issue?

Hello,

Sorry to hear you are having trouble.

I have noted the issue internally; thank you for the reports.

Internal ref: 0206824

Sean Drohan
Stardock Support Manager

Ok, so after some testing, it seems to work.  Following some basic Windows 10 WOL set-up:

https://winaero.com/blog/how-to-use-wake-on-lan-on-windows-10/

With a few exceptions:

• I turned the Secondary firewall off to avoid any port issues (you may want to test with that).
• And as a baseline WOL tester, I used this app:
  https://www.microsoft.com/en-us/p/wake-on-lan/9wzdncrdfshb?activetab=pivot:overviewtab

Tested with the firewall on and it still worked. 

Both MP, and the WOL app woke the Secondary.

Sean Drohan
Stardock Support Manager

Yeehaw!  I found the problem with Multiplicity. 

Apparently, if you have multiple network adapters installed (even virtual ones like a VPN or for VMWare/VBox), the adapter that is pinged with a magic packet may not be the correct one! 

This does NOT affect the Seamless or KVM control code, because once the Secondary Computers are awake, they can be Connected To or controlled just fine, with no problems. 

However, they still can't be sent a magic packet to wake them up even after you've controlled the same machine, put it to sleep, etc.

I tested this by disabling the other network adapters and then unloading Multiplicity.  Once I re-ran Multiplicity with only one adapter enabled (the wired adapter), the wake-on-lan functionality of Multiplicity was restored.  The Seamless command, the Menu command, and the Connect auto-wake-up all returned to proper working order.

So, I don't know why the wrong adapter is getting bound to this command but not elsewhere.  Is it alphabetical (EDIT: nope) or binding to whatever adapter wakes up first or...

That's for you fine folks to figure out.  I hope this helps. 

EDIT: List of Adapters

Ethernet - RealTek PCIe GbE Family Controller - wired, correct, network adapter

Ethernet 2 - VirtualBox Host-Only Ethernet adapter - for VirtualBox Virtual Machines

ExpressVPN - OpenVPN TAP Adapter

vEthernet (Default Switch) - Hyper-V Virtual Ethernet Adapter <- I suspect this bad boy 

Quoting Excalpius, reply 6

Yeehaw!  I found the problem with Multiplicity. 

Apparently, if you have multiple network adapters installed (even virtual ones like a VPN or for VMWare/VBox), the adapter that is pinged with a magic packet may not be the correct one! 

This does NOT affect the Seamless or KVM control code, because once the Secondary Computers are awake, they can be Connected To or controlled just fine, with no problems. 

However, they still can't be sent a magic packet to wake them up even after you've controlled the same machine, put it to sleep, etc.

I tested this by disabling the other network adapters and then unloading Multiplicity.  Once I re-ran Multiplicity with only one adapter enabled (the wired adapter), the wake-on-lan functionality of Multiplicity was restored.  The Seamless command, the Menu command, and the Connect auto-wake-up all returned to proper working order.

So, I don't know why the wrong adapter is getting bound to this command but not elsewhere.  Is it alphabetical (EDIT: nope) or binding to whatever adapter wakes up first or...

That's for you fine folks to figure out.  I hope this helps. 

 

 

EDIT: List of Adapters

Ethernet - RealTek PCIe GbE Family Controller - wired, correct, network adapter

Ethernet 2 - VirtualBox Host-Only Ethernet adapter - for VirtualBox Virtual Machines

ExpressVPN - OpenVPN TAP Adapter

vEthernet (Default Switch) - Hyper-V Virtual Ethernet Adapter <- I suspect this bad boy 

 

End of Excalpius's quote

This hasn’t been addressed yet on stardocks side?  I just purchased and ran into the same issue.  Could sure use an option to choose which adapter it’s pinging since it apparently chooses a different one than every other WOL app I use. 

this is huge for me.  Probably also explains why prevent sleep on other machines isn’t working. 

what’s super weird is I’ve checked the Mac against the Mac in my other apps that work, and it’s the same.  Its my understanding that Mac is tied to a specific adapter.  So it’s just ignoring the Mac it lists in settings and pinging elsewhere?

yea, disabled my bt adapter, disabled my wifi adapter, disabled my vpn adapter, still no wake on lan on either of my secondaries. 

works with everything else.  hmmmm

Hello,

I have forwarded your report to the Stardock support team for their review and recommendations.

Please keep an eye on this thread for any updates.

We really do appreciate your feedback, thanks.

AzDude
Stardock Community Assistant

fwiw, prevent sleep on secondaries is also not working.  hypothesizing that the reasoning between one not working and the other is the same.   In case that info is helpful to the staff as far as the culprit.

Outside of those two items everything else seems to work perfectly.  Unfortunately having functioning WoL is absolutely paramount for me.   I really dont want to have to open up something else to wake up the pc's when its conveniently located right within multiplicity which i'd be running anyways.

this wouldnt have to do with the fact that my other working WoL apps see the mac address as all capitalized same as presented by ipconfig whereas multiplicity lists it in lower case.

I wouldnt imagine so, but im dead out of ideas.   The problem has to lay with multiplicity as it works via every single other avenue ive tried.   wake-on-lan from ios.  teamviewer from within windows or IOS.  Magic Packet uwp app.  

just bumping this guy.   getting WoL working with multiplicity is super important to me.   Hate having to use something else to wake my pc.   loathe it.  its annoying, redundant, inconvenient. 

anyways.

assuming @Excalpius is on point with his assertion that the problem lay with multiple adapters, can a developer hop in and suggest perhaps a string that exists or can be added to the registry to force it to magic packet a specific adapter?

i'm not sold thats the issue on my end but thats the next step in process of elimination i guess.   My laptop only has the WAN miniports listed, my main ethernet adapter, and a integrated wifi adapter. 

no vlan or vpn etc. 

either way, even operating under the assumption that IS the issue, you cant expect your entire userbase to wait for and buy another version to have this fixed, and you certainly cant expect your entire base to disable all their ethernet adapters so your software's magic packet lands on the right one.

perhaps we need the option to adjust number of packets/frequency of packets sent just in case thats where the problem lay.  

do we know what port theyre sending them on?

it does see the pc's, as i only slept one of them, and via the tray menu thats the one that showed up in the wake on lan list

its just failing on the waking part.

i just disabled the wifi adapter so only the ethernet one was enabled, still nothing.  venturing its sending a single packet as opposed to several, or its going over some port it shouldnt be.  or ... something.

need someone much more versed in the workings, like a developer that participated in the relevant code base.

Multiplicity will send one magic packet and the adapter chosen will be whatever the OS decides is the right one.

Clearly in some situations this isn't producing the right adapter probably because unlike other packets there is no IP address to guide it so it will no doubt be the default adapter.

It is possible in Windows to order interfaces by priority so if everything is on the same network you should be able to use this : https://www.windowscentral.com/how-change-priority-order-network-adapters-windows-10

I'll look into that for sure.   i dont doubt my ethernet adapter IS my priority adapter, what are the chances it is not on both secondary pc's?

not to mention i disabled the wireless on my laptop and it still didnt work.  ive never even connected via wifi on them but i digress.

it does have an IP address doesnt it?  you have multplicity on your primary "telling" which IP is connected AND telling what mac adapter which directs it to the proper Ethernet adapter.   Ive checked via my stand alone wake on lan app, and the mac address does line up.

I think we may need the option to send more packets perhaps?  My standalone app (one of them that i can see the option) defaults to 5.    the other i have no idea but it still works. 

Either way, in the name of being thorough - ill look into that link you shared.  Thanks!

yea Get-NetIPInterface shows my local area connection with the highest priority (lowest number - 5) out of them all.

a powercfg -devicequery wake_armed shows my ethernet adapter as having WoL enabled.  (obviously since other apps wake it fine)

I tried disabling ipv6 on my gateway and restarting (even though its dual stack and uses ipv4 internally anyhow) with no change.

its something else, and it only effects multiplicity.

So i swapped my primary and one of the secondaries.

It wakes fine in the other direction.

So im at the point that someone with a deeper understanding needs to take over.  I've exhausted all i know to do, and now i know it at least doesnt effect my main (usually primary) pc.

Just my secondary and my secondary-laptop will not wake and only with multiplicity.

harmph.

all i need is to understand A) what is different in how multiplicity is behaving relative to other apps and/or what is different between my main pc and the secondaries (as wol with multiplicity works TO the main pc)

ha.  the sleuth has discovered more.... stuff....

So my secondary (which i changed to primary for testing) can wake BOTH the other pc's fine.

seems the problem is with the sending of the packets from the main pc and again only with multiplicity.   Theyre just not being sent, or not getting to the other pc's in that direction.  What on earth....

SO, can anyone pin down what would cause this behavior?   Soooooo close!

In either case, you have demonstrated that MP does indeed send/receive with no changes to it.  Logic dictates that something other than it is impeding its sending/receiving. 

Glad to see you have made progress, however. 

Sean Drohan
Stardock Support Manager

Well, ive went into my gateway (even though it should have no bearing) and disabled packet filtering, turned off its firewall.  I have disabled windows firewall.  I have disabled all non microsoft services.  I have disabled all startup items.

nothing is running but multiplicity.  

Wont wake the other pc's

Normally id beginning thinking somethings busted with the sending of said packets and the current intel driver relative to my nic.   but......

I open up the UWP app "Magic Packet" click the manually added shortcut to the other pc's mac address...  One click.
wakes up fine.

So its sending the packets.   the other pc's are getting the packets.   its just not sending em from multiplicity..  or... something.

Taking all suggestions.

in the meantime ill be going back to re-enable everything under the sun

Neil, this did indeed solve the problem for me.  THANK YOU!

Checking the Get-NetIPInterface (per your link), it appears as though other interfaces (virtual machines, VPNs, etc.) were taking lower (meaning first) priority over the physical LAN adapter.  Changing its priority from Automatic to 1 solved the problem for me. 

As mentioned in another post, other programs let you select the network adapter their program is bound to, so maybe that's a feature that can be added in your next pass of this wonderful program.  While this is a good workaround, I can see the possibility that this hard priority change might cause problems for default traffic routing for VPNs in particular?  Maybe not.

Either way, thank you for your help and for this incredibly useful program.    

Best regards always.

but doesnt the mac address do just that?  send it TO that exact adapter?  neither teamviewer nor Wake-On-LAN(magic packet) allow you any configuration beyond the mac.  Teamviewer not even that but i imagine it uses its own proprietary means.

Either way, my ethernet adapter is lowest priority on all 3 machines set at 5.

the problem lay elsewhere as evidenced by the fact that my secondary can wake my primary and my laptop (when i switch the primary/secondary role) as can my laptop wake both the others.

only the primary does not wake the other two.

Any input on which port is used to send the packet?  Im about to start tearing into softwares that can detect the send/receive of it.

dont know what else to do.  

see this is my baseline, and it works.  #boggle

https://www.microsoft.com/en-us/p/wake-on-lan-magic-packet/9nblggh51pb3?activetab=pivot:overviewtab

I believe that your problem is different than mine and flyingbuttmonkey's.  Good luck!

anyone aka sean or neil able to tell me what port this sends its WoL magic packets over?   Got a few small utilities to monitor packets.

todays mission is to can the WoL issue.