Possibility of improving default udhcpc/odhcp6c user script mechanism

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?

1 Like

Added info to the wiki:

The amount of space used by such a file is negligible even for OpenWrt, especially because it is in the squashfs (compressed/readonly) partition.

If you want to make a PR I think you should hook this up to the Hotplug system, OpenWrt has consolidated all events to call user-created or package-added scripts from there https://openwrt.org/docs/guide-user/base-system/hotplug?s[]=hotplug

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

This should be the file called by dnsmasq to trigger hotplug scripts https://github.com/openwrt/openwrt/blob/master/package/network/services/dnsmasq/files/dhcp-script.sh

Here is the old thread where we discussed this in the past Udhcpc.user script documentation and how to hotplug for DHCP events - #10 by bobafetthotmail

1 Like

@vgaetera Cool - here we go!

@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.

That's your opinion. It's common pratice in OpenWrt, and the space used is negligible, as the rootfs is squashfs, lzma-compressed.

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.

That's for DHCP server (dnsmasq), not client events.

1 Like

@rsalvaterra point taken.
what do you think about where to add the replacement?

See my review. :wink: As I wrote, I like your changes, just make sure the files aren't lost on sysupgrade.

yeah, should the dhcp client events go to another folder?


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
/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.

Adding subfolders in Hotplug for different kinds of events is not a problem, so yeah you can do that if it makes sense.

The only thing is that the current dhcp folder should still receive the same events to not break retrocompatibility.

1 Like

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. :slightly_smiling_face:

Well, in this case, we also need to make sure any existing /etc/udhcpc.user and /etc/odhcp6c.user continue to work.