Repository navigation
Hyper-V (and probably virtualbox) break UDP discovery #101
Description
I'm not sure if this a strictly a bug, but I'm reporting here so people are aware of it and can work around the issue. I do have a workaround, but I haven't done enough testing to see if the workaround breaks Hyper-V, so YMMV.
I'm running Windows 10 with Hyper-V installed and have an HS110 on my network. When I run kasa or kasa discover from this machine I get nothing.
Direct IP connection also works fine, as does connect by hostname.
If I disable the Hyper-V vEthernet virtual adapters, discovery works fine.
I'm not confident on terminology, but it looks as though the problem arises due Hyper-V virtual adapters having higher priority than the physical ethernet card - more precisely, on my machine the interface metrics for both the vEthernet adapter and the vEthernet Default switch are than lower interface metrics than the physical card.
I fixed problem this by changing the interface metrics on all of the virtual adapters and switches to have higher metrics than the physical adapter. After this discovery works.
Notes:
-
Hat tip to @jamesbarnett91 - the virtualbox note on https://github.com/jamesbarnett91/tplink-energy-monitor pointed me in the right direction.
-
https://mikefrobbins.com/2018/11/08/managing-the-hyper-v-default-switch-in-windows-10-version-1709-and-higher-with-powershell/ got me started on interface metrics. This page also suggests this may only be a problem for older versions of Windows 10 and upgrades of these older versions (where I am).
-
This may or may not break Hyper-V - I'll report back when I've had time to experiment before.
-
This fix may or may not work for virtualbox as well.
-
The following powershell commands allowed me to edit interface metrics (setting requires admin privileges).
- Grab ifIndex for adapter with:
Get-NetIPInterface
- With admin enabled powershell, set the interface metric for adapter 12 to 45.
Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 45
Activity
fixit9660 commented on Aug 26, 2020
I don't know how related this is but I'm running a FreeNAS 11.3-U3 and have built a Jail to run tplink-energy-monitor in, also running FreeBSD 11.3. I get the same symptoms, I can directly contact the HS110 but the tplink-energy-monitor won't discover the HS110. I've been starting (very slowly because I'm not familiar with FreeBSD) down the route of sniffing the packets on the wifi, but haven't gotten far. I'll have to look at the interface settings and see if the metrics changes make the same difference.
BuongiornoTexas commented on Aug 26, 2020
I assume a jail is a virtual environment. You could try disabling the jail network interfaces and running tplink-energy-monitor on the host OS (this is pretty well what I did on Windows and it worked).
cristipurdel commented on Aug 26, 2020
I am also having issues with VirtualBox
Below is the output of my Get-NetIPInterface
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
3 Ethernet 9 IPv6 1500 25 Enabled Connected ActiveStore
20 Bluetooth Network Connection 2 IPv6 1500 65 Disabled Disconnected ActiveStore
19 Local Area Connection* 13 IPv6 1500 25 Enabled Disconnected ActiveStore
13 Local Area Connection* 12 IPv6 1500 25 Disabled Disconnected ActiveStore
18 Ethernet 2 IPv6 1500 55 Disabled Disconnected ActiveStore
26 Ethernet IPv6 1500 5 Enabled Disconnected ActiveStore
15 Wi-Fi IPv6 1500 35 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
3 Ethernet 9 IPv4 1500 25 Disabled Connected ActiveStore
20 Bluetooth Network Connection 2 IPv4 1500 65 Enabled Disconnected ActiveStore
19 Local Area Connection* 13 IPv4 1500 25 Enabled Disconnected ActiveStore
13 Local Area Connection* 12 IPv4 1500 25 Enabled Disconnected ActiveStore
18 Ethernet 2 IPv4 1500 55 Enabled Disconnected ActiveStore
26 Ethernet IPv4 1500 5 Enabled Disconnected ActiveStore
15 Wi-Fi IPv4 1500 35 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore
Can you please detail the values which should be used for
Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 45?
Ethernet 9 is my current VirtualBox
fixit9660 commented on Aug 26, 2020
BuongiornoTexas commented on Aug 26, 2020
@cristipurdel
Repeating my earlier warnings: a) this is not my area of expertise and b) you may break your virtual box set up by making these changes.
The numbers in the first column are the interface index and the numbers in the fifth column are the metric, so for Ethernet 9, your command would be: Set-NetIPInterface -InterfaceIndex 3 -InterfaceMetric <new metric value>.
However, I'd suggest a better first step might be systematically disabling all interfaces except the one you are using and testing if this resolves your problem. If it does, then you can re-enable interfaces one at a time until you find out which ones are causing the problem, and then you can modify the metric interface for these. (this is is the approach I took for my problem).
kirichkov commented on Aug 27, 2020
Have any of you tried providing explicitly the interface? Discover supports this just for such situations - https://python-kasa.readthedocs.io/en/latest/discover.html#kasa.Discover.discover
BuongiornoTexas commented on Aug 27, 2020
@kirichkov I don't think the interface option is available from the cli executables (which is essentially all I need at the moment). Also, adjusting the interface metric makes tp-link-energymonitor work again - which I very much require.
As an aside, from the reading I've done, it seems as though this was a misconfiguration issue in some generations of Hyper-V, but because I haven't fired up a VM in a while, I don't know what side effects changing the metric will have.
kirichkov commented on Aug 28, 2020
Changing the metric means your packets start traveling a different route through the network. It all depends on your configuration whether you'll experience this. The kernel will choose the path with the lower metric if two routes can get the packet to its destination. Normally Python-kasa advertises on all interfaces, but many OSs simply don't bind the discovery to all interfaces and choose one. It appears your guest OS chooses which interface to use based on the interface's metric, so that's why your workaround works. If you're routing completely different subnets changing of the metric should have no undesireable side-effects.
BuongiornoTexas commented on Aug 29, 2020
Thanks for the explanation, which helps build my understanding. It looks like I need to do a bit more reading on hypervisors to get to grips with this (which may be in the distant future!).
In my case, it's been much more of a necessary fix than a work around. Making the change also sorted massive dns lookup delays and eliminated a problematic stutter in spotifyconnect clients.
rytilahti commented on Apr 9, 2022
Issues caused by complex network setups are not something this library can fix, hope you got your setup working though!