Date: Sat, 20 Jul 2019 16:56:29 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently Message-ID: <bug-238796-7501-TzoNx2vVzw@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-238796-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-238796-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #31 from Cy Schubert <cy@FreeBSD.org> --- fr_tifs and fr_dif are not indexes. frdest_t fr_tifs[2]; /* "to"/"reply-to" interface */ frdest_t fr_dif; /* duplicate packet interface */ They're a struct with an IP address + an index or a linked list if enclosed= in {}. I don't think the problem is there either. Treating fr_tif, fr_rif and fr_dif simply as indexes is wrong. Agreed. The patch is flawed as it didn't fix anything. I assumed from your description that the problem was any time "to" was used where in fact it is more esoteric than that. Only with "to" when "on" is relocated, and why I am not able reproduce the problem simply with your examples. Taking the same r= ule and relocating on <INTERFACE> reproduces the problem, but only once as by t= hat time there is a second copy of the shadowed rule. My reply #29 clearly show= s it works in cases where the rule is coded the same but fails to detect the shadowed rule if the on keyword is moved to before the reply-to keyword, but only the first time because the shadowed rule is now added and it subsequen= tly matches. It is clearl that frentry_t is constructed differently when the on keyword is moved. Darren's March 2009 patch resolved one (more serious) issue while breaking this. There is a subtle mistake in the March 2009 patch that needs to be fi= xed. Unfortunately I disagree with his (and many other people's) style of commit= s, batching multiple fixes in one commit. It make it difficult to bisect the patches from each other and it's not clean either, messing up history. What is disconcerting is that this bug is probably symptomatic of a another more serious bug. I've fixed other bugs like this in that it's either hurri= ed development or incomplete features and fixes (ippool is an excellent exampl= e of this where I finally have it working but for IPv4 only) which is why I want= to discover the root cause. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238796-7501-TzoNx2vVzw>