Hello, On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote: > On Mon, Jan 25, 2021 at 04:19:11PM +0100, Alexander Bluhm wrote: > > On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote: > > > --- sys/conf/GENERIC 30 Sep 2020 14:51:17 -0000 1.273 > > > +++ sys/conf/GENERIC 22 Jan 2021 07:33:30 -0000 > > > @@ -82,6 +82,7 @@ pseudo-device msts 1 # MSTS line discipl > > > pseudo-device endrun 1 # EndRun line discipline > > > pseudo-device vnd 4 # vnode disk devices > > > pseudo-device ksyms 1 # kernel symbols device > > > +pseudo-device kstat > > > #pseudo-device dt # Dynamic Tracer > > > > > > # clonable devices > > > > This is an unrelated chunk. > > oh yeah... > > > > +pf_route(struct pf_pdesc *pd, struct pf_state *s) > > ... > > > + if (pd->dir == PF_IN) { > > > if (pf_test(AF_INET, PF_OUT, ifp, &m0) != PF_PASS) > > > > Yes, this is the correct logic. When the packet comes in, pf > > overrides forwarding, tests the out rules, and sends it. For > > outgoing packets on out route-to rules we have already tested the > > rules. It also works for reply-to the other way around. > > yep.
I'm suggesting to keep current if () in. and change it with follow up commit, which will adjust match rule for route-to/reply-to. would it be OK with you, David? > > > But what about dup-to? The packet is duplicated for both directions. > > I guess the main use case for dup-to is implementing a monitor port. > > There you have to pass packets stateless, otherwise it would not > > work anyway. The strange semantics is not related to this diff. > > are you saying i should skip pf_test for all dup-to generated packets? this makes perfect sense for me. > > > We are reaching a state where this diff can go in. I just startet > > a regress run with it. OK bluhm@ > > hopefully i fixed the pfctl error messages up so the regress tests arent > too unhappy. thanks and regards sashan