Re: git: b4c6c3db0379 - stable/14 - ipfw: Teach ipfw that EtherIP is an upper layer protocol
- Reply: Warner Losh : "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: Sat, 27 Sep 2025 18:44:23 UTC
> On 27. Sep 2025, at 20:35, 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=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. That is why I am asking. My understanding is that we should * MFC from main to stable/15 * MFC from main to stable/14 * MFC from stable/14 to releng/14.4 So I might be wrong and and I should actually do instead * MFC from main to stable/15 * MFC from stable/15 to stable/14 * MFC from stable/14 to releng/14.4 I know that releng/14.4 does not exist, but there is a time window we can get changes into relen/14.4 with approval from re@. I would just like to know how I should MFC to stable/14... Best regards Michael > > - 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; >> >