> > > > It is not just for ipf, but that is one of the two beneficaries.
> > > > The other is BPF (tcpdump.)
> > > 
> > > tcpdump can decode ESP by itsself and i think it should if needed.
> > > it already has -E option.  it's a bit limited currently, though.
> 
> > And it only fixes the problem for tcpdump and not all
> > applications that want to use BPF to look at unecrypted
> > traffic - which I think is an unnecessary burden.
> 
> if bpf interface isn't insufficient,
> why not improve/hack it to be able to have multiple tap points

Because bpf has a different role to pfil and I think your patch
is wrong for joining the two together but that's just my opinion.

BPF is primarily aimed at providing copies of "raw packet data"
from data received by a network device (in this case the result
of decrypting packets) or copies of what's about to be sent via
one.

pfil is generally concered with providing the means for controlling
packets being accepted as part of a protocol's processing.

> like attached (incomplete) patch or invent a new packet tapping interface?

A net packet tapping interface...hmmm. like netgraph in FreeBSD that
almost nothing presently uses ?

> > Yes, you need to be able to distinguish how the rules are applied.
> 
> because ipfilter must knows which pfil_head it added hooks in,
> i think that it can distinguish them, of course.

Actually, ipfilter has no clue about which pfil_head it is being
called from.  This may need to change or maybe not.

Now, even if ipfilter knew which pfil_head it was being called from,
that needs to be reflected back in a rule, somehow.

Can you spend some more time working on your idea and post the patch?

I'm also concerned that this patch creates an interdependency between
what are two otherwise completely separate subsystems.  Currently it
is possible to use BPF without PFIL_HOOKS and vice versa.  I see this
as being a mandatory requirement.

Darren