No bulbs detected with network lock feature of VPN

[eidermar]

This looks really interesting and I'd love to get this to work. Unfortunately I do have basically the same problem as the Windows 10 guy, just on Ubuntu.

I do have 6 bulbs (Color 1000) on the network, all turned on and working perfectly with numerous apps on several devices.

You can find the Log file here: http://pastebin.com/FYwY1hvs

Add-on debug logging is enabled. This is for starting up kodi waiting for the "service is running" notification, heading to the add-on settings and starting automatic discovery.

Thank you for your work on this plugin, hopefully you can find a way to make this work!

edit: I forgot, when trying to disable the add-on it crashes kodi altogether :-)

[eidermar]

Before you go on a hunt for bugs, I might have found the cause for this. Probably it's related to pfsense. I will investigate further and update here.

[sanghviharshit]

Yes, that would be helpful. I checked your logs and I couldn't find any errors as such except it doesn't have any log after it started the discovery. I will also add some more logging in the future release to have some more clarity on the discovery process.

[eidermar]

I was able reproduce the discovery issue with and without a network lock feature of my VPN client. As soon as it's disabled the discovery works flawlessly and fast. Now I don't know enough about how the discovery of the lifxlan feature works, but I know that the network lock prefers IP adresses over hostnames. Do you know if any hostname resolving is involved in the discovery process?

[sanghviharshit]

It uses Lifx LAN protocol for discovery and AFAIK, it broadcasts the message (to 255.255.255.255) and all the bulbs respond with their information. Is it possible the VPN doesn't allow broadcasting messages?

[eidermar]

I'm trying to find out. I also was in contact with mclarkk to see if he has any ideas. So far everything without success. I'll keep digging.

[eidermar]

VPN support advised me to research which IP addresses are needed for the protocol to work and whitelist them all. Now, could you maybe tell me which IP addresses I need to whitelist? I already tried the 192.168.0.0/16 range but that alone didn't help. Any other addresses that might break the script if they are not reachable?

[sanghviharshit]

I just read the discussion at https://github.com/mclarkk/lifxlan/issues/19 As I said, it sends UDP broadcast message on the network for bulb discovery. This is not something you will be able to add to VPN's whitelist. But as he suggested, discovering the bulbs using specific IP/MAC address is something I can look into. But I don't know how easy/difficult will it be for the end user to find IP address or mac address of the bulbs.

[eidermar]

I don't have a problem finding the IP addresses but I have no idea how to change the script so it uses IP/MAC addresses. Also it will probably be necessary to hand out static DHCP addresses to the bulbs to do so, right? Might be a problem for some people with consumer level routers. I'm completely lost here. The automatic discovery is obviously the convenient way for users to do this, and by all means it should work here too. Is there an easy or fast way to check if the bulbs will react if called by IP/MAC - a little script snippet that I can run to test?

[sanghviharshit]

Yes, you will need to use static IP addresses for this setup to work. To test this setup, you can lifxlan on your machine by sudo pip install lifxlan and run hello_world.py or any of the basic examples from examples directory to see if automatic discovery works at all.

After that you can run this script to check if connecting to light using MAC & IP works - create_light_object.py

You will need to add the bulb's IP to VPN whitelist.

[eidermar]

Thank you so much for trying to help out here. I tried all the scripts in the lifxlan examples folder and they work just fine with network lock disabled. As soon as enabled they fail to discover anything. Then I tried to run the little script you posted (with the correct IP and MAC address of course) but that triggered an error message:

light = Light("XX:XX:XX:XX:XX:XX", "192.168.0.108", verbose = True)
TypeError: __init__() takes at least 6 arguments (4 given)

This is unrelated to whether network lock is enabled/disabled.

[sanghviharshit]

I'm sorry about that. I haven't really tested this code because I'm not home yet. But the following snippet should work.

from lifxlan import *
import sys

light = Light("12:34:56:78:9a:bc", "192.168.1.42")
print(light)

replace line 4 with this if the above still fails -

light = Light("12:34:56:78:9a:bc", "192.168.1.42",service=1, port=56700, source_id=0, verbose=True)

[eidermar]

Thanks. The code works now, but as I feared same problem. Bulb send response when network lock is disabled, but nothing when enabled. I think I'll have to give up on this. Really a shame because this is a beautiful plugin and I was waiting for some time now to be able to do this like the guys with Hues were.

Again, thank you for trying to help and investing your time to share your work.

[eidermar]

OK, I'm back after all :-) I think I maybe have an idea of what might be the problem. I saw in wireshark that some packets of the communication between bulb and script are utilizing IPv6. Is that correct? For several reasons IPv6 is not allowed within my VPN client to avoid DNS leaks. Is there a way to have this working in IPv4 only?

[sanghviharshit]

No, I don't think the reason for this not working has to do anything with IPv6. I believe, your VPN is simply not broadcasting on your local network. This has been reported by someone else on the Kodi Forums as well

[eidermar]

yup, you're probably right. unfortunately they are not very cooperative at this point. they promised to investigate wireshark packets, but so far no response. I'll keep you posted.

[eidermar]

I was able to solve to problem. As far as I can tell after investigating with wireshark the problem was that the bulbs and the computer were sending their broadcast packages on different network interfaces. By forcing 255.255.255.255 outside the VPN tunnel this was resolved. Now everything seems to be working perfectly.