Subject: Re: Take #3 - final proposed patch for ipsec/bpf/ipfilter integration
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 05/14/2003 12:13:46
> > 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
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.