Date: Fri, 13 May 2005 17:30:12 +0200 From: Andre Oppermann <andre@freebsd.org> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: freebsd-net@FreeBSD.org Subject: Re: Dummynet/ipnat interaction breakage Message-ID: <4284C804.ABC0C314@freebsd.org> References: <D86BF562467D944EB435513F725B236A07C13C@exchange.stardevelopers4msi.com> <20050513100606.GE667@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremie Le Hen wrote: > > On Wed, Feb 02, 2005 at 12:05:11PM +0100, Jeremie Le Hen wrote: > > > Take a look at PRs 61685 and 76539. Hope that helps. > > > > Well, I was aware of the first one (I'm doing shaping on my internal > > interface as a workaround), but not the second one. The second one > > is very new and this could indeed be the same problem I encountered. > > > > It seems that the import of IPFilter 3.4.35 in the middle of 2004 is > > the source of the problem because when I switch back to 3.4.31 on > > 4.11, everything works. > > > > I Cc'ed andre@ since he had not took over 76539, maybe he's not aware > > of it. > > > > Andre, what can you tell us about the drawbacks of the proposed patches ? > > I think there must be some as they would have been merged if this was > > not the case. > > > > Are there any change to have this fixed in RELENG_4 ? I know that no > > more releases are scheduled in this branch, but there is no obvious > > reason to let a bug live there IMHO. > > 4.1 is still broken. I understand that RELENG_4 is at end of its life > but ipnat/dummynet interaction further breakage between 4.10 and 4.11 > (due to IPFilter 3.4.35 import) is, IMHO, not acceptable for FreeBSD, > especially RELENG_4 which is a must in term of stability and release > engineering. My workaround was to go back to RELENG_4_10 branch in > src/sys/contrib/ipfilter. > > Given that *there are* patches in these PR, although we should admit > these are not examples of long term solution, is there any chance to > get this commited into RELENG_4 to assist this old good branch until > its funeral ? The problem is not to break something while 'fixing' this problem. I haven't looked at the proposed patch but not the entire code path in either 4.11 or 5.4. However it seems very likely to me that this 'fix' breaks ipfw one_pass/multi_pass. In ipfw/dummynet you may want packets coming from dummynet to continue with the next ipfw rule. Unconditionally setting M_SKIP_FIREWALL is going to break it. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4284C804.ABC0C314>