Re: git: b4c6c3db0379 - stable/14 - ipfw: Teach ipfw that EtherIP is an upper layer protocol

On Sat, Sep 27, 2025, 12:44 PM Michael Tuexen <tuexen@freebsd.org> wrote:

> > 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...
>

Either way works. Without conflicts I do main to both. With conflicts I do
main to 15 and then 15 to 14. For releng, it's always from the stable
branch.

Warner

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;
> >>
> >
>
>