xled icon indicating copy to clipboard operation
xled copied to clipboard

Skip discovery to workaround network that doesn't propagate broadcasts

Open scrool opened this issue 4 years ago • 2 comments

Discovery is currently implemented as a broadcast. On some networks broadcasts are not propagated. That effectively means Twinkly devices cannot be found. Unicast connections work just fine (e.g. because they are forwarded across networks).

Twinkly app falls back to unicast for each address on the network. It does this only once - when new device is added to the app and then stores information about the device and addresses it directly.

Doing unicast discovery by CLI would be too expensive.

I'd like to mitigate this by ability to skip discovery - probably implicitly when --hostname is specified.

Skip of discovery might require #59.

scrool avatar Dec 05 '20 19:12 scrool

Just ran into #69 after installing Hamachi, discovery could not get a beacon back. Disabling the adaptor(s) for the moment worked.

Emerica avatar Apr 15 '22 15:04 Emerica

hmm, I was just trying out xled, but my setup is a layer3 network, the IoT wifi stuff is in a separate layer 3 network with its own SSID.

i tried to use --hostname of twinky device, but I do not see any traffic to that IP, only a broadcast to 255.255.255.255:5555

01:09:06.887374 IP xledhost.5555 > 255.255.255.255.5555: UDP, length 9

/usr/local/bin/xled --version xled, version 0.7.0

Is this somehow supposed to work?

mo8Zomo0 avatar Jun 18 '22 23:06 mo8Zomo0