Hi Joan
From: Joan Lledó <[email protected]> To: "Roy Marples"<[email protected]>, "martin-ericracine"<[email protected]> Cc: <[email protected]> Date: Tue, 19 May 2026 22:10:45 +0100 Subject: Re: Fwd: [PATCH 1/6] New libpcap BPF backend > Hi Roy, > > I'm adding the Hurd mailing list to CC. I'm not subbed to the list, so please CC me on any relevant replies. Thanks in advance! > > El 19/5/26 a les 14:21, Roy Marples ha escrit: > > Hi > > > > Thanks for the patch, I've merged it here: > > https://github.com/NetworkConfiguration/dhcpcd/ > > commit/6ae07424aff786e0feb83f4f008725716bd7c5ce <https://github.com/ > > NetworkConfiguration/dhcpcd/commit/6ae07424aff786e0feb83f4f008725716bd7c5ce> > > > > > > I didn't open a PR for the patches because I'm still not 100% sure these > are going to be the final patches, since I'm still waiting for this PR > to be merged by libpcap maintainers: > > https://github.com/the-tcpdump-group/libpcap/pull/1565 > > But thanks anyway, I don't think I'll need to change any of the patches, > but who knows. > > > This actually triggered a fair bit of work, splitting out the BSD and > > DLPI specifics new files. > > I also optimised the pcap code a little with the final result here: > > https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/bpf- > > pcap.c <https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/ > > bpf-pcap.c> > > > > As part of this, I did actually patch libpcap to support BSD write > > filter and lock mechanisms but it seems upstream is resistant to this > > change because it's BSD only even though it provides a mechanism to > > harden the use of libpcap in a public facing application. > > https://github.com/the-tcpdump-group/libpcap/pull/1683 <https:// > > github.com/the-tcpdump-group/libpcap/pull/1683> > > > > So, my question is how hard would it be to add BPF write filtering and > > filter locking to GNU/Hurd? > > Maybe others in the Hurd list answer this, they can probably answer > better than me. > > The first idea that comes to my mind is to actually create the BPF > translator for the hurd, installed at /dev/bpf, following the BSD > interface. That way we could implement such operations via RPCs or via > ioctls. That way, both libpcap and dhcpcd could use their existing BSD > backends for the hurd. > > But we don't have such translator as for today, so, unless gnumach > supports such features, I don't know how can we implement > pcap_setwritefilter() and pcap_lockfilter() on libpcap for the hurd. > No problem. My idea was just that if any other OS supported BSD write filtering for BPF then they would be more open to merge it. > > > Hopefully the rest of the patches won't be so onerous! > > > > Please take into account the Patch 5 about the `./configure` has some AI > generated code, since I don't really know much about shell scripting. > It's not a problem, I can see what it's doing well enough. My main concern is for patch #3. Why does Hurd provide a #define for BSD - it's clearly not a BSD and I see this as a bug that should be resolved outside of dhcpcd. I still don't have a Hurd VM yet - it doesn't work at all on my Macbook Neo via QEMU (emulating x86_64) and while I do get some progress on my NetBSD host it can't find any disks to install to. Likely Hurd lacks virtio foo and I need to update my qemu start script to accomodate. Someone also recommended using i386 rather than x86_64. I'm loath to commit patches I can't test as well so it's probably a good time to chat before doing anything else :) Thanks Roy
