From nobody Mon Sep 29 03:22:15 2025 X-Original-To: dev-commits-src-branches@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 4cZmhZ5Cp7z68lfT; Mon, 29 Sep 2025 03:22:22 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cZmhZ3KCXz3p80; Mon, 29 Sep 2025 03:22:22 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759116142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+MhqIeRYv86kAgCsgJPqwAUil2CstKNPbCXkTyXkViM=; b=WpMnyf0Cu4X+lrRluicdY6n0UzTrweGfeu+yLGWmqEOq17pxZKOVhhK3uUtNy+uRkpShMm P/DMeuGoKaCS9l3kjvp/5cToitt/+GRp7TQrVSj3EgPPBRWQxk/0iSdsItCUM0M12V4XXm 3DJPx4GR1GaIAVzVd3T656pizayChj/SiF5XyxcN3mb1RxlgmM35fSk1VhzoT5HWziLC2a Ay5opa+wL+CyzxB+MoageNig8qvrDpt768U5h3VLlfVMZNqMyj5Vd+oJ/QKtWqeXYnRKwI 7tZybkcAj+weq9YL+p3kXuOE0JdHdWAbMT71ev/qQ2vbRwNonQxaQqCPROeHMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759116142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+MhqIeRYv86kAgCsgJPqwAUil2CstKNPbCXkTyXkViM=; b=iIQx12kUpjE8puc6KvhKhMp3GY81sAvdYLLBoatNgYz6vxA8iL1XsENVpFmgAXD9sqeQwM HrbA2NG9kKBrhOEneT8JW64qj6KeBNTJbVzIadApZhtKeRJajvQLxJNJbAJDvDL2caZhc8 NMt93JukceqI4X8iwAVTavymVHkswRZfh0zSz5HOIhjkjAOjZAgtKEWxCe5R/YKJ0HDN7R K/VNCUd7WyTx1Un5sbCHJIHi8jxsKw8aOWv5aCP6WnSOTj4v4GzA2xPyWF/5aIhGXpyI0x fgEn84BNTspGHw7coKRUDok00yebezx80veNFS5m3kxL4Izt5Lg7VxDI0y6LmQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1759116142; a=rsa-sha256; cv=none; b=FLEtr3o8M7exNKtP61aQ3xsPOBa4jG/rX9fB6GoWww20MyMq+tzED91U8baCUnIKfkDKTD qXAuR8Q3ZCSZYZCGm01EyQV+K4OAL10VM29XMcSK2zI4f6iaONWnyx3H72E2FeIu9z2rIk MyBoUkkRz1aqssSkHg0sa2fe9pe3TNH9kJoq1A2mGUI9Oy0KG0bQQxh02KesY9x10Tok3O tBUfof8MYOKn9ODOxygaNCijxR35kBQNTT9SwP+QGSbWiMfnFWzkV8wj3yzzS82Pz49Gvq Mby5k+1wCYQMcO9XNYOKXX2EzSw7RzTKCfTQGUhzEgj44Qv3iLdG8TKlrjmvwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cZmhX2SVLz16HT; Mon, 29 Sep 2025 03:22:20 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A963760F-6B49-4366-A5BC-DC8BF57C03DA" List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-branches@freebsd.org Sender: owner-dev-commits-src-branches@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: git: b4c6c3db0379 - stable/14 - ipfw: Teach ipfw that EtherIP is an upper layer protocol Date: Mon, 29 Sep 2025 11:22:15 +0800 In-Reply-To: <20250927143548.661e75f7@ralga.knownspace> Cc: Michael Tuexen , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-branches@freebsd.org" , Warner Losh To: Justin Hibbits References: <202509271513.58RFDst3083057@gitrepo.freebsd.org> <44DAB9B2-B037-49B0-9153-90B4CFBB6234@FreeBSD.org> <20250927143548.661e75f7@ralga.knownspace> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_A963760F-6B49-4366-A5BC-DC8BF57C03DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 28, 2025, at 2:35 AM, Justin Hibbits = wrote: >=20 > On Sat, 27 Sep 2025 20:32:20 +0200 > Michael Tuexen > wrote: >=20 >>> On 27. Sep 2025, at 17:13, Zhenlei Huang wrote: >>>=20 >>> The branch stable/14 has been updated by zlei: >>>=20 >>> URL: >>> = https://cgit.FreeBSD.org/src/commit/?id=3Db4c6c3db0379a5b3d34143325805cd7e= 68cf3d9a >>>=20 >>> commit b4c6c3db0379a5b3d34143325805cd7e68cf3d9a >>> Author: Zhenlei Huang >>> AuthorDate: 2025-09-16 15:58:24 +0000 >>> Commit: Zhenlei Huang >>> CommitDate: 2025-09-27 15:11:35 +0000 >>>=20 >>> ipfw: Teach ipfw that EtherIP is an upper layer protocol >>>=20 >>> so that we do not discard EtherIP packets ( over IPv6 network ) >>> when net.inet6.ip6.fw.deny_unknown_exthdrs is set to 1 ( which is >>> the default value ). >>>=20 >>> PR: 227450 >>> Reviewed by: ae, #network >>> MFC after: 1 week >>> Differential Revision: https://reviews.freebsd.org/D52566 >>>=20 >>> (cherry picked from commit >>> 0418e6690e91aa6c38dd9af9da43c4c5a9dc1cd2) (cherry picked from >>> commit b1c96e54b906d0cdea0b5a9c74cc295803dfe50e) =20 >> Why is this cherry picked from two commits? Shouldn't this be only >> cherry picked from the commit to the main branch? >>=20 >> Best regards >> Michael >=20 > It's common to cherry-pick from stable to older-stable. This was > likely cherry-picked from stable/15, which was cherry-picked from = main. Exactly ! I have ever encountered merge conflicts when doing MFC and it is painful = to resolve the conflicts multiple times when MFCing to older branches. Also it it likely that branches will no drift too much between closer = ones and less conflicts can happen, e.g. stable/15 and stable/14, but = not main and stable/14, As Warner pointed out, if no merge conflicts happens then it is OK to = MFC from main to older branches. To make it simple ( I'm a little lazy ~ ) I'd always choose MFC from a = near branch. Best regards, Zhenlei >=20 > - Justin >=20 >>> --- >>> sys/netpfil/ipfw/ip_fw2.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>>=20 >>> diff --git a/sys/netpfil/ipfw/ip_fw2.c b/sys/netpfil/ipfw/ip_fw2.c >>> index 0e0ecd3c6b20..928ccefe4803 100644 >>> --- a/sys/netpfil/ipfw/ip_fw2.c >>> +++ b/sys/netpfil/ipfw/ip_fw2.c >>> @@ -67,6 +67,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>>=20 >>> #include >>> @@ -1717,6 +1718,12 @@ do { \ >>> PULLUP_TO(hlen, ulp, struct ip); >>> break; >>>=20 >>> + case IPPROTO_ETHERIP: /* RFC 3378 */ >>> + PULLUP_LEN(hlen, ulp, >>> + sizeof(struct etherip_header) + >>> + sizeof(struct ether_header)); >>> + break; >>> + >>> case IPPROTO_PFSYNC: >>> PULLUP_TO(hlen, ulp, struct pfsync_header); >>> break; =20 --Apple-Mail=_A963760F-6B49-4366-A5BC-DC8BF57C03DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 28, 2025, at 2:35 AM, Justin Hibbits <chmeee@has.gonegalt.net> wrote:

