Multiplicity WOL problem

Wake On Lan - wrong SlaveMAC address

After updating to Multiplicity 4.0.5 Pro, the Wake-On-LAN (WOL) feature for Slave computers has stopped working correctly.

The issue is that each Slave machine is now showing an incorrect and identical MAC address that is not related to any real hardware on the system. As a result, WOL packets are being sent to the wrong address, making it impossible to wake the correct machine remotely.

In older versions of Multiplicity, the correct MAC addresses were displayed in the KVM view and WOL worked perfectly.

 

Please investigate and fix this regression, as this completely breaks remote wake functionality for all connected Slave systems.

Move to Multiplicity Area

10,305 views 18 replies
Reply #1 Top

Hello,
Sorry to hear you are having issues. I have forwarded your problem/question to Stardock Support Team for their assistance. Please keep an eye on this thread for any updates. We appreciate your feedback and patience.

Thank you,
Basj,
Stardock Community Assistant.

Reply #2 Top


After updating to Multiplicity 4.0.5 Pro, the Wake-On-LAN (WOL) feature for Slave computers has stopped working correctly.

Whats not clear,; did you update on ALL MP PCs, not just the Primary?

Sean Drohan
Stardock Product Lifecycle Manager

 

 

Reply #3 Top

Yes, of course – it happened after updating all Slaves and Primary.

The option
[X] Enable Wake-on-LAN support (MAC: xx-xx-xx-xx-xx-xx)
suddenly shows random MAC addresses.

 

In my case, I literally saw my correct MAC being replaced by a random one — for example, on my home setup, it changed to the MAC address of my main router.

Reply #4 Top

Hi biuro,

Thank you for reporting this.  We've now logged the issue for internal review.

Internal Ref: ODNT-10210

Best regards,

Adam McGuinness
Stardock Customer Support Specialist

Reply #5 Top

Thanks Adam,

I appreciate that the issue has been escalated internally — this problem breaks one of the key features of Multiplicity in many setups.

To confirm:

The issue only occurs after updating both all Slaves and the Primary to version 4.4.0.5 Pro.
In the “Enable Wake-on-LAN support” field, Multiplicity displays an incorrect MAC address — sometimes the MAC of my router, or a random one.

As a result, Wake-on-LAN from within Multiplicity fails — the magic packet is sent to the wrong MAC address.

Important note:

I’ve double-checked my router configuration (MikroTik) — ARP is configured correctly, and I’m not using any proxy-ARP, spoofing, or non-standard mechanisms.

I’ve also written my own software in Delphi that successfully sends WOL packets to devices in my network using their known MAC address and UDP port 9 — and it works flawlessly.

My program detects the Slave’s IP and correct MAC address without issue, and can wake it up reliably.
Additionally, when the Slave is online, its IP and MAC show up correctly in the ARP table on my PC (arp -a in CMD confirms that).

In previous versions of Multiplicity, the MAC address was always correct and Wake-on-LAN worked without any issues — so the current behavior is a major regression.

I'm really hoping this can be resolved, as I have multiple paid Multiplicity licenses across several machines and rely on it heavily every day.

If I can be of any help, I’d be happy to suggest how to retrieve and pass the correct MAC address in your software — since I’ve implemented this successfully in my own application built entirely in Delphi. I know the WOL and ARP mechanics inside out — both in theory and in practice.

Just to illustrate — here is a real scan report from my WOL tool - MkIpScanner.exe.
One line is bolded — it’s my actual Slave machine used with Multiplicity:

