DHCP lease renewal needlessly disrupts VPN

brentr · November 10, 2024, 7:43pm

My ISP (Comcast in California) recently reduced the duration of its DHCP leases. OpenWRT seems to treat any lease renewal as a complete update. The dhcp.script calls setup_interface() even if the renewal merely extends the existing lease.
setup_interface(), understandably, disrupts any services running on the effected interface. In my case, a Wireguard would go offline for a minute or so ever 30 minutes.

Why doesn't OpenWRT recognize when the DHCP lease renewal is merely extending the established lease?
In this case, the interface should not be disturbed.

Here's a "proof of concept" patch on /lib/netifd/dhcp.script that implements this. It doesn't cover some complex corner cases, but it gets the job done in mine...
(patched against OpenWrt 23.05.2)

--- original/dhcp.script	2024-10-26 20:34:09.000000000 -0700
+++ ./dhcp.script	2024-10-26 22:21:23.000000000 -0700
@@ -102,12 +102,26 @@
 	proto_send_update "$INTERFACE"
 }
 
+leased=/var/run/$interface.lease
+
 case "$1" in
 	deconfig)
+		rm -f $leased
 		deconfig_interface
 	;;
 	renew|bound)
+		leaseSpec="$ip M:$subnet G:$router"
+		[ "$broadcast" ] && leaseSpec="$leaseSpec B:$broadcast"
+		[ "$mtu" ] && leaseSpec="$leaseSpec U:$mtu"
+		false && {  #only if using dhcp server's recommended dns
+			leaseSpec="$leaseSpec$'\n'$domain DNS:$dns"
+		}
+		[ "$1" = "renew" -a "`cat $leased 2>/dev/null`" = "$leaseSpec" ] && {
+			logger -p daemon.notice -t `basename $0` "$interface extended lease on $ip"
+			exit 0
+		}
 		setup_interface
+		echo "$leaseSpec" >$leased
 	;;
 esac

How have others dealt with the issue of short DHCP leases disrupting VPNs and the like?

brada4 · November 10, 2024, 8:01pm

opkg search /lib/netifd/dhcp.script

And either post a pull request or outline the p4oblem and envisioned solution in bug tracker.
You can use snapshot in x86/64 vm to poc/test.

Does it log anything besides new lease like up/down?
Is it giving you public ip or 192.168.100.?

systemcrash · November 10, 2024, 10:04pm

comcast sigh

