From owner-freebsd-net Sat Apr 22 21:13:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 2480637B7D5; Sat, 22 Apr 2000 21:13:28 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id VAA17652; Sat, 22 Apr 2000 21:11:45 -0700 (PDT) From: Archie Cobbs Message-Id: <200004230411.VAA17652@bubba.whistle.com> Subject: Proposal for ethernet, bridging, netgraph To: pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, luigi@freebsd.org Date: Sat, 22 Apr 2000 21:11:45 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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