Thanks for the detailed explanations. It turns out my issue was elsewhere, a misunderstanding about VLAN setup on my side. Seeing no UDP socket for dhcpd initially misled me, but this thread helped me revisit how the network stack layers work and understand dhcpd’s design in OpenBSD much more deeply. Appreciate the clarity and historical context.
Le jeu. 6 nov. 2025, 01:58, David Gwynne <[email protected]> a écrit : > hmm. > > it's not clear to me if the problem here is that "dhcpd is not working", > or if "dhcpd doesn't appear to be working the way i think it works". > > i'm going to assume it's the latter for now. > > for historical reasons, dhcpd does not use the ip stack to send and > receive dhcp packets, so it does not create and use a udp socket. > instead it has it's own tiny ip stack inside itself, and it relies on > BPF to steal the DHCP packets off the wire and inject it's replies onto > the wire. > > that's why you see fd 4 is the bpf0 character device special, but no udp > socket. this is also why dhcpd does not require pf rules allowing dhcp > packets to enter the stack, because bpf runs before the ip stack and is > not subject to policy in pf. > > the icmp socket you see is used by dhcpd to try and check if an ip has > something camping on it by pinging it, before handing that ip out to a > host requesting an ip. > > if you want to go deeper down the rabbit hole, there's a diff on tech@ > that shows you dhcpd can use udp sockets instead of bpf. the subject > line is "use UDP sockets instead of BPF", and you should be able to find > it in an archive like marc.info. > > On Tue, Nov 04, 2025 at 10:02:30AM +0100, Kevin Berkane wrote: > > Using kdump, I see: > > > > text > > CALL pledge(0xb364f3d58bf,0) > > STRU promise="stdio inet sendfd" > > RET pledge 0 > > > > I noticed dhcpd pledges without bpf. According to the pledge(2) man > > page, bpf allows ioctl operations on bpf(4) devices. Could the missing > > bpf promise be the origin of the problem? Should pledge include bpf > > for dhcpd to work in non-global rdomains? I'm still an enthusiast > > tinkerer with OpenBSD, so I might be misunderstanding something. > > > > > > Le mar. 4 nov. 2025 ?? 07:50, Kevin Berkane <[email protected]> a > ??crit : > > > > > > Thanks. I did double-check all commands ran in the right rdomain : > > > atlas$ doas route -T 0 exec netstat -an | grep -E '\.67|\.68' > > > udp 0 0 192.168.1.187.68 *.* > > > atlas$ doas route -T 0 exec fstat | grep dhcpd > > > _dhcp dhcpd 43427 text /usr 1373788 -r-xr-xr-x r 148704 > > > _dhcp dhcpd 43427 wd /var 2669760 drwxr-xr-x r 512 > > > _dhcp dhcpd 43427 root /var 2669760 drwxr-xr-x r 512 > > > _dhcp dhcpd 43427 0 / 78999 crw-rw-rw- rw null > > > _dhcp dhcpd 43427 1 / 78999 crw-rw-rw- rw null > > > _dhcp dhcpd 43427 2 / 78999 crw-rw-rw- rw null > > > _dhcp dhcpd 43427 3 /var 4432453 -rw-r--r-- w 0 > > > _dhcp dhcpd 43427 4 clone 78589 crw-rw---- rw bpf0 > > > _dhcp dhcpd 43427 5* internet raw icmp 0xfffffd83ecef0528 rtable 20 > > > atlas$ > > > atlas$ doas route -T 20 exec netstat -an | grep -E '\.67|\.68' > > > atlas$ doas route -T 20 exec fstat | grep dhcpd > > > _dhcp dhcpd 43427 text /usr 1373788 -r-xr-xr-x r 148704 > > > _dhcp dhcpd 43427 wd /var 2669760 drwxr-xr-x r 512 > > > _dhcp dhcpd 43427 root /var 2669760 drwxr-xr-x r 512 > > > _dhcp dhcpd 43427 0 / 78999 crw-rw-rw- rw null > > > _dhcp dhcpd 43427 1 / 78999 crw-rw-rw- rw null > > > _dhcp dhcpd 43427 2 / 78999 crw-rw-rw- rw null > > > _dhcp dhcpd 43427 3 /var 4432453 -rw-r--r-- w 0 > > > _dhcp dhcpd 43427 4 clone 78589 crw-rw---- rw bpf0 > > > _dhcp dhcpd 43427 5* internet raw icmp 0xfffffd83ecef0528 rtable 20 > > > atlas$ > > > > > > > > > Le mar. 4 nov. 2025 ?? 07:17, Janne Johansson <[email protected]> a > ??crit : > > >> > > >> > Observed behavior: > > >> > - dhcpd starts without errors, shows "Listening on vlan20 > (10.13.20.1)" > > >> > - dhcpd runs as _dhcp in rdomain 20 (checked with ps aux -o rtable) > > >> > - netstat -an does not show a socket listening on port 67 > > >> > > >> Don't know if it was a deliberate omission, but running "netstat -an" > > >> with "route exec -T 20" sounds appropriate here. > > >> > > >> > - When I check with fstat (`doas route -T 20 exec fstat | grep > dhcpd`), I see: > > >> > _dhcp dhcpd 43427 5* internet raw icmp 0xfffffd83ecef0528 rtable 20 > > >> > > >> like you did here.. > > >> > > >> -- > > >> May the most significant bit of your life be positive. > > >
