Date: Wed, 23 Aug 2000 20:24:51 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: freebsd-net@freebsd.org Subject: Re: bridging and freebsd crash Message-ID: <200008231824.UAA29351@info.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
> The bridging+ipfw code in 3.x did work -- but it was very messy. > Each individual driver had to have an ugly hack. The ipfw code > was doing filtering for non-IP packets, etc., etc. Recall that > my changes removed 1,016 lines of redundant code! In my opinion > that alone is a clear indication that more design and less hacking > is sorely needed. > > In my opinion (you may disagree), these changes were worthwhile I fully agree(d) on the changes to ethernet drivers - they were deeply needed. On ipfw (and bridge+ipfw interactions), opinions may differ, and i do not really think it is a technical matter. I am not a big fan of layering when it makes things more complex than they should be (and i am thinking of a firewall configuration -- i prefer to have all things in one place, rather than have to configure an etherfw, an ipfw and maybe an upper layer firewall. If you don't like the "ipfw" name change it!). And below, when you say that the interaction between bridging+ipfw was ill-conceived, can you explain where ? > In my opinion (again you may disagree), the right answer is: > > 1. Finish the cleanup of the bridging code by moving it into its > own netgraph node. This will eliminate any code paths that result > in unvalidated packets (which seems to be the current problem). but... if you cannot test things, who is going to do it ? I think the problem is not only with unvalidated packets reaching ipfw, it is also with mbufs shared between a device driver (which might pass it to a DMA engine) and the upper layers (where the code might do some NTOH*() on the same buffer, resulting in data corruption for the net -- this is the breakage for multicast packets i was referring to. I do not think moving to netgraph is going to help, you have to know that the problem is there and apply countermeasures. > happen using netgraph. The reason this is happening now is because > of the current, ill-conceived bridging+ipfw interaction. Actually passing bridged packets to ipfw with all proper tests took a handful of lines of code and did work. Yes, the commit i did also had some dead code trying to match ethernet packets -- that one had to be either removed or fixed, but that's it. I don't think the interaction was ill-conceived :) > I'm willing to work with anyone interested in this project -- or some which brings things back to square one... no volunteers aroung :( cheers luigi > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > ----- End of forwarded message from Luigi Rizzo ----- 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?200008231824.UAA29351>