-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LIFX Discovery fails. #54
Comments
Did you figure this out? Looking to do a similar relay but adding custom ports 6666 and 6667 to get discovery working for Tuya devices. I also want to use @scyto's Docker image if possible. |
unfortunately not, please let me know if your find a solution |
That is a broadcast address of 255.255.255 is not a multicast address, i have no idea if that would be considered valid by multicast relay or not, but maybe that's why it is not working, have you done a network sniff to verify what address tuya is using and what sort of packets? I note other tools seem to rely on DHCP discover (home assistant for one); this would indicate tuya may not be using mDNS-like or SSDP-like multicast protocols. To start (for testing purposes) I would recommend you have no firewall rules enabled between the VLAN except ANY <> ANY = allow. |
Hey @scyto — thanks for your feedback. I'm starting out with no firewall but two VLAN's. Main VLAN and IoT — my network is running on a UDM PRO. I have a Raspberry Pi4 on the main VLAN and I'm using a package called homebridge-tuya on top of Homebridge (node based, similar to Home Assistant) to get my local devices discovered. Auto discover fails. Moving the device to my main VLAN makes auto discovery work, so I've confirmed it's an issue with multiple VLAN's. I looked at the code and it is attempting to discover on port 6666 and 6667. I then looked around for more packages doing Tuya auto discovery and found this broadcasting code, which is the well-known tuya-convert that makes it possible to flash a Tuya device with Tasmota. That's Python based, so probably more your world? :) It seems to indicate that it's using 0:0:0:0 as the broadcast address. Would I then do I did not yet attempt to install the Docker on my UDM PRO but I plan to try that today or tomorrow using these custom UDP ports in addition to the standard ones (I am also having issues with casting to Chromecast devices from my main VLAN to my TV's on the IoT network), with the purpose of making it work across my VLANS. Still getting my feet wet on networking, so my only question for now is. What would be a good command line sniffer to sniff all broadcast traffic on all ports on a Linux / Raspberry Pi? I'd like to be able to sniff and follow progress while setting things up, so I can confirm what chatter is hitting the server. |
I have tested with chromecast with no firewall rules (i don't actually run vlans myself so haven't bothered with tightening firewall rules) and that should work fine. That code only shows that it is a UDP broadcast and that it is listening on all interfaces (0.0.0.0) i think. this is a good tutorial https://danielmiessler.com/study/tcpdump/ good luck! |
Happy to report back that I was successful in getting broadcasting working with Tuya devices over VLAN's on my UDM Pro. In addition to that my Chromecast LG TV connected to my IoT network is now also able to stream from my Mac through Chrome on the main VLAN. I ran docker like this (for testing, the plan of course is to remove verbose logging and run it in a screen):
--noMDNS as I am running that on the UDM PRO (may revisit that if something is not working). Thank you @scyto for the docker image and your help here. Thank you @alsmith for the Python relay code :) |
@jaddel Since I hijacked your thread here, I thought I'd give you a tip on how you may be able to figure your situation out — sorry if you already tried this but this is just how I would attack it. It seems you are unsure about the port. Use tcpdump directly on the UDM PRO to sniff on the incoming broadcasts and try to identify your device. If you look at the device that is not working/broadcasting in your clients page in UniFi, and not the IP address of the device in question then you can do this after a ssh root login in the UDM PRO:
Replace that IP with the IP of the device. Keep it open and wait for your device to send a broadcast which it should do within seconds. If it doesn't, try power cycling the device. Note down the port, add it to the --relay in the OPTS argument. This technique should make it possible to figure out any broadcast port by any device, even if it's a no-name device with no documentation. HTH! Let us know! |
Sorry to also hijack this post @houmark but do you know of any youtube tutorials that explain how do do this in a step by step guide? Without any guidance I'm a little overwhelmed but would love to learn how to do this! Thanks! |
@jaddel I made it work in my setup. Only differences are that I have a couple more VLANs (maybe I went a bit crazy with it) and that I use an old Raspberry Pi Model B that does not support docker or podman. Here is the command I used.
Some details about my setup:
Thanks you all for the helpfull informations on this thread. |
First of all thank you for your awesome work!
Im trying to setup LIFX discovery on my UDM between my private an iot Lan but they just won't show up by auto discovery.
Setup: UDM with UDM Utilities by https://github.com/boostchicken/udm-utilities
This Multicast Relay Dockerized by: https://github.com/scyto/multicast-relay
Added Broadcast Address:
Broadcast Address: 255.255.255.255
Port:56700
My testing starting command:
podman run --rm -it --network=host -e OPTS="--relay 255.255.255.255:56700 --verbose" -e INTERFACES="br0 br30" scyto/multicast-relay
Am I doing something wrong?
The text was updated successfully, but these errors were encountered: