Multiple Interfaces

[JohnnyErnest]

On a Raspberry Pi 3 I have an interface that links to the internet (192.168.2.3 eth0) and its own WiFi AP (192.168.42.1 wlan0) for which my lightbulbs (Lifx and TP-Link LB130) connect to. I can do an ARP ping on the 192.168.42.1 wlan0 interface's subnet with scapy in Python and get the MAC Addresses for all of them. However, LifxLAN's device discovery by UDP broadcast doesn't seem to pick up anything.

[mclarkk]

This seems more like a question for some networking folks than a question about the library, but I can see what I can do to help!

On Linux, lifxlan's UDP broadcast works by sending packets to the address 255.255.255.255, which on most vanilla setups broadcasts the message to all hosts connected to the local network, and does not send anything past the router. However, I have found that OS and networking configurations can change this behavior. You'll need to verify whether sending messages to 255.255.255.255 works the expected way with your networking setup.

[mclarkk]

Actually, a really quick test you can do is go into lifxlan/device.py line 47 and set broadcast = "192.168.42.255", then reinstall the library from source (if you installed with pip before, I'd remove the pip version just in case). I bet that will work!

[mclarkk]

Hey, I think I made a general fix that should work for everyone with these problems. Can you pull the latest code, build it, and test it out?

[JohnnyErnest]

No worries managed to figure that one out looked over the LIFX docs and got it all working.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: ML Clark notifications@github.com Sent: Saturday, December 9, 2017 9:23:42 PM To: mclarkk/lifxlan Cc: Shining Knight Light; Author Subject: Re: [mclarkk/lifxlan] Multiple Interfaces (#64)

Hey, I think I made a general fix that should work for everyone with these problems. Can you pull the latest code, build it, and test it out?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mclarkk/lifxlan/issues/64#issuecomment-350522328, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYvkRDeFaPV1bnGmQZj_rpBvYQdHiqIwks5s-069gaJpZM4QW6i0.

[JohnnyErnest]

Seems like btw on my network because of some oddity in my router's DNS getting forwarded to another router 255.255.255.255http://255.255.255.255 would not work but 192.168.2.255http://192.168.2.255 would work. It was probably because the main router was on 192.168.1.255http://192.168.1.255 it was going to the main router subnet instead of my router subnet even though it was being used from my router subnet and not the main router.

So mine was kind of a one-off deal basicallywhich is not normal but it might be worth mentioning I don't know.

Get Outlook for Android

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: ML Clark notifications@github.com Sent: Saturday, December 9, 2017 9:23:42 PM To: mclarkk/lifxlan Cc: Shining Knight Light; Author Subject: Re: [mclarkk/lifxlan] Multiple Interfaces (#64)

Hey, I think I made a general fix that should work for everyone with these problems. Can you pull the latest code, build it, and test it out?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mclarkk/lifxlan/issues/64#issuecomment-350522328, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYvkRDeFaPV1bnGmQZj_rpBvYQdHiqIwks5s-069gaJpZM4QW6i0.

[mclarkk]

It's definitely worth mentioning and I'm glad you did. A lot of people have the problem where 255.255.255.255 doesn't work for them, and as I understand it using that address has been deprecated. Instead people recommend using the broadcast address for each subnet (like 192.168.2.255). A lot of people on Windows have been having problems related to the 255.255.255.255 address too. It would really help me out if you could try the new library code with your setup, but if not, I'm glad you got a fix!

[JohnnyErnest]

Well the fix isn't much of a fix. I figured out the raw protocol and made a C# implementation because my UI system is actually in Unity3D, but it doesn't make much sense now that I realize it to do things that way. I do one broadcast packet to turn off the lights at night, but then you know sometimes in the morning I go to the closet lights are off have to get on the computer just to turn the lights on.

Didn't even bother with just flipping it off and on to see if the light is smart enough to reset to a white light if the brightness was previously 0 on the switching on event.

Got me thinking though when you emailed me that implementing on a Python/Django stack with your library would be a better solution all around.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: ML Clark notifications@github.com Sent: Sunday, December 10, 2017 1:54:35 AM To: mclarkk/lifxlan Cc: Shining Knight Light; Author Subject: Re: [mclarkk/lifxlan] Multiple Interfaces (#64)

It's definitely worth mentioning and I'm glad you did. A lot of people have the problem where 255.255.255.255 doesn't work for them, and as I understand it using that address has been deprecated. Instead people recommend using the broadcast address for each subnet (like 192.168.2.255). A lot of people on Windows have been having problems related to the 255.255.255.255 address too. It would really help me out if you could try the new library code with your setup, but if not, I'm glad you got a fix!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mclarkk/lifxlan/issues/64#issuecomment-350531394, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYvkRAtNFoCtDoPPCTk5kcYtgNsy5TCzks5s-447gaJpZM4QW6i0.

[JohnnyErnest]

Just tried from the latest git, put my broadcast IP 192.168.2.255 into Device.py around line 47 where you mentioned and it all works now just great for my setup as expected.

Problem I think is that with this particular router in my bedroom, it's a Belkin N450 I got from RadioShack when it was closing for a pretty good deal, it has one problem with it that I can't seem to get around that it forwards the DNS to the main AT&T router on 192.168.1.254, and it doesn't seem like there's a way to change that. Problem is it doesn't give me a manual DNS setting anywhere that I can see for a DNS server assignment when using DHCP to get the router WAN IP it just gets it all from the main router.

So on my router I can ping individual addresses by IP or by MYPC.local but not by MYPC.mylocal.net because the DNS resolution I think is happening at the main router so DNS lookups from 192.168.2. to anywhere on 192.168.1. work just fine, but DNS lookups on 192.168.2. to anywhere in 192.168.2. don't resolve so I have to append hostnames with .local or just use the IP address.

I would put them all on the same subnet and WiFi SSID but had issues with this actually, that AT&T U-Verse router has problems with some hardware connecting to it and can go down very easily to at least 2 pieces of equipment I've owned unless I segment them off into their own routers. Had a problem with my TP-Link lights I had before going down a lot on the main router. We've all sorts of issues here with things like printer problems and the like on the main AT&T router and they seemingly go away when putting them behind a secondary router it's likely a physical or data-link layer level problem with the actual hardware rather than actually TCP related, just from trying to diagnose the various issues I've seen.

It's most likely a very rare problem to have so I don't know if it's entirely worth the effort of parameterizing get_broadcast_addrs() with an override if the user wants or just documenting and making mention of this if they run into an issue with their network in scenarios where local DNS resolution is a problem because of a secondary or tertiary router that forwards the DNS lookups outside of its own subnet.

[mclarkk]

Lots of other people have problems with 255.255.255.255 that, like your situation, would be solved by sending broadcast messages to the specific broadcast address for each subnet the device is attached to, so I made that change. You shouldn't need to put your broadcast IP in device.py, the library should just work. Can you try running the library code unmodified to see if device discovery works for you?

[MaxValue]

This! This issue fixed the problems i had. Setup is:

Script using lifxlan running on a Linux server(which acts as a router at the same time).

Before i updated to 1.1.9 the lights never showed up, except when i ran the script from a normal machine in the same network. I even thought my firewall settings were off.

Thank you very much for making this work (at least for me). My broadcast address is set to 10.0.0.255 if that helps.

[mclarkk]

Yay! I'm glad the update fixed discovery for you! That's great news, thanks for the feedback.

[Einstein42]

Just a quick note on this. Looks like your code tries to create the broadcast address assuming it is a class C network /24 and returns (192.168.1.255 or similar). While this works for the majority of users that would probably be running it. With the same example if I was using a /28 the broadcast address is 192.168.1.15.

A bit more logic might need to be added at some point. Just my .02

Thanks for your work on this as always.