From: Alexander Bluhm Subject: Re: ipv4 icmp_reflect() source address selection optimisation To: David Gwynne Cc: tech@openbsd.org Date: Fri, 23 Aug 2024 15:43:40 +0200 On Wed, Aug 21, 2024 at 03:40:23PM +1000, David Gwynne wrote: > On Fri, Aug 09, 2024 at 11:47:14AM +0200, Claudio Jeker wrote: > > On Fri, Aug 09, 2024 at 11:15:34AM +0200, Alexander Bluhm wrote: > > > On Fri, Aug 09, 2024 at 10:40:11AM +1000, David Gwynne wrote: > > > > tl;dr: i believe this change would let us simplify pf_route (the > > > > loopback ip handling specifically), so it's worth it. > > > > > > In contrast I have worked on all the corner cases in 15 years to > > > make it work. Maybe not the best solution, but it works. I fear > > > that at our customers somethig will break if we change behavior > > > just because we think it looks better. > > all of them? that's a bold claim. > > add this config the PF host in your test setup and then run the regress: > > # cat /etc/hostname.vport0 > inet 169.254.0.1 255.255.255.0 > up > # cat /etc/hostname.pfsync0 > syncif vport0 > maxupd 128 > defer > up My test does ping -n -c 1 10.188.88.24, which does not work. But with ping -n -c 3 10.188.88.24 I get: 3 packets transmitted, 2 packets received, 33.3% packet loss The first packet is always dropped. So pf-route with pfsync is not totally broken, just buggy. Maybe we can fix it. I am not against running pfsync with pf-route. Maybe we can find a less invasive fix for that specific problem. The non-working reject routes only for loopback interfaces is a different issue. This is the way 4.4BSD implemented the feature. In if_ether.c RTF_REJECT is used to mark invalid arp cache. And RTF_BLACKHOLE is used in if_loop.c exclusively. bluhm