Date: Wed, 23 Aug 2000 10:26:24 -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.ORGG Subject: Re: bridging and freebsd crash Message-ID: <200008231726.KAA79356@bubba.whistle.com> In-Reply-To: <200008230736.JAA27319@info.iet.unipi.it> from Luigi Rizzo at "Aug 23, 2000 09:36:12 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo writes:
> > I'll restate my suggestion: rewrite the bridging code as a netgraph node.
>
> Ok, sorry but at this point i think i need to say this on the list.
> People, do not take this as a personal attack as it is not.
>
> Archie- it's much simpler than that. Bridging+ipfw in 3.x did not
> have the problems that people is mentioning -- at least i have had
> quite a few of them in use for a long time now and no reports for
> weird crashes (i am specifically referring to the picobsd images
> available from my web site which is almost exactly the code in the
> RELENG_3 tree).
>
> The problems in 4.x/5.x are likely due to improper mbuf handling
> (specifically, these mbufs are shared between device drivers and
> in some cases upper layers in the protocol stack, which is fine
> but requires a bit of care in doing things, and timing is very much
> hardware dependent), and some code that was deleted, all of this
> is related to your ether_input() changes.
>
> As it told you at that time, I agreed on the change in principle
> (as we gain a lot in terms of reduced code bloat and more supported
> cards); however, doing the commit without testing that bridging
> was still working with all features after the change was really
> a bad idea -- and i also told you this.
>
> I don't want to look as the one who complains "i knew it" as i did
> not have the time (nor i do now, at least in the near future) to
> do the required testing and fix things, but, alas, i did not commit
> such code!
Luigi-
No offense taken, and all of the above is a fair description.
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
because they make the code more modular and maintainable, and
removed redundant code, not to mention as a side effect adding
bridging support for *all* Ethernet drivers in one fell swoop.
My apologies for breaking things -- as stated on this list when
proposing those changes, I have limited testing capability for
bridging here. Nobody offered to help at the time. C'est la vie.
In any case, let's look forward.. how can we best fix the remaining
problems?
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).
2. Have an /etc/rc.bridge or whatever that contains the relevant
ngctl(8) commands to set up bridging over the desired interfaces.
3. Packets received on a bridge interface will have m->m_pkthdr.rcvif
set appropriately, so ipfw filtering on a per-interface basis
will still work.
I'm not just saying this because I like netgraph, but rather because
it has (by design) advantages that are applicable here. For example,
the problem of an unvalidated packet reaching ipfw simply will not
happen using netgraph. The reason this is happening now is because
of the current, ill-conceived bridging+ipfw interaction.
I'm willing to work with anyone interested in this project -- or some
other variant, as long as it doesn't regress to the previous state of
things.
-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?200008231726.KAA79356>