Commit
6f30f08d0e ("dnsmasq: add fallback for default dhcpv4/dhcpv6
values") changed dnsmasq.init to default the 'dhcpv4'/'dhcpv6' UCI
options to 'disabled' when a 'config dhcp' section leaves them unset:
- config_get dhcpv4 "$cfg" dhcpv4
- config_get dhcpv6 "$cfg" dhcpv6
+ config_get dhcpv4 "$cfg" dhcpv4 disabled
+ config_get dhcpv6 "$cfg" dhcpv6 disabled
The intent was to match odhcpd, which already treats an unset value
as disabled, so both backends behave the same way for newly created
configs. Its companion commit
85767ac8fe added explicit
'option dhcpv4/dhcpv6 server' lines to the stock 'lan' section in the
packaged dhcp.conf template, which covers fresh installs.
Neither commit accounts for configs that predate the change. Before
it, an unset dhcpv4/dhcpv6 option was implicitly treated as enabled,
so it was common (and still is, on any router upgraded from before
this landed) to have 'config dhcp' sections for additional
interfaces/VLANs with no explicit dhcpv4/dhcpv6 option at all. After
the change, dnsmasq.init silently skips '--dhcp-range' for every one
of those sections:
if [ "$dhcpv4" != "disabled" ]; then
...
fi
The result: any interface whose dhcp section never needed the option
before stops handing out leases entirely, with nothing logged beyond
a normal dnsmasq startup, while sections that happen to already carry
an explicit 'server' value keep working. On a router with several
VLANs this looks exactly like "DHCP only works on one interface."
Fix by shipping a one-time /etc/uci-defaults migration, matching the
existing 50-dnsmasq-migrate-resolv-conf-auto.sh /
50-dnsmasq-migrate-ipset.sh pattern in this package: for every
'config dhcp' section, if dhcpv4/dhcpv6 is unset, explicitly set it
to 'server', preserving the pre-
6f30f08d0e behavior for existing
configs. Sections that already set the option (or set 'disabled'
deliberately) are left untouched, and sections that never reach the
check (e.g. 'wan' with 'option ignore 1') are unaffected.
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24068
Signed-off-by: Robert Marko <robimarko@gmail.com>
PKG_NAME:=dnsmasq
PKG_UPSTREAM_VERSION:=2.93
PKG_VERSION:=$(subst test,~~test,$(subst rc,~rc,$(PKG_UPSTREAM_VERSION)))
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE:=$(PKG_NAME)-$(PKG_UPSTREAM_VERSION).tar.xz
PKG_SOURCE_URL:=https://thekelleys.org.uk/dnsmasq/
$(INSTALL_DIR) $(1)/etc/uci-defaults
$(INSTALL_BIN) ./files/50-dnsmasq-migrate-resolv-conf-auto.sh $(1)/etc/uci-defaults
$(INSTALL_BIN) ./files/50-dnsmasq-migrate-ipset.sh $(1)/etc/uci-defaults
+ $(INSTALL_BIN) ./files/50-dnsmasq-migrate-dhcp-default.sh $(1)/etc/uci-defaults
endef
Package/dnsmasq-dhcpv6/install = $(Package/dnsmasq/install)
--- /dev/null
+#!/bin/sh
+# dnsmasq.init used to treat an unset 'dhcpv4'/'dhcpv6' option as
+# implicitly enabled. Since the fallback default was changed to
+# 'disabled' (to match odhcpd), any existing 'config dhcp' section
+# that never had to set these options explicitly silently stops
+# serving that protocol. Pin the old behavior for configs that
+# predate the change.
+
+. /lib/functions.sh
+
+migrate_dhcp() {
+ local cfg="$1"
+ local dhcpv4 dhcpv6
+
+ config_get dhcpv4 "$cfg" dhcpv4
+ config_get dhcpv6 "$cfg" dhcpv6
+
+ [ -n "$dhcpv4" ] || uci -q set dhcp."$cfg".dhcpv4='server'
+ [ -n "$dhcpv6" ] || uci -q set dhcp."$cfg".dhcpv6='server'
+}
+
+config_load dhcp
+config_foreach migrate_dhcp dhcp
+
+uci -q commit dhcp
+exit 0