isc-dhcp: dhcrelay4 needs restarting after boot

[brianjmurrell]

Maintainer: @pprindeville
Environment: x86_64 OpenWrt 23.05.0 r23497-6637af95aa

Description:
I seem to have to restart the dhcrelay4 service after the router is booted in order for it to function. Prior to restarting, even though /usr/sbin/dhcrelay is running it is simply not actually doing any relaying until I run /etc/init.d/dhcrelay4 restart.

I suspect it might be getting started too early in the boot sequence and something it needs is not yet ready/up/etc. Although it's placement at S91 would make that a bit surprising.

[brada4]

Migrate to kea. dhcp relay is discontinued upstream and will be removed soon.
You can reload network services via hotplug scripts if they are slow to accomodate ip changes.

[brianjmurrell]

dhcp relay is discontinued upstream and will be removed soon.

Will it? @pprindeville Is that your plan?

@brada4 Thanks for your input but I'm perfectly aware of the status of the ISC DHCP server project however, having been a previous contributor to it.

However isc-dhcp-relay-ipv4 = 914kB and kea-dhcp4 = 281kB + kea-libs = 2364kB + libopenssl1.1 + log4cplus + boost + boost-system + etc. + etc.

Kea is not so friendly to embedded systems.

As long as @pprindeville is willing to provide isc-dhcp packages, I will continue to use them.

You can reload network services via hotplug scripts if they are slow to accomodate ip changes.

But the point is that I shouldn't have to. The package as supplied by OpenWRT should not need to have every user hack their installation due to this bug. This issue is to document the bug and hopefully bring the maintainer's attention to it in hope that he sees a quick and easy fix so that everyone using it doesn't need to apply their own manual hacks.

[brada4]

eol tracker #20793
relay can be done with dnsmasq included by default

[brada4]

maybe later start can help maybe not

[pprindeville]

dhcp relay is discontinued upstream and will be removed soon.

Will it? @pprindeville Is that your plan?

I have a rewrite of the current dhcpd.init that emits a Kea config file instead. It's blocked on a few dependency PR's like openwrt/openwrt#13765 and openwrt/libubox#6. Some of these PR's are more than 2 months old.

@brada4 Thanks for your input but I'm perfectly aware of the status of the ISC DHCP server project however, having been a previous contributor to it.

However isc-dhcp-relay-ipv4 = 914kB and kea-dhcp4 = 281kB + kea-libs = 2364kB + libopenssl1.1 + log4cplus + boost + boost-system + etc. + etc.

Kea is not so friendly to embedded systems.

But it does drop in nicely to SMB environments. It's more enterprise friendly.

As long as @pprindeville is willing to provide isc-dhcp packages, I will continue to use them.

I was hoping to have retired it by now, honestly, but getting the maintainers of the dependent PR's to merge (or even comment on the PR's) is not an expedient process. Sometimes it feels like we're drifting back into the dynamic that caused the LEDE schism...

You can reload network services via hotplug scripts if they are slow to accomodate ip changes.

But the point is that I shouldn't have to. The package as supplied by OpenWRT should not need to have every user hack their installation due to this bug. This issue is to document the bug and hopefully bring the maintainer's attention to it in hope that he sees a quick and easy fix so that everyone using it doesn't need to apply their own manual hacks.

Part of the issue is also that the maintainers can't always easily reproduce every usage case in a viable environment that's adequate for testing.

[brianjmurrell]

Part of the issue is also that the maintainers can't always easily reproduce every usage case in a viable environment that's adequate for testing.

That's completely fair. I'm happy to instrument and test in any way I can if you have any theories.

[brada4]

Check stat order in luci/system/startup , you might want to start it later when interface IPs are stable configured.

[brianjmurrell]

As I stated in the original description it already starts pretty late at S91. The only startup scripts after it are:

lrwxrwxrwx    1 root     root            21 Oct  9 17:45 S94gpio_switch -> ../init.d/gpio_switch
lrwxrwxrwx    1 root     root            14 Oct  9 17:45 S95ddns -> ../init.d/ddns
lrwxrwxrwx    1 root     root            14 Oct  9 17:45 S95done -> ../init.d/done
lrwxrwxrwx    1 root     root            13 Oct  9 17:45 S96led -> ../init.d/led
lrwxrwxrwx    1 root     root            17 Oct  9 17:45 S98sysntpd -> ../init.d/sysntpd
lrwxrwxrwx    1 root     root            15 Oct  9 17:45 S99snmpd -> ../init.d/snmpd
lrwxrwxrwx    1 root     root            22 Oct  9 17:45 S99urandom_seed -> ../init.d/urandom_seed

The problem is likely that the interfaces are not brought up synchronously with the startup scripts and so can be [not] up at any random point in the startup script ordering.

That said, the two interfaces that dhcrelay is working on are both local network interfaces so they shouldn't have that much delay to coming up.

But indeed, perhaps starting dhcrelay needs to be a hotplug event, not a startup script. Does that seem plausable/reasonable @pprindeville? Granted that it needs to be brought up after two (or more!) interfaces are up makes it a bit more complicated. I'm not sure what facility would be available in a hotplug script to query if the other (than the interface for which the hotplug script is running) interfaces dhcrelay is operating on are up yet. Obviously such a hotplug script would only start dhcrelay on the last hotplug interface-up for all of the involved interfaces.

[brada4]

kea does not include relay itself, you need to adapt dnsmasq as a replacement
If interfaces are very slow to come up you can use rc.local like (sleep 42 ; service dhcrelay reload) &

[brianjmurrell]

Sleeps are hacky, racy and error-prone. Things should be event driven, not waiting and hoping for the best.

[brada4]

migrate to dnsmasq, it is not year into EOL. dhcp-relay=upstream_ip is the needed option.

[brada4]

Actually relay should have been dismissed long ago
https://lists.isc.org/pipermail/dhcp-users/2021-June/022495.html

[pprindeville]

migrate to dnsmasq, it is not year into EOL. dhcp-relay=upstream_ip is the needed option.

The migration to Kea would be done by now if I could get approval for my changes here.

[brianjmurrell]

The migration to Kea would be done by now if I could get approval for my changes here.

But as mentioned before Kea is far far too big[1] for an embedded platform like most consumer-grade (i.e. all of the devices OpenWRT targets and supports) wireless routers. That's a huge amount of baggage just to get DHCP relaying services which is why I proposed enabling BusyBox's udhcprelay

[1] kea-dhcp4 = 281kB + kea-libs = 2364kB + libopenssl1.1 + log4cplus + boost + boost-system + etc. + etc.

[brada4]

kea is not a replacement for dhcp-relayd.
replacement is dnsmasq in base system.