From owner-freebsd-stable Sun May 21 9:28: 5 2000 Delivered-To: freebsd-stable@freebsd.org Received: from darren2.lnk.telstra.net (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (Postfix) with ESMTP id 35C0B37B92F; Sun, 21 May 2000 09:27:55 -0700 (PDT) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by darren2.lnk.telstra.net (8.9.1/8.8.7) id QAA28879; Sun, 21 May 2000 16:26:54 GMT From: Darren Reed Message-Id: <200005211626.CAA12901@avalon.reed.wattle.id.au> Subject: 4.0_STABLE Broken (was Re: FTP proxy without translation no longer working? (fwd)) In-Reply-To: <20000521102808.C5468@prism.flugsvamp.com> from Jonathan Lemon at "May 21, 0 10:28:08 am" To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Mon, 22 May 2000 02:26:50 +1000 (EST) Cc: darrenr@reed.wattle.id.au, freebsd-stable@freebsd.org, ps@freebsd.org, Cy.Schubert@uumail.gov.bc.ca X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In some email I received from Jonathan Lemon, sie wrote: > On Sun, May 21, 2000 at 02:28:30PM +1000, Darren Reed wrote: > > Jonathan, > > Can you please back these changes out for 4.0_STABLE ? > > They appear to interfere with the operation IP Filter. I'm happy > > for these to on the head and for there to be work required to get > > things working again. If I don't hear/see from you within the > > next week, I'll assume that you otherwise are not that concerned > > and offer to backout the changes myself. > > Well, instead of backing the changes out, how about we fix the problem > instead? I'm not familiar with IPFilter, but I know that there were > some initial problems with ipfw, perhaps the problems here are similar. Okay. So you want to play "pass the buck". Backing out that change (which does not fix *any* bugs!) will "fix the problem". As it is, you've introduced a _new feature_ to the _STABLE branch and broken something. In my book, that's two crosses you've marked up: changes to _STABLE must not break it and new features must be extensively tested in -current before committing to a release branch. To summarise, some very good reasons why that change should be backed out of 4.0_STABLE: 1. It breaks 4.0_STABLE 2. It breaks 4.0_STABLE 3. It breaks 4.0_STABLE Do you need any more ? I am given to understand that FreeBSD doesn't have a very strict (read absent) release engineering policy which allows for this sort of thing to happen. The change (as I understand it) is not necessary for stability. It would appear that it needs some testing under -current and until it works flawlessly there should not be brought into the -stable branch. At least that is how the current "release engineering" process works, right ? Put it in -current and if there are no problems, put it on -stable and if there are problems there, remove from -stable until things are fixed in -current ? Or is that a failure on my part to believe that things should be fixed in -current before they are patched up in -stable ? It *SHOULD NOT* matter that there "may be" a problem with how IP Filter is handling the checksums (and given the comments from your changes for things like IP divert I'm sure there are). Commits to -stable should *NOT* break -stable in any way. Or am I wrong in making that statement and that commits to -stable are (now) allowed to break it ? Jordan ? > What happens now is that the TCP/UDP layer will place the pseudo > checksum in the TCP/UDP header, and set a flag in the mbuf. After > the IP layer determines which interface the packet is going out on, > it will compute the checksum if: 1. the interface indicates it does > not support delayed checksums, and 2. the delayed csum flag is set > in the mbuf. Sounds like a similar sort of `hack' used in Solaris for devices which do the TCP checksum in hardware (at present limited to Gigabit and ATM cards, AFAIK). > If the packet is intercepted/redirected at some point between the > upper (TCP) and lower (IP) layers, then it will not have a valid > checksum. In this case, there needs to be a small bit of code to > force the checksum to be computed if necessary. E.g.: > > if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { > in_delayed_cksum(m); > m->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; > } > > I don't know where IPFilter hooks into the stack, so I don't know > where the appropriate point to put this would be. Well, maybe you should have thought of that *before* you merged the change from -current into 4.0_STABLE ? Jordan, if you're reading this, you should give some *serious* thought to setting up a proper release engineering team - they should be dealing with this, not me and Jonathan directly pissing on each other. Allowing the "unwashed" (i.e. committers) to commit to released and stable branches is an invitation for disaster, IMHO. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message