In some mail from YAMAMOTO Takashi, sie said:
> 
> > > 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.

Yes, that might be the way.  Currently it is insert order dependant,
which is good in some ways but means you cannot position between things
(this may or may not be a bad idea.)

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

I'm sure I am, but I would like to see you flesh it out completely as
it is your idea and I think it is better for you to show us how you
think it would work rather than me try and read your mind to do it.

Besides, it will not hurt you to try and work with the ipfilter code :)
Afterall, I've already had to dig through KAME IPSec code to get my
patch to work :)

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

Well, maybe we should try asking ourselves what users will want/expect.

Is someone going to expect to intercept esp/ah traffic separately ?
Is this important ?  Consider that if it's just "ipsec" then there
is no way to find out later if it was AH'd or ESP'd (currently.)

If people want both AH & ESP traffic, should they have to run tcpdump
twice or just once ?

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

It's mainly for inbound packets that I have concerns for.  I would like
to be able to check packet checksums in ipfilter as part of the decision
tree for determining if a packet is good or bad.

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

Ok.  I'd like to hear from some of ther others (matt, jason!) who are
reading this, I hope, list about what they think about this idea.

Darren