Wake on LAN only broadcasts on one network interface

[andrewgreenwood]

Bug report

Describe the bug

I wanted to make my PVR backend go to sleep when idle. MythTV provides this functionality, and the PVR add-on for Kodi supports Wake-on-LAN to facilitate this. This functionality appears to be part of Kodi (the addon calls XBMC->WakeOnLan with the MAC address) so I believe this to be related to Kodi rather than the specific add-on.

First, I tested by manually forcing the backend host to go to sleep (actually suspend to RAM), then using a Wake-on-LAN tool on my router to power on the host via its MAC address. That worked.

Then I tested Kodi on Windows: I input the MAC address into the PVR add-on settings, forced the backend to sleep, restarted Kodi and accessed the PVR functionality - the backend host remained asleep. I waited a few minutes and eventually decided to wake it up via my router's WOL tool again (which worked.)

Wireshark (on the Windows PC) showed that the WOL packet was being sent on only one of the network interfaces (I have VirtualBox on this PC and it was showing on that interface). No WOL packet was being sent on my physical network interface according to Wireshark.

After disabling the VirtualBox ethernet interface, Kodi was able to wake up the remote host, indicating that Kodi does send the packet and that the receiving system is able to respond correctly to the packets (by waking up), however the packets might be sent on the wrong interface.

It seems that the code in xbmc/network/Network.cpp sends the packet to the INADDR_BROADCAST address, and reading about this online it seems this will send a single packet on only one (unspecified) network interface.

Expected Behavior

Kodi's Wake-on-LAN should wake up the host whose network card has the specified MAC address.

Actual Behavior

The remote host remains asleep if the networking stack chooses a different network interface to broadcast the WOL packet on.

Possible Fix

Send one WOL packet per available network interface: Loop through each network interface that has been assigned an IP address, identify the broadcast address for each of these and send the WOL packet to those instead of the single packet to the INADDR_BROADCAST address.

To Reproduce

Ensure your computer has multiple network interfaces present (either physical, or some virtual ones e.g. VM interfaces or VPN links) and enabled.
Try using Kodi to wake up a machine on the same network via Wake-on-LAN (e.g. install MythTV PVR add-on and put the MAC address of that computer in the settings and try to access the PVR functionality).
Note: This should be reproducible with any Kodi component that uses Wake-on-LAN, I have only had experience with this functionality via the specific add-on I refer to though.

Debuglog (added 28th Nov 2018)

Looking at the code it doesn't look like it will give any useful information in this case (only that it successfully sent the WOL packet - not which interface it sent it on.)

Debug log from Windows: https://paste.kodi.tv/ogawupadit.kodi

Relevant lines:
21:29:26.704 T:2948 INFO: CNetworkBase::WakeOnLan - Magic packet send to '00:25:90:98:38:0e'
21:29:29.715 T:2948 INFO: CNetworkBase::WakeOnLan - Magic packet send to '00:25:90:98:38:0e'

Wireshark packet example (for first WOL packet) from 192.168.56.1 ("VirtualBox Host-Only Network" interface: https://paste.kodi.tv/avapimohuv

Screenshots

n/a

Additional context or screenshots (if appropriate)

n/a

Your Environment

Used Operating system:

• Android

• iOS

• Linux

• OSX

• Raspberri-Pi

• Windows

• Windows UWP

• Operating system version/name: Windows 10

• Kodi version: 18 / Leia

[Rechi]

@andrewgreenwood your debug log is missing. Was there something unclear about A debuglog is always mandatory when creating an issue. Provide one!?

[andrewgreenwood]

I will add debug logs this evening (from PC and Pi) then.

I omitted them because the WOL code did not seem like it would've logged anything other than it having sent the WOL packet and the reason for it not working seemed clear from the diagnostics I'd performed. So it didn't look like they would give anything useful.

[andrewgreenwood]

Debug log for Windows added, along with example WOL packet from Wireshark.
Raspberry Pi log will be added later.

[andrewgreenwood]

It seems this does not affect LibreELEC on my Raspberry Pi after all - the MAC address had a space in front of it. I collected a debug log and was reviewing it when I noticed invalid MAC addresses being reported. After removing the space and running tcpdump on the MythTV backend, I saw it receive the WOL packet.

I suspect it could happen though if the WLAN adapter is enabled (mine isn't).

[thezoggy]

have you tried doing: https://kodi.wiki/view/Wake_on_lan

[andrewgreenwood]

have you tried doing: https://kodi.wiki/view/Wake_on_lan

I've looked at that but haven't tried it as I noted that further down the page it notes that it doesn't wake up PVR servers (which is what I was trying to do). Initially I thought it might be a bug in the PVR add-on but the code for that just uses a method provided by Kodi - so as far as I'm aware, this would just call the same method.

[ghost]

I can also confirm that using either the built-in wake on lan function by @t4-ravenbird or the Advanced Wake On Lan by mandark alongside an enabled VirtualBox (6.0.10) ethernet adapter on Windows 10 will fail to wake the remote server. Disabling the VirtualBox adapter allows Kodi to successfully wake the remote server.

With three different Kodi WOL implementations failing, this seems to suggest that it is a core issue within Kodi's network interface management.

All other external tools and scripts that I have used to send a WOL to this remote server has no problems waking it up even with the VirtualBox adapter enabled.

[kib]

As a related aside: I recently discovered that Virtualbox wrongly / does not implements setting the adapter priority on Windows 10 - they have not understood that windows 10 (finally) removed the adapter priorities in favor of using metrics and set their own metric wrong when creating the adapter, which for instance causes multicast receiving to fail. This might be related

You might also be able to resolve the entire issue by giving the virtualbox adapter a manually assigned metric higher than the one the real adapter has.

[ghost]

Thanks for the information @kib. However, I did further testing and found out that this issue isn't isolated to VirtualBox and is affected by any enabled virtual interface, as originally noted by @andrewgreenwood.

With an enabled Wireshark Npcap loopback adapter or a Windows VPN connection (WAN miniport (L2TP)), Kodi will fail to send a WOL packet correctly unless all virtual interfaces are disabled / disconnected.

I did find a workaround for those that need to have VirtualBox's adapter remain enabled: go into the adapter's Properties and uncheck "Internet Protocol Version 4 (TCP/IPv4)." This does not appear to affect a VM's connection to the internet or to the host machine. However, this workaround will not work for a VPN connection so a proper fix is still needed.

[ghost]

I just had a chance to look into how to set the interface metric and found that you were right, it does solve the issue with all adapters, including the VPN connection, so disabling TCP/IPv4 is unnecessary.

[fuzzard]

Closing with the confirmation that appropriate metric use works.