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

introducing some kind of priority of filter is enough?
maybe we need it anyway when we have more pfil users besides ipf.

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

what's needed to be added to rules is optional 'filter point' and
it's trivial.
maybe it can be specified as part of interface name as your patch did.
do you concern about ipf implementation detail?
i'm sure that you're far good at ipf than i am. :-)

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

both are not perfect.
maybe it depends on the one's personal preference...
or should we take more flexible way?

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

i'm not sure if we should care about checksums for tapped packets.
even currently it can be wrong when eg. offloaded to hardware.

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

hmm..

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

i personally have no problem if bpf depends on pfil.
i agree that pfil and ipf shouldn't need bpf.

YAMAMOTO Takashi