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

Reply via email to