Well, as a datapoint, my device is not affected by this. But I have static IPs, and Ipv4+6 (even though they're assigned via DHCP)

I just see udhcpc getting updates in the logs. No noticeable blips.

brentr · November 11, 2024, 2:02am

@systemcrash Are you hosting a wireguard or other VPN service from your router?

@brada4 I'm getting a public IP address from Comcast via DHCP. The router is routinely processing connections from the internet.

brada4 · November 11, 2024, 2:25am

Show the log entries. Dhcp renew does not reset interfaces

brentr · November 11, 2024, 3:12am

@brada4 I reverted my dhcp.script patch. Here's the resulting log of activity following a DHCP renew. The interface in question is called MBARIwg (mbari wireguard)

Sun Nov 10 18:42:39 2024 daemon.notice netifd: wan (4197): udhcpc: sending renew to server 96.113.129.73
Sun Nov 10 18:42:39 2024 daemon.notice netifd: wan (4197): udhcpc: lease of 107.3.xxx.yyy obtained from 96.113.129.73, lease time 7200
Sun Nov 10 18:42:39 2024 user.notice firewall: Reloading firewall due to ifupdate of wan (wan)
Sun Nov 10 18:42:59 2024 user.info banIP-0.9.3-5[11771]: start banIP processing (reload)
Sun Nov 10 18:43:00 2024 user.info banIP-0.9.3-5[11771]: start banIP download processes
Sun Nov 10 18:43:05 2024 user.info banIP-0.9.3-5[11771]: start banIP domain lookup
Sun Nov 10 18:43:05 2024 user.info banIP-0.9.3-5[11771]: start detached banIP log service (/sbin/logread)
Sun Nov 10 18:44:10 2024 daemon.notice netifd: Network device 'MBARIwg' link is down
Sun Nov 10 18:44:10 2024 daemon.info dnsmasq[1]: exiting on receipt of SIGTERM
Sun Nov 10 18:44:10 2024 daemon.notice netifd: Interface 'MBARIwg' is now down
Sun Nov 10 18:44:10 2024 daemon.notice netifd: Interface 'MBARIwg' is setting up now
Sun Nov 10 18:44:10 2024 daemon.notice netifd: Interface 'MBARIwg' is now up
Sun Nov 10 18:44:10 2024 daemon.notice netifd: Network device 'MBARIwg' link is up
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: started, version 2.89 cachesize 150
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq-dhcp[1]: DHCP, IP range 192.168.6.150 -- 192.168.6.189, lease time 12h
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq-tftp[1]: TFTP root is /tftp
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using nameserver 8.8.4.4#53
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using nameserver 8.8.8.8#53
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 48 names
Sun Nov 10 18:44:11 2024 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Sun Nov 10 18:44:11 2024 user.notice firewall: Reloading firewall due to ifup of MBARIwg (MBARIwg)
Sun Nov 10 18:44:12 2024 daemon.info dnsmasq[1]: exiting on receipt of SIGTERM
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: started, version 2.89 cachesize 150
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq-dhcp[1]: DHCP, IP range 192.168.6.150 -- 192.168.6.189, lease time 12h
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq-tftp[1]: TFTP root is /tftp
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.10.10#53 for domain mbari.org
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.12.87#53 for domain mbari.org
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.10.10#53 for domain 89.134.in-addr.arpa
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.12.87#53 for domain 89.134.in-addr.arpa
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.10.10#53 for domain mbari.org
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.12.87#53 for domain mbari.org
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.10.10#53 for domain 89.134.in-addr.arpa
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 134.89.12.87#53 for domain 89.134.in-addr.arpa
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 8.8.4.4#53
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using nameserver 8.8.8.8#53
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: read /tmp/hosts/MBARIwg - 2 names
Sun Nov 10 18:44:13 2024 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 48 names

brada4 · November 11, 2024, 6:57am

But that comes 1m30 later?

brentr · November 11, 2024, 8:19am

I think I figured out what's causing my Wireguard interface to restart...
My ISP may change this machine's IP on a renewal, but it rarely does.
So, in a custom hotplug script: /etc/hotplug.d/iface/98-MBARIwg
the MBARIwg VPN is restarted on any $ACTION on the wan interface to update the routing for the (rare) case the IP address from the ISP really did change.

However, this ifup $ACTION is triggered by setup_interface() in the standard dhcp.script,
even if the IP address did not change.

I suppose I could move the lease paramter change detection logic to my custom 98-MBARIwg script, but, it would be more difficult to detect there and would still send useless ifup $ACTIONs to all the other hotplug scripts.

So, why should a lease renewal, with no network changes, still cause setup_interface() to be called?

brada4 · November 11, 2024, 12:23pm

Dont you think same would apply to everybody? VPN does not go down if DHCP refreshes. Wireguard even freely roams maintaining connections open.

dave14305 · November 11, 2024, 12:48pm

Depending what’s inside your hotplug script, you can adapt it similar to the firewall script.

github.com

openwrt/firewall4/blob/master/root/etc/hotplug.d/iface/20-firewall

#!/bin/sh

has_zone() {
	fw4 -q network "$INTERFACE" >/dev/null && return 0
	eval $(ubus call "network.interface.$INTERFACE" status | jsonfilter -e 'ZONE=@.data.zone')
	fw4 -q zone "$ZONE" >/dev/null
}

[ "$ACTION" = ifup -o "$ACTION" = ifupdate ] || exit 0
[ "$ACTION" = ifupdate -a -z "$IFUPDATE_ADDRESSES" -a -z "$IFUPDATE_DATA" ] && exit 0

/etc/init.d/firewall enabled || exit 0

has_zone || exit 0

logger -t firewall "Reloading firewall due to $ACTION of $INTERFACE ($DEVICE)"
fw4 -q reload

Personally, I modify the firewall script to ignore the DATA update, since it is usually only the leasetime that can change with Comcast (I’ve seen it alternate between 7200 and 3600 secs during maintenance).

brentr · November 12, 2024, 1:09am

@brada4 Wireguard cannot determine that its partner's IP has changed until that partner contacts it with the new one. That's a problem if the machine is a server, awaiting incoming connections.

This is why my iface hotplug script cycles the VPN interface when the wan interface changes. But, the iface "ifupdate" event often is triggered by a lease renewal that updates nothing, so, each renewal ends up causing the VPN interface to cycle

Part of the problem seems to be that cycling the Wireguard interface in the hotplug script causes the next DHCP renewal to generate an ifupdate event, etc. If I remove the

ifup wireguard

from the hotplug script, subsequent DHCP renewals DO NOT trigger the ifupdate on the wan interface.

Thoughts?

brentr · November 12, 2024, 1:12am

@dave14305 Thanks for this pointer. That looks helpful.
Do you know where these environment variables

IFUPDATE_ADDRESSES
and
IFUPDATE_DATA

are assigned?
Any docs on this?

dave14305 · November 12, 2024, 1:33am

They are set by netifd.

github.com

openwrt/netifd/blob/34eb11eb6f5c62de480d6192f0ca840093127fee/interface-event.c#L68-L77


      
          	if (event == IFEV_UPDATE) {
          		if (updated & IUF_ADDRESS)
          			setenv("IFUPDATE_ADDRESSES", "1", 1);
          		if (updated & IUF_ROUTE)
          			setenv("IFUPDATE_ROUTES", "1", 1);
          		if (updated & IUF_PREFIX)
          			setenv("IFUPDATE_PREFIXES", "1", 1);
          		if (updated & IUF_DATA)
          			setenv("IFUPDATE_DATA", "1", 1);
          	}

See the hotplug wiki page.
https://openwrt.org/docs/guide-user/base-system/hotplug?s[]=ifupdate#iface

brentr · November 12, 2024, 5:02am

Thanks, again. The code helped me to understand.
The ifupdate action will be called with the corresponding env var flag set if that item has changed. Still not clear on what IFUPDATE_DATA is about. I guess one can associate a blob of some sort with each interface?
Anyway, this is solved as far as I'm concerned.

dave14305 · November 12, 2024, 10:49am

If you run ifstatus wan you should see the data section that most likely contains the leasetime and dhcp server IP. If those items change between renewals, the hotplug event will fire.

system · November 22, 2024, 10:50am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.