> > i can't understand why you want to introduce such a 'virtual interface' hack.
> > what you need for ipf is just additional filtering points(pfil_head), isn't
> > it?
> 
> 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.

> There are a couple of problems with just adding more filtering points
> with pfil.  The first is that for input traffic, the packets are processed
> twice by the same code, already, so it wouldn't be an extra pfil callout
> but rather some mechanism to do it with.  The second major problem is you
> now have to invent a way to do filteirng on those packets in a
> distinguishable manner.  By creating a virtual interface, this is
> achieved without needing any changes to ipfilter or anything else
> that wants to get these packets - they are simply associated with
> a different interface.

> > adding more protocol-specific member into struct ifnet seems a bad idea.
> 
> Well, I'll ask you the same question I asked Itojun - do you have a better
> solution to "this problem" ?  I'm willing to listen to ideas others have
> but so far, after much frustration to many people, there would appear to
> have been no better idea ?  Consider that there are two targets here that
> we want to fix the problem for - tcpdump et al & ipfilter.  Solving the
> problem for ipfilter with fancy pfil stuff is not going to work for
> tcpdump.

i don't think that ipfilter and tcpdump should use the same mechanism
to solve this "problem".

i think that additional pfil filtering points, e.g. inet_decoded_pfil_hook,
is enough for ipfilter.  am i missing something?

see above for tcpdump.

YAMAMOTO Takashi