Skip to content
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

Discovery fails with "can't broadcast discovery packet: No route to host" #2

Closed
lopter opened this issue Sep 20, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@lopter
Copy link
Owner

commented Sep 20, 2015

On more pedantic systems (OpenBSD at the moment) with multiple interfaces the discovery will fail with this error.

This is because discovery packets aren't broadcasted properly: lightsd tries to send packets to 255.255.255.255 (INADDR_BROADCAST) which becomes ambiguous as soon as the system has multiple network interfaces.

There is two solutions for that, I'll probably implement both and make them mutually exclusive:

  • the first solution is to let the user explicitly decide on which address or network interface lightsd should bind its discovery/broadcast socket, this will allow lightsd to broadcast packets using a valid (broadcast) address;
  • the second solution will be for lightsd to discover all the network interfaces on the system and attempt to discover LIFX bulbs on each of them.

I'm looking at implementing the first solution soonish, no ETA for the second solution since it requires more work as network interface discovery is OS-specific.

@Magicking

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2015

Any news on this ?

I'm made a temporary monkey patch (linux specific) to broadcast to every interface while the issue is resolved, patch is here Magicking@ebe166c

Cheers,

@lopter

This comment has been minimized.

Copy link
Owner Author

commented Dec 23, 2015

No real news, but @moonwatcher also complained about it so I'll address it, will see if I do that at 32C3 or after! Really wanna address GH-5 and reverse the new grouping API too.

Anyway, thank you so much for the patch it's helpful and motivating, need to look at it and figure out the portability bits, maybe I'll integrate it just for Linux since it's better than nothing.

@lopter lopter self-assigned this Dec 23, 2015

@Magicking

This comment has been minimized.

Copy link
Contributor

commented Dec 23, 2015

A nice evolution on their part would be to accept multicast (even without IGMP), that would allow to delegate some routing to the network.

edit: changed the link of the commit above due to a missing line.

@lopter lopter added this to the 1.2.0 milestone Jan 7, 2016

@lopter lopter added the bug label Jan 7, 2016

@lopter lopter closed this in 3ba475b Apr 11, 2016

lopter added a commit that referenced this issue May 29, 2016

Properly broadcast LIFX discovery packets on all networks (closes GH-2)
This is really the proper way of achieving the same semantic as
broadcasting to 255.255.255.255 and is kinda half the solution only.
What I'd like to add is:

- bind to all local-only networks (right now lightsd binds on 0.0.0.0);
- watch for network interfaces changes so we can re-bind if necessary,
  this is really the hard and annoying part as each OS has its own
  mechanism for this and some (e.g: BSDs) don't even have it AFAIK.

So that people running lightsd on a machine connected to Internet (that
can happen quickly on a laptop or a phone/tabled) don't have to firewall
56700.

lopter added a commit that referenced this issue Jul 3, 2016

Properly broadcast LIFX discovery packets on all networks (closes GH-2)
This is really the proper way of achieving the same semantic as
broadcasting to 255.255.255.255 and is kinda half the solution only.
What I'd like to add is:

- bind to all local-only networks (right now lightsd binds on 0.0.0.0);
- watch for network interfaces changes so we can re-bind if necessary,
  this is really the hard and annoying part as each OS has its own
  mechanism for this and some (e.g: BSDs) don't even have it AFAIK.

So that people running lightsd on a machine connected to Internet (that
can happen quickly on a laptop or a phone/tabled) don't have to firewall
56700.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.