From nobody Sun Aug 25 18:32:45 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WsMqd3wWWz5TJZk for ; Sun, 25 Aug 2024 18:32:45 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WsMqd24Shz473w for ; Sun, 25 Aug 2024 18:32:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1724610765; a=rsa-sha256; cv=none; b=K6kFwyGr57uBSPTDaupRb3jX3WXjWofoAtRZO/Wz1PQAo4HwMJkC6HSVAT8hu0NlEzIY+D 36foZg2Fyawa/sHNj2bCA5rp+gBAHxi02trtc5IElaMMGJG8tWF/q4nykBVDNWzHkpcy8y TnXz3zIntjOZN0L+ssqAzOSCRED3at2Q7QL4iqoynWRzB+inuZFQjzQ+p3fNYCV1bK6szt OKJDdawrSq5bkBpqWr0E+wVRFHuG20WDVD5+xyjdDOMiT1XcjmeGgk9n+sbbWVSYc+bTme t1UvI0aiE6nYiXQbtbGq92368d7K9GTbvXryW3JaKe/zciIlDf6TQnG3TFXqoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724610765; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Phr6cj8ej+J+bZXr9DNsh+XMBCRCKdbKTbQRIj7jqVo=; b=U4W+xFxgf1zAM0xZD5lQ79/4aIO0qPL69xZi12LiEVYyL3HMaRWKi8sgYpO4hxWc2rIqxO CMlcjxLcbrsUZcTezgMaW31FSopWzknjJOWDfGwq/sgCse0F+rnC8maifKrtYGogtdtXOo yCkEfulcjMxly/y5ewcr9rolx3zl4FFOK9tKXCsKzqUxuF+RJwzdklY4tRezBnW0HVG5Kv b2nHwypo3PeXrRNmadT4r5B0TxdvdDILw324PBLv7Kz+IyFj8QYnqGUkadOc/jcE0zEjju nfCgU+WhWOwEf16nCfDGJ44ZDrdXLgU5ae8yU/bfBQburpn+xYZxYy5BX9uE9A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4WsMqd1dfYzZqk for ; Sun, 25 Aug 2024 18:32:45 +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 47PIWjte026960 for ; Sun, 25 Aug 2024 18:32:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 47PIWjUm026959 for net@FreeBSD.org; Sun, 25 Aug 2024 18:32:45 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 280701] FreeBSD-SA-24:05 fix breaks ICMP/ICMP6 states handling in pf firewall (ping, traceroute) Date: Sun, 25 Aug 2024 18:32:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280701 --- Comment #57 from Franco Fichtner --- In closing I'd like to add a few things. It was made known that a proper bug report and steps to reproduce should be raised. I think that's only fair. This, however, requires the undesired behaviour to follow established rules which do not readily apply here. The core of the problem as we as OPNsense see it is that pf state tracking = was added to several ICMPv6 types that were not there before -- first and forem= ost ND_NEIGHBOR_SOLICIT/ND_NEIGHBOR_ADVERT. It can be said that the state trac= king is insufficient now in at least these two types of ICMPv6 communication whi= ch results in intermittent package drops. This also results in easily visible ping drops as neighbour discovery fails intermittently. The full scope of = this change is highly speculative and it has been hinted at in OPNsense and Open= BSD that further issues exist with other ICMPv6 types contained within this cha= nge. The way forward in FreeBSD releases now should be treated with the appropr= iate amount of foresight. If you want to ask for easily reproducible steps please also ask how easily reliable tests could have been added for this. Testing all of this is very difficult as I'm sure we all know now. I think we are all here to help avo= id and remedy problems together. It's not my place to question why adding state tracking to pf/ICMPv6 was a = good idea to everyone involved in bringing this to all FreeBSD releases immediat= ely so far. Someone should ask that question internally probably. A better ta= rget for this would be FreeBSD 15.0 in my very humble opinion. It would be beneficial now to have a real IPv6 expert inspect these state tracking attempts because I think so far that hasn't happened. OPNsense do= es a lot of IPv6 and does it quite well, but we are in now way experts. My first reaction to seeing the ICMP patches on stable/14 was to ignore them, but th= at was made impossible by pushing them to SA state in the way they were. Also to remind everyone what downstream does: we are trying to run projects based on FreeBSD and we mostly build integration for other software. Ideal= ly we do this on unmodified FreeBSD. Yet upstreaming patches is increasingly difficult and hostile. Our kernels only diverge because of: (1) Too strict errata policy on FreeBSD releases, and (2) upstreaming patches and stable turnaround times are too long. This causes friction with committers because they don't trust us or our capabilities or reports and think things like kernel patches are our own problems. All of it only leads to more divergence. I think that should be said here once for emphasis. And as a personal matter we should stop with the idea of "conspiracy theorising" and "downstream is broken". This will not advance FreeBSD in t= he way that it should. As far as this discussion goes I think FreeBSD has all the information that= it needs to progress this. As downstream we certainly will make a move based = on what we found out so far, too. Good luck. Cheers, Franco --=20 You are receiving this mail because: You are the assignee for the bug.=