From owner-freebsd-net@freebsd.org Sat Jul 20 16:56:30 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B2E59C27F8 for ; Sat, 20 Jul 2019 16:56:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 94FE188A36 for ; Sat, 20 Jul 2019 16:56:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 92A75C27F7; Sat, 20 Jul 2019 16:56:30 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9269FC27F6 for ; Sat, 20 Jul 2019 16:56:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72D6B88A35 for ; Sat, 20 Jul 2019 16:56:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4B094D5E3 for ; Sat, 20 Jul 2019 16:56:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6KGuUmp079272 for ; Sat, 20 Jul 2019 16:56:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6KGuUBa079271 for net@FreeBSD.org; Sat, 20 Jul 2019 16:56:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently Date: Sat, 20 Jul 2019 16:56:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 72D6B88A35 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 16:56:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #31 from Cy Schubert --- 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 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.=