Date: Sun, 23 Apr 2000 00:25:31 -0700 From: Julian Elischer <julian@elischer.org> To: Archie Cobbs <archie@whistle.com> Cc: pavel@alum.mit.edu, nsayer@sftw.com, luigi@freebsd.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <3902A56B.167EB0E7@elischer.org> References: <200004230411.VAA17652@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs wrote: > [...] > > 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.. With or without netgraph, this has called for cleaning up for a while. > > 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() sure > > 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.'' Theoretically this is not needed. We already have the address of the ifnet structure and thus the arpcom, so we have the flags, AND the local ethernet address, so we can just do the same test that is presently done in the drivers. We have all the the info we need. > > 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. No, because I wanted to put the ng_ether code into the generic ehter code and to make it as unintrusive as possible so that no-one could complain that it was slowing down the mainline. As has been noted the generic code doesn't get packets not destined to this machine. (maybe a separate hook to catch these?). Also I didn't add a way to give these packes back to the system if netgraph didn't need them. This is the second place where a "give it back" facility would be useful. and so I have decided that I will put forward a proposal to allow 'Packet return' facility in netgraph.. Basically this will allow netgraph to have 'processing 'stubs' where you hand a packet to a hook and it may come back to you modified in some way. (or duplicated or whatever). I can see a lot of uses for this and it's actually a very small change to the protocol. It's also backwards compatible. > > 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. Tricky, but the main reason i didn't do this in the forst place is that I wanted the netgraph code in if_ethersubr.c to be COMPLETELY removable if option NETGRAPH were not used so that the traditionalists wouldn't be able to complain that I was slowing up the critical path. > > 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 This is a fair idea, though I'd like to add the 'stub' option as well. (to save on kernel stack and processing time). > > 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 The ifindex is a hack that should go away (in my opinion). > > 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? :-) Sure. > > 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 > Personally I like it and it's teh kind of thing that I wrote teh original netgraph design to handle. I really do think that a pass-back facility would round out the protocol, but that's a different issue I will discuss separately. Julian > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v 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?3902A56B.167EB0E7>