From: Alexander Bluhm <bluhm@openbsd.org>
Subject: Re: pf_route simplification, or pf_route vs pfsync
To: Alexandr Nedvedicky <sashan@fastmail.net>
Cc: David Gwynne <david@gwynne.id.au>, tech@openbsd.org
Date: Sat, 13 Jul 2024 15:43:39 +0200

On Sat, Jul 13, 2024 at 02:54:50PM +0200, Alexandr Nedvedicky wrote:
> > if you could have a look at this updated diff i'd appreciate it.
> > if it still sucks i'll try setting up 4 machines.
> > 
> 
>     This change is OK @sashan, but please give bluhm@ a chance
>     to try out updated diff.

Previous failing tests were:

run-ping-mtu-1400-inet-RTT_OUT
run-traceroute-icmp-inet-RPT_IN
run-traceroute-udp-inet-RPT_IN

With new diff these subtests fail:

run-ping-inet-RT_IN
run-ping-mtu-1400-inet-RTT_OUT
run-traceroute-icmp-inet-RPT_IN
run-traceroute-udp-inet-RPT_IN

I really did spent a long time to get all the corner cases with TTL
and path MTU right.  Over years I added theses tests to
regress/sys/net/pf_forward to keep the features reliable.

I doubt that by just looking at code you can get it right.  When I
implemented it, I had a working test setup and traced each packet
to figure out what is going on.

Complete log is here
http://bluhm.genua.de/regress/results/2024-07-12T14%3A08%3A06Z/logs/sys/net/pf_forward/make.log

By the way, putting m_tag_get() in the packet path does not make
it fast.  It means a pool allocation for each packet.  I am working
in the other direction an try to remove them from the fast path.

bluhm