On Sat, 27 Sep 2025 20:32:20 +0200
Michael = Tuexen <tuexen@FreeBSD.org> wrote:

On= 27. Sep 2025, at 17:13, Zhenlei Huang <zlei@FreeBSD.org> = wrote:

The branch stable/14 has been = updated by zlei:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3Db4c6c3db0379a5b3d3414= 3325805cd7e68cf3d9a

commit = b4c6c3db0379a5b3d34143325805cd7e68cf3d9a
Author: =     Zhenlei Huang <zlei@FreeBSD.org>
AuthorDate: 2025-09-16 15:58:24 +0000
Commit: =     Zhenlei Huang <zlei@FreeBSD.org>
CommitDate: 2025-09-27 15:11:35 +0000

  ipfw: Teach ipfw that EtherIP is an upper layer = protocol

  so that we do not = discard EtherIP packets ( over IPv6 network )
when = net.inet6.ip6.fw.deny_unknown_exthdrs is set to 1 ( which is
the default value ).

  PR: =             22= 7450
  Reviewed by:    ae, = #network
  MFC after: =      1 week
  Differential Revision: =  https://reviews.freebsd.org/D52566

  (cherry picked from commit
0418e6690e91aa6c38dd9af9da43c4c5a9dc1cd2) (cherry picked = from
commit b1c96e54b906d0cdea0b5a9c74cc295803dfe50e) =  
Why is this cherry picked from two = commits? Shouldn't this be only
cherry picked from the = commit to the main branch?

Best regards
Michael

It's common to cherry-pick from stable to older-stable. =  This was
likely cherry-picked from stable/15, which was cherry-picked = from main.

Exactly !

I = have ever encountered merge conflicts when doing MFC and it is painful = to resolve the conflicts multiple times when
MFCing to older = branches.

Also it it likely that = branches will no drift too much between closer ones and less conflicts can happen, e.g. stable/15 and stable/14, = but not main and stable/14,

As = Warner pointed out, if no merge conflicts happens then it is OK to MFC = from main to older branches.

To = make it simple ( I'm a little lazy ~ ) I'd always choose MFC from a near = branch.

Best = regards,
Zhenlei


- Justin

---
sys/netpfil/ipfw/ip_fw2.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/sys/netpfil/ipfw/ip_fw2.c = b/sys/netpfil/ipfw/ip_fw2.c
index = 0e0ecd3c6b20..928ccefe4803 100644
--- = a/sys/netpfil/ipfw/ip_fw2.c
+++ = b/sys/netpfil/ipfw/ip_fw2.c
@@ -67,6 +67,7 @@
#include <net/route/nhop.h>
#include = <net/pfil.h>
#include <net/vnet.h>
+#include <net/if_gif.h>
#include = <net/if_pfsync.h>

#include = <netpfil/pf/pf_mtag.h>
@@ -1717,6 +1718,12 @@ do { = \
PULLUP_TO(hlen, ulp, struct ip);
break;

+ case IPPROTO_ETHERIP: /* RFC 3378 */
+ PULLUP_LEN(hlen, ulp,
+ =    sizeof(struct etherip_header) +
+ =    sizeof(struct ether_header));
+ = break;
+
case IPPROTO_PFSYNC:
PULLUP_TO(hlen, ulp, struct pfsync_header);
break; =  


= --Apple-Mail=_A963760F-6B49-4366-A5BC-DC8BF57C03DA--