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

Detect IP address changes #13

Closed
thom-nic opened this issue Aug 6, 2018 · 6 comments
Closed

Detect IP address changes #13

thom-nic opened this issue Aug 6, 2018 · 6 comments
Milestone

Comments

@thom-nic
Copy link
Contributor

thom-nic commented Aug 6, 2018

So, I'm running on a device that may boot up with no Ethernet connected, or it could be boot on a DHCP network, then be disconnected and reconnected to a switch without DHCP, falling back to a ZeroConf IP address, etc. Currently I'm using busybox ifplugd to detect interface events, which in turn trigger udhcpc and zcip (the ZeroConf daemon) to restart. udhcpc and zcip then fire their own scripts when e.g. a DHCP lease is obtained or a ZeroConf IP is allocated.

In mdnsd.c, it looks like ina is assigned once in main() and it's assumed that address will not change. I see SIGHUP will re-read config files but not reload IP address. So I'm left with killing/restarting mdnsd when any IP address changes.

I don't know if the easiest solution is rtnetlink notification, calling getifaddrs() periodically and comparing the result, or letting an external program signal that the IP address has changed.

I also noticed that mdnsd quit with an error Failed writing to socket: Invalid argument presumably when the interface was unplugged. Or maybe there's no "easy" way to handle this, and the right answer is just killing and restarting mdnsd.

I imagine this could be related to #8 but that issue didn't mention address changes.

@troglobit
Copy link
Owner

Thanks for the report! I've been thinking about how to handle this in a portable manner ... ideally I'd like to be able to run mdnsd on *BSD as well, so I've tried to avoid listening to netlink to detect interface address changes.

I think the best solution atm. is to call getifaddrs() whenever we announce the IP, i.e. when the TTL is about to elapse, or when we get a discover message.

Thanks for mentioning the "Failed writing to socket", we should probably add a -p persistent mode that allows mdnsd to retry the same interface (name, not ifindex since that might change) until it comes back.

@thom-nic
Copy link
Contributor Author

thom-nic commented Aug 6, 2018

should probably add a -p persistent mode that allows mdnsd to retry

That would be great! Yes, at the moment my init is very simple - no process supervision - so for the time being, if it's possible mdnsd could die abruptly that's the other reason to restart the daemon on network changes :)

@troglobit
Copy link
Owner

OK, I'll look into it!

(I guess writing an init process form scratch isn't for everyone 🤣 )

@thom-nic
Copy link
Contributor Author

thom-nic commented Aug 7, 2018

I saw finit, and I definitely like it better than busybox's runsv! I just haven't gotten around to pulling in something more sophisticated yet.

@troglobit
Copy link
Owner

Awesome! Yeah, we used runsv (or rather djb daemontools) many years ago. Not really my cup of tea. Then we found Finit and I picked up maintaining+extending that -- mostly engineered for our purposes at work, but there are other users as well, not for everyone though (ymmv).

troglobit added a commit that referenced this issue Aug 7, 2018
This is a feature request that came up in issue #13.  When an interface
goes down, or is temporarily lost, we wait a second and then retry the
interface and reopen the socket.

Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
@troglobit
Copy link
Owner

There, hopefully it works OK for you. Let me know otherwise and we'll reopen the issue.

@troglobit troglobit added this to the v0.8 milestone Aug 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants