On Fri, 9 Jun 2000, Andi Kleen wrote:
> > > Netfilter is not an IP only thing. It is a generic framework for
> > > packet mangling. Although currently only IPv4 and IPv6 netfilter
> > > implementations exist it would be no big problem to add ``raw
> > > ethernet'' netfilter hooks.
> >
> > Raw ethernet netfilter hooks, as are IPX netfilter hooks by the way, are
> > currently a nice blue cloud in the sky.
>
> They are not hard to add. Just so far nobody needed them. You could
> either hook them into the device's hard_start_xmit function or as an
> netfilter qdisc for the devices with queue (both requires no
> additional instructions in the fast path when not used)
I know, but my point was that our approach currently works. Saying things
like 'Well, of course it could be done in this specific way' while
required functionality does not even exist is nothing more than a
handwave.
> > As we're getting into the architectural purity business anyway, does it
> > make a whole lot of sense to netfilter on two different protocol levels?
>
> I think it does. netfilter is not a single entinity, it is a hook
> infrastructure. When multi layer filtering is required it can be
> integrated.
So one packet can end up being filtered multiple times, if I get this
correctly. But where do we draw the line, then?
For example, the IP portion of netfilter currently has the capability to
filter on source MAC address as well as the capability to filter on things
like TCP ports. That's a layering violation in both directions, and
although it does not hurt, it's not particularly pretty.
What if we want to let all traffic coming from IPX network 0xdeadbeef use
VLAN 2? Should we either add 'IPX protocol extension module'-type of
uglyness to the raw ethernet netfilter hooks or write a complete IPX
netfilter layer just to be able to accomplish that?
> I haven't thought hard enough about the VLAN problem to decide if it
> really makes sense to implement it as netfilter module. The net_fifo
> idea seems to have some merits too (struct net_device probably does
> too many things at once currently and some hash tables/trees for
> device management probably couldn't hurt)
Agreed, struct net_device is a fscking mess.
greetings,
Lennert
|