Repository navigation
Handle discovery where multiple LAN interfaces exist #104
Description
My network arrangement:
modem->wireless bridge a->wireless bridge b->rpi qos & automation->wifi/lan bridge->clients, including hs300.
For the purposes of this discussion, we can simplify that to:
modem->rpi->wifi->hs300
When discovery occurs, from what I can tell, an arbitrary interface (the first interface, linked to the modem) on the rpi is selected. This means the wrong network gets the broadcast packet (which would need to go out via wifi).
This is a known issue, as discussed here, and it can be resolved as discussed in the previous link and here. Also useful is this article about selecting interfaces in linux vs windows
The crux of it is basically:
sockets = []
if windows:
for address in AF_INET addresses:
sockets.append(<a new socket, bound to that address>)
if linux/osx:
for index, interface in socket.if_nameindex():
sockets.append(<a new socket, bound to that interface>)
for socket in sockets:
<do discovery>Obviously, there are additional considerations in the actual coding. Also, there are some ugly convolutions on Windows -- specifically, although you can select the interface to use by binding one of its IP addresses, there's no nice way to get a list of IP addresses. This may mean a module dependency such as netifaces.
Thank you!
Activity
eode commented on Sep 19, 2020
Actually, after testing just now, the address-binding method works on Linux, as well. This method may be superior, both because it can be used universally for linux/win, and because it doesn't require special privileges.
eode commented on Nov 5, 2020
I can confirm that to actually get a list of addresses (in an os-agnostic way), you'll need an external module such as netifaces or ifaddr. Getting local addresses (although small for a python module) is probably beyond the scope of python-kasa. Fortunately, the required module is small, and usage is straightforward:
rytilahti commented on Nov 5, 2020
Is there something wrong using the procedure you mentioned in your latest message in combination with the target kwarg? That being said, I'm not completely against adding a new discovery method for discovering on all connected networks, as long as it and its dependency on ifaddr/netifaces remains an optional.