On Tue, Jun 17, 2025 at 01:47:14PM +1000, David Gwynne wrote:
> On Mon, Jun 16, 2025 at 04:09:01PM +0200, Alexander Bluhm wrote:
> > On Mon, Jun 16, 2025 at 07:49:08AM -0600, Theo de Raadt wrote:
> > > >     the idea is the dhcp/bootp traffic for client should be covered by 'pass
> > > >    all' rule.  the semi-working diff is attached for reference.
> > > 
> > > I worry quite a lot about this proposal since it presumes people have
> > > written their pf.conf files according to a particular style.
> > > 
> > > Anyone using dhcpd and a hand-written pf.conf is have a pretty bad time
> > > with this, and I do not believe forwarn communication will change
> > > anything.
> > > 
> > > As a second point, I think the components of the solution are very
> > > complicated compared to the existing bpf approach.
> > 
> > I think dhcp client with UDP sockets needs too many changes in the
> > network stack.  Server dhcpd with UDP sockets may work as dlg@
> > shows.  In both cases I see no real benefit in switching.  The old
> > implementation works, especially with pf.
> 
> but it doesnt work.
> 
> i didn't write the diff because i (allegedly) hate bpf or because
> i was bored. i solved a problem at work that needs dhcpd to work
> more like the network stack, but we already have a working network
> stack.

I don't oppose this change in general, just weighting pros and cons.
New dhcpd would work with anycast, but it could break pf setups for
our users.  If the later can be solved, I don't object.

sashan's pf diff looks promising.  I would not mind to get that in
and fix remaining corner cases in tree.  As dhcp is simpler than
neigbour discovery, I guess that is feasible.

bluhm