In some mail from YAMAMOTO Takashi, sie said:
> 
> > 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.
> 
> while i don't want strongly to join them,
> i don't see any big reason to keep them separate.
> tapping packets is a kind of filtering
> and single hook for them is fine, IMO.

It's quite different, in a number of ways, from my perspective.

Most importantly, there is an order dependancy - you always want the
tapping to precede the filtering.  Well, almost always, I can see how
some might like it the other way too.

> > > > 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.
> 
> yes.  i don't care about syntax of ipf rule sets.

Right, well given that this is "half the problem", you need to
care about it.

If I was in a position to say so, I'd say this patch is broken
until you have solved the problem for both tcpdump and ipfilter.

> > Can you spend some more time working on your idea and post the patch?
> 
> "tcpdump -i esp@wi0" worked with attached patch.

While I like the "foo@ifname", is separating esp & ah the right
way to go ?  Would it not be better to just have "ipsec@wi0" ?

> it's still very incomplete (ipv4, esp, tranport mode only, no ipf patch)
> but i think it's enough for testing a method.

I found transport mode to always supply bad checksums, according to
tcpdump, so you might get more satisfaction from testing tunnel mode.

On top of that, I'd like to see a complete solution so it can be
fully and properly be evaluated rather than trying to decide if
something is good or not based on an incomplete and perhaps
substantially different solution compared to the final one.

> > 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.
> 
> why mandatory?  i even think that bpf_mtap can be a wrapper of pfil hook.

Because using BPF on these things should not be dependant on having
"options PFIL_HOOKS" in the kernel config, only "pseudo-device bpf 8"
and likewise, using ipfilter should not need bpf, only PFIL_HOOKS.

Well at least that is the way it has always been, until now, and I don't
see why it should be changed now unless it is absolutely necessary (and
so far I'm yet to be convinced it is.)  If one or the other of these two
became a mandatory kernel part of the kernel (no longer an option) then
I could see the sense in using one to support the other.

Darren