Date: Sat, 22 Apr 2000 21:11:45 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, luigi@freebsd.org Cc: freebsd-net@freebsd.org Subject: Proposal for ethernet, bridging, netgraph Message-ID: <200004230411.VAA17652@bubba.whistle.com>
next in thread | raw e-mail | index | archive | help
So, I've got a proposal :-) These are not all my ideas, but
here they are collected in one place..
The current situation with Ethernet drivers, Bridging, BPF, and
Netgraph is that it's all a bit klugey and gross. As evidence of
this, every single Ethernet driver (I've counted 45) must contain
the same duplicated code to handle both BPF and bridging..
The reason for this being that both of these require putting the
device in promiscuous mode, but ether_input() is only supposed to
get "real" packets, and so the driver must "shield" ether_input()
from seeing packets which it wouldn't normally see. However, BPF
and bridging must be "unshielded". The result is that each driver
has to contain logic to handle BPF and briding, because by the
time packets get to ether_input(), it's too late.
So, the first part of the proposal is:
1 Move the BPF and BRIDGE code out of all of the Ethernet drivers
and put it into ether_input()
2 Add a new parameter to ether_input() which a driver will set
to non-zero indicating ``IFF_PROMISC was set and this packet
came in, but it's not really supposed to be received so don't
send it up the networking stack.''
Secondly, the ng_ether netgraph node is not as elegant as it could be.
For example, it should be possible to do bridging using a "ng_bridge"
netgraph node.. but that's not possible right now.
Also, you have to compile your kernel with options NETGRAPH in order
to get netgraph node Ethernet support.. there's no ng_ether.ko KLD.
So, the next part of the proposal..
3 Move the netgraph part of if_ethersubr.c into a new file ng_ether.c
and make it so the Ethernet node type can be a KLD and still work.
4 Change the ng_ether node type to have these two hooks:
"device" -- connection down to the raw Ethernet device
"stack" -- connection to the Ethernet stack and upper stacks
5 Add netgraph control messages to get the associated interface name
and index, so that it's possible to set promiscuous mode, multicast
addresses, etc. by:
from the kernel - getting the interface structure (using
ifindex2ifnet[if_index]), and then calling ifioctl()
(small note: ifioctl() will be made to handle p == NULL)
from userland - using the normal ioctl() mechanism
6 Minor fix to ppp(8), etc. to handle different ng_ether hook names
Re #4: When neither hook is connected, they are effectively connected
together -- i.e., the interface functions normally. Otherwise, you
get the obvious data connection, allowing both sending and recieving
raw frames to the device, but also input/output from the Ethernet
stack associated with the interface. Filtering Ethernet frames based
on interface would be easy .. etherfw(8) anyone? :-)
Finally..
6 Convert BRIDGE into a netgraph node. This would make it more
powerful because you could do bridging on any arbitrary subset
of interfaces.
7 (Optional) Remove existing BRIDGE support in favor of netgraph version
Only if people want to for simplicity.
What do people think?
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004230411.VAA17652>