I tested the pf idea on two OpenBSD 7.9 VMs (GENERIC.MP#449) running stock base dhcpd. Again the traffic traverses fine but gets stuck in Recv-Q. Notably, this does not occur if the interface name is provided instead of the IP address, "-y vio1" vs "-y 192.0.2.1". According to the man page, either should be supported. It does mention that providing an IP operates as unicast while providing the interface operates as multicast, so maybe it's related to that?
Not sure if a dump of dmesg is relevant here, but happy to provide any additional information on request. On Thu, Oct 29, 2026 at 7:31 PM Bryan Vyhmeister <[email protected]> wrote: > > On Thu, Oct 29, 2026 at 02:49:54PM -0400, John Clendenen wrote: > > During some testing, I found what I believe is a defect in dhcpd sync. > > Apologies if I am mistaken here, but if the fault is on my end, I'm > > not seeing it. > > > > Details below: > > > > Synopsis: sync peers never exchange leases with -y <address> > > Category: user > > System: OpenBSD 8.0 (also reproduced on 7.9 and -current) > > Architecture: amd64 > > > > Description: > > I run two dhcpd servers as a failover pair with lease synchronisation: > > > > dhcpd -y 192.0.2.1 -Y 192.0.2.2 em1 > > dhcpd -y 192.0.2.2 -Y 192.0.2.1 em1 > > > > The two servers never synchronise leases. Each /var/db/dhcpd.leases > > holds only the leases that server granted itself. Nothing is logged. > > If one server goes down, the survivor knows nothing about the other's > > leases. The sync packets do reach the host: `netstat -an -p udp` shows > > them building up in the Recv-Q of the *:8067 socket, but the queue > > never drains. > > There is not enough information to see what the issue might be. My guess > is that your pf.conf(5) is not allowing this traffic. I would start with > something like: > > pass quick from 192.0.2.1 to 192.0.2.2 > pass quick from 192.0.2.2 to 192.0.2.1 > > Then, if this is the issue, tighten up the rules. When I have had this > same issue, it has always been my pf(4) rules. > > Bryan
