Date: Wed, 23 Aug 2000 12:10:38 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: Archie Cobbs <archie@whistle.com>, Robert Watson <rwatson@FreeBSD.ORG>, Tomas Hodan <tomas@hodan.sk>, freebsd-net@FreeBSD.ORG Subject: Re: bridging and freebsd crash Message-ID: <200008231910.MAA85466@bubba.whistle.com> In-Reply-To: <200008231823.UAA29344@info.iet.unipi.it> "from Luigi Rizzo at Aug 23, 2000 08:23:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo writes: > And below, when you say that the interaction between bridging+ipfw > was ill-conceived, can you explain where ? I just mean that it needs to be made clear (a) whether ipfw is going to do IP-only filtering or otherwise, and (b) what is the correct path for packets to reach ipfw. IMHO packets should only go through ipfw via the function calls in ip_input() and ip_output(). > 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 Isn't this a result of calling ipfw without going through the "normal" pathways? Or.. do we know the exact pathway that causes this to happen? Where is the m_copypacket() happening? (there must be one, right?) If so, this should be easy to fix (at the expense of speed) by using m_dup() instead of m_copypacket(). This could be a short term fix. > 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. At least, netgraph has strict rules about who "owns" an mbuf. > 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 :) We can acomplish the same thing using the "normal" pathways and avoid the "handful of lines" == "hack" :-) > > I'm willing to work with anyone interested in this project -- or some > > which brings things back to square one... no volunteers aroung :( Well, first let's think about a real plan (i.e., design) for what we want to acomplish. Then we can set about asking for help. You've heard my plan. How would you suggest we address the current situation? And do even fully understand it? (I don't yet) Thanks, -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?200008231910.MAA85466>