Re: git: b4c6c3db0379 - stable/14 - ipfw: Teach ipfw that EtherIP is an upper layer protocol
- Reply: Andriy Gapon : "Re: git: b4c6c3db0379 - stable/14 - ipfw: Teach ipfw that EtherIP is an upper layer protocol"
- In reply to: Justin Hibbits : "Re: git: b4c6c3db0379 - stable/14 - ipfw: Teach ipfw that EtherIP is an upper layer protocol"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 29 Sep 2025 03:22:15 UTC
> 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 <mailto: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=b4c6c3db0379a5b3d34143325805cd7e68cf3d9a >>> >>> 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: 227450 >>> 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;