Empty user scripts for udhdpc and odhcp6c where added recently do "document the existence" of that feature.
Personally, I don't think creating an empty file is a good form of documentation in an environment where space is scarce. But I know the feature was overlooked even in openwrt itself (it had a critical bug from 2012 to 2015).
These user-scripts offer an easy way of reacting to changed addresses that is understandable by non-developers as well.
Until now, I used packages to install those files. Naturally, there are now conflicts (But that file is already provided by package * netifd).
But I believe there is something to be had here and I'm thinking about creating a PR adding /etc/udhcpc.user.d and /etc/odhcp6c.user.d (calling the contained files from the respective script) to make it easier for packaged software to tap into these events.
Does anyone see any problems with it?
Anyone else think it would be helpful?
Afaik it has a folder for dhcp-related events already, but it was working only with ipv4. I think that dnsmasq has a similar setup where every change the dnsmasq binary calls a special script, and in that file in OpenWrt there is the hook to call the stuff in Hotplug folders, so you can use that as a base
@bobafetthotmail I'm not sure whether hotplug is the right place or not.
An openwrt-abstraction for reacting to DHCP events would be nice, though.
Should addresses and routes be considered to be "plugged" in?
Open question. I don't know - especially since there already is something there.
I have edited the above post with more information so please refresh the page and make sure you have seen it in its updated form.
Afaik Hotplug is the right place for any event you want to use as a trigger for user-provided or package-provided scripts, as you can see it covers many event sources and tries to standardize them a bit.
I don't know what you mean with
because I'm not using it much myself.
But if you have a usecase for them and you can actually trigger a script on route or address changes you can add that too.
I would argue that it makes more sense to "plug in" addresses and routes on a system-level rather than DHCP events.
But then some DHCP-specific info doesn't make sense anymore (e.g. where to put the timeserver when an IP address is added).
For a new openwrt-level interface, I would try to aim for something clean.
Maybe, /etc/hotplug.d/addresses and /etc/hotplug.d/routes
or /etc/hotplug.d/dhcp-lease, /etc/hotplug.d/dhcp6, and /etc/hotplug.d/ipv6-slaac.
I'd say there a uses cases for both.
The information going in can be very different for DHCP, DHCPv6, router advertisment, and SLAAC.
The real question is probably why don't the DHCP clients generate hotplug events, like other components… but that's surely a harder problem to solve.
EDIT: In the context of hotplug events, I'm sure it's wiser to separate server from client, yes.
As an aside, I'm happy to see my documentation patches started a serious discussion about the DHCP client events problem. It's something that has been bugging me for ages.
As I wrote, I like your changes, just make sure the files aren't lost on sysupgrade.