[001] 192.168.2.2  Image no host name  [4C:5E:0C:46:59:48]  [Routerboard.com]
[002] 192.168.2.30  Image NASMK [HTTP]  [00:11:32:2A:EE:50]  [NasMK (DS214+) / Synology / DS214+ / Synology Incorporated NAS, kamera IP]
[003] 192.168.2.32  Image nginx [HTTP]  [00:11:32:2A:EE:50]  [Synology Incorporated NAS, kamera IP]
[004] 192.168.2.100  Image no host name  [56:7A:C2:EE:63:B0]  [Randomized MAC – no match in DB (e.g. Android)]
[005] 192.168.2.102  Image no host name  [1C:90:FF:A6:F6:E0]  [Tuya Smart Inc.]
[006] 192.168.2.103  Image MKI9  [E8:9C:25:C4:CD:A3]  [ASUSTek COMPUTER INC. Router, laptop]
[007] 192.168.2.105  Image no host name  [C2:56:EE:49:45:DE]  [Randomized MAC – no match in DB (e.g. Android)]
[008] 192.168.2.106  Image no host name  [A6:49:6C:10:2A:26]  [Randomized MAC – no match in DB (e.g. Android)]
[009] 192.168.2.107  Image no host name  [3C:F7:A4:9D:81:15]  [Samsung Electronics Smartphone, tablet]
[010] 192.168.2.109  Image no host name  [EC:FA:BC:03:6B:58]  [Espressif Inc. ESP8266, ESP32]
[011] 192.168.2.112  Image HPG2miniDOM  [FC:3F:DB:10:63:AA]  [Hewlett Packard Laptop, printer]
[012] 192.168.2.128  Image Samsung QN91AA 75 TV  [54:3A:D6:6F:B3:C0]  [Samsung QN91AA 75 TV / Samsung Electronics / QE75QN91AATXXH]
[013] 192.168.2.212  Image ShellyHTTP [HTTP]  [A0:A3:B3:67:57:80]  [Espressif Inc. ESP8266, ESP32]
[014] 192.168.2.250  Image HADOM  [D8:3A:DD:F5:71:FF]  [Raspberry Pi Trading Home Assistant Box]

Let me know if you need logs, captures, or any testing help.

Reply #6 Top

MKi9 (192.168.2.103) is my PC - Primary
HPG2miniDOM - my Slave and I have to use this to do WOL

Reply #7 Top

Quoting biuro10, reply 5

I'm really hoping this can be resolved, as I have multiple paid Multiplicity licenses across several machines and rely on it heavily every day.

It has our full attention, brother, I promise.

Thank you for the complete and valuable data.

Sean Drohan
Stardock Product Lifecycle Manager

Reply #8 Top

We should have this resolved in future updates and this is undergoing testing.

In the short term you can alter the registry key where the MAC address is saved and it should be ok unless you configure the machine and save changes.

All the machines are stored here in the Windows Registry : HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Stardock\Multiplicity2\Machines

Each machine has a value called "MACAddress" which can be set to the correct value manually.

 

Reply #9 Top

Thank you very much for looking into the issue I reported – I’ll be waiting impatiently for the update.
Also thank you for describing the temporary registry workaround with
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Stardock\Multiplicity2\Machines

However, this might actually help you track down the bug faster: as you can see on my screenshot, in my WOW6432Node there is no Stardock entry at all


– so it looks like the latest version of the software no longer creates these machine subkeys with their MAC addresses.

I only found entries directly under Software\Stardock\Multiplicity2\Machines (see my second screenshot),


but there is no sign of any MACAddress values there either – so in my case I can’t use your temporary workaround.

 

No complaints of course – I just hope these observations help you pinpoint the root cause. Unless I am missing something and doing it wrong – in that case, please correct me.

Reply #10 Top

Quoting biuro10, reply 9

Thank you very much for looking into the issue I reported – I’ll be waiting impatiently for the update.
Also thank you for describing the temporary registry workaround with
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Stardock\Multiplicity2\Machines

However, this might actually help you track down the bug faster: as you can see on my screenshot, in my WOW6432Node there is no Stardock entry at all


– so it looks like the latest version of the software no longer creates these machine subkeys with their MAC addresses.

I only found entries directly under Software\Stardock\Multiplicity2\Machines (see my second screenshot),


but there is no sign of any MACAddress values there either – so in my case I can’t use your temporary workaround.

 

No complaints of course – I just hope these observations help you pinpoint the root cause. Unless I am missing something and doing it wrong – in that case, please correct me.

You are looking under current user, not local machine which is why you do not see it.  MP settings are machine local not user.

Reply #11 Top

Of course, you are right Neil – thank you so much! I must have been a bit distracted. I’ve now found the correct entries under Local Machine and can edit the MAC addresses as a temporary workaround.

 

Sorry for the confusion and I’ll be waiting for the update ;) I use many of your programs and they’re great!

Reply #12 Top

Hello again,

A Beta version for the software has now been released, which addresses this.  We encourage you to give it a try and let us know what you think.  

For instructions how to get it, and for additional details and feedback, please see:

Thanks again and best regards,

Adam McGuinness
Stardock Customer Support Specialist

Reply #13 Top

Hi,

Thanks for releasing the beta of Multiplicity 4.06 — the slave MAC addresses now show correctly.

Unfortunately, in my home network, the Wake-on-LAN function does not work, even though the MAC address is correct. My own program MkIpScanner sends the magic packet and wakes the computers without any issues.

After testing and analysis, it turned out that the problem lies in how Multiplicity creates the UDP socket to send the magic packet:

If the socket is created without binding (i.e., no bind) or

if the socket is bound to '0.0.0.0' and the magic packet is sent to '255.255.255.255',

then WOL DOES NOT WORK and the packet does not get sent.

However, the following two configurations do work:

Example 1: Bind to '0.0.0.0' and send to the local subnet broadcast (e.g., '192.168.2.255'):

sock := TUDPBlockSocket.Create;
try
sock.CreateSocket;
sock.Bind('0.0.0.0', '0');
sock.MulticastTTL := 64;
sock.EnableBroadcast(True);
sock.Connect('192.168.2.255', '9');
sock.SendString(packet);
finally
sock.Free;
end;

Example 2: Bind to a specific local IP address of the network interface and send to the global broadcast '255.255.255.255':
(this is often used way in my software)

sock := TUDPBlockSocket.Create;
try
sock.CreateSocket;
sock.Bind('192.168.2.114', '0'); // local IP of the network interface
sock.MulticastTTL := 64;
sock.EnableBroadcast(True);
sock.Connect('255.255.255.255', '9');
sock.SendString(packet);
finally
sock.Free;
end;

In my home network, with my Intel I226-V network card and drivers, only these configurations work properly.

Please consider implementing in Multiplicity UDP socket binding to the local IP address of the main network interface, as in Example2. The current way of sending to 255.255.255.255 without binding causes WOL not to work for me.

Thank you for your attention and willingness to improve.

Best regards.


One more thing: cases like mine might be common worldwide. If you implement correct socket binding to the IP of the primary network interface (main network card in the computer), Multiplicity will work properly everywhere.


Tomorrow - hmmm today morning I will test it in my company on another master PC with another network card.

Best regards Mirek

Reply #14 Top

We have a new build for you to try - download it here.

 

You only need to install this on your primary device for the fix to apply - this is an out-of-band release build, while we did quickly test it for bugs/breaks, this is hot out of the oven so we would not recommend installing it on any mission critical endpoints.

Reply #15 Top

Just tested the new build and can confirm that Wake-on-LAN is now correctly waking our Slave computers. Looks good on my end—thanks for the quick turnaround!

Reply #16 Top
    1. When can we expect an official update that includes the properly implemented Wake-on-LAN feature?
    2. I need to use the Scroll Lock key in Windows for one of my applications, but unfortunately Multiplicity blocks it completely — pressing it on the host never reaches the slave, so my app can’t detect or respond to it.
Reply #17 Top

Quoting biuro10, reply 16

 



        1. When can we expect an official update that includes the properly implemented Wake-on-LAN feature?

        1. I need to use the Scroll Lock key in Windows for one of my applications, but unfortunately Multiplicity blocks it completely — pressing it on the host never reaches the slave, so my app can’t detect or respond to it.


 


MP4 4.07 was released some days ago

https://forums.stardock.com/538550/multiplicity-407-released

Sean Drohan
Stardock Product Lifecycle Manager

Reply #18 Top

Quoting sdRohan, reply 17

MP4 4.07 was released some days ago

https://forums.stardock.com/538550/multiplicity-407-released

Yes, I got it. Thank you very much! It works very well, especially the WOL feature.