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.
> 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?
> 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.
