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