Date: Thu, 26 Oct 2006 07:10:17 +1300 From: Andrew Thompson <thompsa@freebsd.org> To: Darren Reed <darrenr@hub.freebsd.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_bridge.c Message-ID: <20061025181017.GA62176@heff.fud.org.nz> In-Reply-To: <20061025175302.GB94866@hub.freebsd.org> References: <200604290537.k3T5bPXC071830@repoman.freebsd.org> <20061025175302.GB94866@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 25, 2006 at 05:53:02PM +0000, Darren Reed wrote: > On Sat, Apr 29, 2006 at 05:37:25AM +0000, Andrew Thompson wrote: > > thompsa 2006-04-29 05:37:25 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/net if_bridge.c > > Log: > > Add support for fragmenting ipv4 packets. > > > > The packet filter may reassemble the ip fragments and return a packet that is > > larger than the MTU of the sending interface. There is no check for DF or icmp > > replies as we can only get a large packet to fragment by reassembling a > > previous fragment, and this only happens after a call to pfil(9). > > I'm a long time in catching up with this change, but architecturally, > this change is very very wrong. > > A bridge should have _no_ part in fragmenting up an IP packet > regardless of what options are set (or not set) in an IP header. Its not really the bridge that is fragmenting packets. The packet filter may reassemble fragments and return a packet larger than we can send, the fragmenting is done in the layer between bridge<->pfil. As long as we may be returned a large packet this is unavoidable. I agree that a bridge should not have anything to do with IP, and technically it isn't. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061025181017.GA62176>