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