Created attachment 192442 [details] Patch for if_gif(4). First, I want to apologize for my bad English, because I'm not a native speaker. Should not all packets processed by gif_output be deleted, when an running instance of if_gif(4) is member of an instance of if_bridge(4)? This question opened to me as I tried to understand the internal structure of gif_transmit in the context of encapsulating Ethernet frames as service data units of EtherIP prtocol. If I understood correctly, then gif_transmit would be called by bridge_enqueue at runtime, if an instance of if_gif(4) is member interface of if_bridge(4)?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8a0308722372a3ac6a94967ae4fe3123842309e2 commit 8a0308722372a3ac6a94967ae4fe3123842309e2 Author: Marius Strobl <marius@FreeBSD.org> AuthorDate: 2023-07-23 16:58:42 +0000 Commit: Marius Strobl <marius@FreeBSD.org> CommitDate: 2023-07-26 11:14:22 +0000 gif(4): Assert that gif_output() isn't called for EtherIP With the current implementation of if_bridge(4), bridge_enqueue() calls gif_transmit() only. Ensure it stays that way so that the expectations in both drivers are either met or changed accordingly. PR: 227450 sys/net/if_gif.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b59b3443f39d2b7d6c631094fde7723e0aec1319 commit b59b3443f39d2b7d6c631094fde7723e0aec1319 Author: Marius Strobl <marius@FreeBSD.org> AuthorDate: 2023-07-23 16:58:42 +0000 Commit: Marius Strobl <marius@FreeBSD.org> CommitDate: 2023-08-06 17:17:30 +0000 gif(4): Assert that gif_output() isn't called for EtherIP With the current implementation of if_bridge(4), bridge_enqueue() calls gif_transmit() only. Ensure it stays that way so that the expectations in both drivers are either met or changed accordingly. PR: 227450 (cherry picked from commit 8a0308722372a3ac6a94967ae4fe3123842309e2) sys/net/if_gif.c | 3 +++ 1 file changed, 3 insertions(+)
Hi, I found this broke ethernet over IPv6 when I was testing a fix for bug 280736. - https://reviews.freebsd.org/D51297 gif_output() may be called due to internal behavior of IPv6 stack when the outer protocol of the tunnel is IPv6. So the kernel should not panic in such cases. Proposed fix is here: - https://reviews.freebsd.org/D51352
(In reply to Koichiro Iwao from comment #3) > Hi, I found this broke ethernet over IPv6 when I was testing a fix for bug 280736. May you please share a minimal setup for `ethernet over IPv6` ?
(In reply to Zhenlei Huang from comment #4) > May you please share a minimal setup for `ethernet over IPv6` ? Emm, surely the setup that breaks `ethernet over IPv6` feature.
(In reply to Zhenlei Huang from comment #5) posting from mobile phone so forgive me if inadequate just replace the tunnel endpoint of this post with ifconfig gif0 inet tunnel <src ipv6> <dst ipv6> https://forums.freebsd.org/threads/transparent-bridge-gif.49729/#post-277956
(In reply to Koichiro Iwao from comment #6) > ifconfig gif0 inet tunnel <src ipv6> <dst ipv6> i meant ifconfig gif0 inet6 tunnel
I'm on 15-CURRENT 3d5ef29825557bddc08b1171126026b051043194. I added the following debug code to gif_output(), then I got the debug output like this. Obviously, gif_output() is called even if gif is attached to a bridge. int gif_output(struct ifnet *ifp, struct mbuf *m, const struct sockaddr *dst, struct route *ro) { uint32_t af; if (ifp->if_bridge != NULL) { if (dst->sa_family == AF_INET6) { const struct sockaddr_in6 *sin6 = (const struct sockaddr_in6 *)dst; char ipstr[INET6_ADDRSTRLEN]; inet_ntop(AF_INET6, &(sin6->sin6_addr), ipstr, sizeof(ipstr)); printf("gif_output: DEBUG6 addr=%s ifname=%s\n", ipstr, ifp->if_xname); m_freem(m); return (0); } } KASSERT(ifp->if_bridge == NULL, gif_output: DEBUG6 addr=ff02:4::1:ff07:4111 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::16 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::16 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::2 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::16 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::16 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::2 ifname=gif0 gif_output: DEBUG6 addr=ff02:4::2 ifname=gif0
(In reply to Koichiro Iwao from comment #8) (In reply to Koichiro Iwao from comment #7) I managed to repeat this issue. This happens when a gif(8) interface is a member of if_bridge(4) , and still has IPv6 address assigned and try to send traffic from this IPv6 address. That is IMO harmless, since we can distinguish IP-IPv6, IPv6-IPv6 and Ether-IPv6 via the ip proto. So I think the asserting ( "unexpectedly called with bridge attached" ) is too strong. Well surely the implementation should be **fixed** to support that.
(In reply to Zhenlei Huang from comment #9) Thanks! Maybe we just need to remove KASSERT?
(In reply to Koichiro Iwao from comment #10) > Thanks! Maybe we just need to remove KASSERT? Unfortunately not enough. Requires a little effort.
Created attachment 262260 [details] Patch EtherIP Hi Koichiro, try this patch :)
(In reply to Zhenlei Huang from comment #12) LGTM at quick glance, let me further test.
(In reply to Zhenlei Huang from comment #12) No issues during my further test, thank you!
Just for the record, here's the minimal setup to reproduce. rc.conf is not modified from the default setup of FreeBSD-15.0-CURRENT-amd64-BASIC-CLOUDINIT-20250724-01c587521dd8-279004-ufs.qcow2.xz. hostname="freebsd" firstboot_freebsd_update_enable=YES growfs_enable=YES sshd_enable=YES nuageinit_enable=YES dumpdev="AUTO" ifconfig_DEFAULT="SYNCDHCP accept_rtadv" # RSA host keys are obsolete and also very slow to generate sshd_rsa_enable="NO" Set up minimal Ethernet over IPv6. ifconfig bridge0 create ifconfig epair0 create ifconfig gif0 create mtu 1500 ifconfig gif0 inet6 tunnel 2001:db8::1 3fff::1 ifconfig bridge0 addm gif0 addm epair0a 1753415597 (Wait around 5 minutes, kernel will panic) panic: gif_output: unexpectedly called with bridge attached cpuid = 2 time = 1753415820 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008c2ac950 vpanic() at vpanic+0x136/frame 0xfffffe008c2aca80 panic() at panic+0x43/frame 0xfffffe008c2acae0 gif_output() at gif_output+0x5b/frame 0xfffffe008c2acaf0 ip6_output() at ip6_output+0x1ca5/frame 0xfffffe008c2accb0 mld_dispatch_packet() at mld_dispatch_packet+0x325/frame 0xfffffe008c2acd30 mld_fasttimo() at mld_fasttimo+0x520/frame 0xfffffe008c2ace10 softclock_call_cc() at softclock_call_cc+0x19b/frame 0xfffffe008c2acec0 softclock_thread() at softclock_thread+0xc6/frame 0xfffffe008c2acef0 fork_exit() at fork_exit+0x82/frame 0xfffffe008c2acf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe008c2acf30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 2 tid 100039 ] Stopped at kdb_enter+0x33: movq $0,0x1235072(%rip) If an IPv6 (link-local) address is assigned to epair0a, it cannot be added to a bridge member, and IPv6 addresses cannot be assigned if the interface is a bridge member (invalid argument). However, even if the interface is a bridge member, a link-local address may still be assigned to it. The default rc.conf setup of the VM-IMAGE is the case. Kernel will panic when it tries to send traffic from the IPv6 address, as zlei mentioned. zlei's patch works fine for me. Shall we move forward?
(In reply to Koichiro Iwao from comment #15) > ip6_output() at ip6_output+0x1ca5/frame 0xfffffe008c2accb0 > mld_dispatch_packet() at mld_dispatch_packet+0x325/frame 0xfffffe008c2acd30 > mld_fasttimo() at mld_fasttimo+0x520/frame 0xfffffe008c2ace10 Yeah, another possible path to trigger the assert panic. > zlei's patch works fine for me. Shall we move forward? The patch deserves a regression test, but I'm traveling home so no build machine at hand and can not easily debug the regression test. Let me have a try with the developer FreeBSD.org hosts.
Add a link to phabricator.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f4744b8acb932fbb3e48b71d31b7cd585566b668 commit f4744b8acb932fbb3e48b71d31b7cd585566b668 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-08-08 10:17:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-08-08 10:17:51 +0000 EtherIP: Fix passing the address family from if_bridge(4) to gif(4) Given IPPROTO_IPV4, IPPROTO_IPV6 and IPPROTO_ETHERIP have different protocol numbers, then it is perfect valid to tunnel IPv4, IPv6 and Ethernet traffic over IPv[46] by the same interface. Since gif(4) has already utilized the inbound csum_data field to carry address family, also teach if_bridge(4) to do that, rather than checking if a gif(4) interface is member of a if_bridge(4) interface. Without this fix, tunnel IPv[46] over IPv[46] will not work when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup, as the address family passed from gif_output() will be overwritten with the wrong one AF_LINK by gif_transmit(), and end up with incorrectly encapsulated packets. PR: 227450 Reviewed by: kp Tested by: meta Fixes: 8a0308722372 gif(4): Assert that gif_output() isn't called for EtherIP MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 sys/net/if_bridge.c | 6 ++++++ sys/net/if_gif.c | 10 +++------- 2 files changed, 9 insertions(+), 7 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=04d0dc4c0c65592a21225cff43f25e0a0da64eb9 commit 04d0dc4c0c65592a21225cff43f25e0a0da64eb9 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-08-08 10:17:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-08-08 10:17:51 +0000 tests: gif(4): Add regression tests for setup with EtherIP Tunnel IPv[46] traffic over IPv[46] should still function when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup. PR: 227450 Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 tests/sys/net/if_gif.sh | 154 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+)
Created attachment 263128 [details] failing test report The 'sys/net/if_gif:etherip' and 'sys/net/if_gif:etherip6' testcases fail in CI at the latest CURRENT. @zlei, would you be able to reproduce the errors and investigate? I have reproduced this error with two methods and attached a sample test-report.txt: 1. using src in-tree local CI: # make -C tests/ci CITYPE=full PARALLEL_JOBS=2 VM_MEM_SIZE=4g KYUA_TEST_FILTERS='sys/net/if_gif:etherip sys/net/if_gif:etherip6' 2. using bricoler[0]: $ bricoler run freebsd-src-regression-suite --param freebsd-src:url=/usr/src --param freebsd-src:branch= --param freebsd-src-regression-suite:hypervisor=bhyve --param freebsd-src-regression-suite:memory=4096 --param freebsd-src-regression-suite:ncpus=2 --param freebsd-src-regression-suite:parallelism=1 --param freebsd-src-regression-suite:tests='sys/net/if_gif:etherip sys/net/if_gif:etherip6' [0] https://github.com/markjdb/bricoler
Created attachment 263131 [details] Fix testcase etherip and etherip6 (In reply to Siva Mahadevan from comment #20) I think I see what happened. From the test log, > ifconfig: BRDGADD gif0: Invalid argument (extended error Member interface may not have an IPv4 address configured) > ifconfig: BRDGADD gif0: Invalid argument (extended error Member interface may not have an IPv4 address configured) @Lexi introduced `net.link.bridge.member_ifaddrs` which is default false hence disallow adding interface with IP addresses to a bridge(4) interface. When I was developing the tests, I have trouble with current/15 as kernel and release/14.3 as userland, see also https://reviews.freebsd.org/D52028, so I mainly use stable/14 and stable/13 and indeed left current/15 untested. Really sorry for that. The uploaded patch should fix the two tests. I do not have test machine at hand. Probably I can fix it before Monday.
(In reply to Zhenlei Huang from comment #21) UPDATE > The uploaded patch should fix the two tests. I do not have test machine at hand. > Probably I can fix it before Monday. The proposed final fix is https://reviews.freebsd.org/D52200 . CC Li-Wen, I realize the CI is able catch my mistake but it did not. Maybe there's something wrong with the CI servers ?
Thanks for the fix! > I realize the CI is able catch my mistake but it did not. Maybe there's something wrong with the CI servers ? I think the FreeBSD-main-amd64-test runs are delayed for a long time, but it is being caught daily on aarch64. See here: https://ci.freebsd.org/view/Test/job/FreeBSD-main-aarch64-test/lastCompletedBuild/testReport/
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9764aa1ccad08a7ec53ed9b80741b9553f3fa4e6 commit 9764aa1ccad08a7ec53ed9b80741b9553f3fa4e6 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-01 10:14:22 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-01 10:14:22 +0000 bridge: Fix adding gif(4) interface assigned with IP addresses as bridge memeber and fix assigning IP addresses to the gif(4) interface when it is a member of a if_bridge(4) interface. When setting the sysctl net.link.bridge.member_ifaddrs to 1, if_bridge(4) can eliminate unnecessary walk of the member list to determine whether the inbound unicast packets are for us or not. Well when a gif(4) interface is member of a if_bridge(4) interface, it acts as the tunnel endpoint to tunnel Ethernet frames over IP network, aka the EtherIP protocol, so the IP addresses configured on it are independent of the if_bridge(4) interface or other if_bridge(4) members, hence the sysctl net.link.bridge.member_ifaddrs should not have any influnce over gif(4) interfaces's behavior of assigning IP addresses. PR: 227450 Reported by: Siva Mahadevan <me@svmhdvn.name> Reviewed by: ivy, #bridge MFC after: 1 week Fixes: 0a1294f6c610 bridge: allow IP addresses on members to be disabled Differential Revision: https://reviews.freebsd.org/D52200 sys/net/if_bridge.c | 6 +++--- sys/netinet/in.c | 4 ++-- sys/netinet6/in6.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b944c8ff17971b1c8f61d5612eac146f5d589e87 commit b944c8ff17971b1c8f61d5612eac146f5d589e87 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-01 10:14:22 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-01 10:14:22 +0000 tests: bridge: Add regression test for gif(4) interface as bridge member if_bridge(4) should not prohibit adding a gif(4) interface which is assigned with IP addresses as a bridge member regardless of the setting of sysctl variable net.link.bridge.member_ifaddrs. Assigning IP addresses on the gif(4) interface should not be affected no matter whether it is member of a bridge interface or not. PR: 227450 Reported by: Siva Mahadevan <me@svmhdvn.name> Reviewed by: ivy (previous version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52200 tests/sys/net/if_bridge_test.sh | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
^Triage: committed via https://reviews.freebsd.org/D52200 .
This is not yet fully fixed because although the 'sys/net/if_gif:etherip' testcase is fixed, the 'sys/net/if_gif:etherip6' is not. I am able to reproduce the failure in CURRENT HEAD as of commit e2761a8567f3. $ bricoler run freebsd-src-regression-suite --param freebsd-src:url=/usr/src --param freebsd-src:branch= --param freebsd-src-regression-suite:hypervisor=bhyve --param freebsd-src-regression-suite:memory=4096 --param freebsd-src-regression-suite:ncpus=2 --param freebsd-src-regression-suite:parallelism=1 --param freebsd-src-regression-suite:tests='sys/net/if_gif:etherip6' @zlei are you able to reproduce the failure?
(In reply to Siva Mahadevan from comment #27) Emm, IIRC all if_gif tests against current/15 run successfully. There must be something wrong.
(In reply to Zhenlei Huang from comment #28) A quick local test shows green. ``` root@:/tmp/tests # kyua test -k Kyuafile sys/net/if_gif sys/net/if_gif:4in4 -> passed [0.090s] sys/net/if_gif:4in6 -> passed [0.073s] sys/net/if_gif:6in4 -> passed [0.074s] sys/net/if_gif:6in6 -> passed [0.076s] sys/net/if_gif:etherip -> passed [0.139s] sys/net/if_gif:etherip6 -> passed [0.150s] Results file id is tmp_tests.20250904-165712-442776 # uname -na FreeBSD 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE #20 main-n280067-59ddbef26238: Thu Sep 4 22:29:56 CST 2025 zlei@:/usr/obj/usr/home/zlei/freebsd-src/amd64.amd64/sys/GENERIC amd64 ``` I'm downloading the prebuild ISO and will give it another try.
(In reply to Zhenlei Huang from comment #29) The latest snapshot is https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/15.0/FreeBSD-15.0-PRERELEASE-amd64-20250828-579bb6c2cd77-279924-disc1.iso . I created a new VM and updated the kernel to commit 59ddbef26238, which is only one commit behind your e2761a8567f3, and the tests are still green. What's your arch ? ARM64 or RISC-V ?
Created attachment 263491 [details] etherip6 failing test report I'm on amd64: FreeBSD x470 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE #5 main-n280080-a884f699e4bf: Thu Sep 4 13:58:47 EDT 2025 root@x470:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 I've attached a kyua test report in this bug.
(In reply to Siva Mahadevan from comment #31) That's weird. I've tried many times but still I can not repeat. ``` root@:/tmp/tests # kyua test -k Kyuafile sys/net/if_gif:etherip6 sys/net/if_gif:etherip6 -> passed [0.133s] Results file id is tmp_tests.20250904-191235-209935 Results saved to /root/.kyua/store/results.tmp_tests.20250904-191235-209935.db 1/1 passed (0 broken, 0 failed, 0 skipped) root@:/tmp/tests # uname FreeBSD root@:/tmp/tests # uname -a FreeBSD 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE #1 main-n280080-a884f699e4bf: Fri Sep 5 02:56:44 CST 2025 zlei@:/usr/obj/usr/home/zlei/freebsd-src/amd64.amd64/sys/GENERIC-NODEBUG amd64 ```
Here's the same failure in jenkins CI on aarch64 one day ago: https://ci.freebsd.org/view/Test/job/FreeBSD-main-aarch64-test/1758/testReport/sys.net/if_gif/etherip6/
(In reply to Siva Mahadevan from comment #33) I believe I figured out why that happens. From the console log https://ci.freebsd.org/view/Test/job/FreeBSD-main-aarch64-test/1758/consoleFull, > 06:08:58 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled On the test VM, ipfw(4) is loaded but with default_to_accept=1. Well ipfw(4) does not recognize the EtherIP protocol, then `net.inet6.ip6.fw.deny_unknown_exthdrs=1` works and those packets with EtherIP protocol are dropped, hence the test case `sys.net.if_gif.etherip6` fails. Steps to repeat: ``` # kenv net.inet.ip.fw.default_to_accept=1 net.inet.ip.fw.default_to_accept="1" # kldload ipfw # cd /usr/tests/sys/net # kyua test -k Kyuafile if_gif if_gif:4in4 -> passed [1.114s] if_gif:4in6 -> passed [1.127s] if_gif:6in4 -> passed [1.119s] if_gif:etherip -> passed [2.317s] if_gif:etherip6 -> failed: atf-check failed; see the output of the test for details [12.603s] ... ``` Fix is coming, thanks for your report !
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0418e6690e91aa6c38dd9af9da43c4c5a9dc1cd2 commit 0418e6690e91aa6c38dd9af9da43c4c5a9dc1cd2 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-16 15:58:24 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-16 15:58:24 +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 sys/netpfil/ipfw/ip_fw2.c | 7 +++++++ 1 file changed, 7 insertions(+)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b1c96e54b906d0cdea0b5a9c74cc295803dfe50e commit b1c96e54b906d0cdea0b5a9c74cc295803dfe50e Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-16 15:58:24 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-23 13:07:33 +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) sys/netpfil/ipfw/ip_fw2.c | 7 +++++++ 1 file changed, 7 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=aeb8f341ad20b5f49561fff688e8bee601b0e15a commit aeb8f341ad20b5f49561fff688e8bee601b0e15a Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-08-08 10:17:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-27 15:11:34 +0000 EtherIP: Fix passing the address family from if_bridge(4) to gif(4) Given IPPROTO_IPV4, IPPROTO_IPV6 and IPPROTO_ETHERIP have different protocol numbers, then it is perfect valid to tunnel IPv4, IPv6 and Ethernet traffic over IPv[46] by the same interface. Since gif(4) has already utilized the inbound csum_data field to carry address family, also teach if_bridge(4) to do that, rather than checking if a gif(4) interface is member of a if_bridge(4) interface. Without this fix, tunnel IPv[46] over IPv[46] will not work when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup, as the address family passed from gif_output() will be overwritten with the wrong one AF_LINK by gif_transmit(), and end up with incorrectly encapsulated packets. PR: 227450 Reviewed by: kp Tested by: meta Fixes: 8a0308722372 gif(4): Assert that gif_output() isn't called for EtherIP MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 (cherry picked from commit f4744b8acb932fbb3e48b71d31b7cd585566b668) sys/net/if_bridge.c | 6 ++++++ sys/net/if_gif.c | 10 +++------- 2 files changed, 9 insertions(+), 7 deletions(-)
A commit in branch stable/14 references this bug: 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) sys/netpfil/ipfw/ip_fw2.c | 7 +++++++ 1 file changed, 7 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5c6fae9d27dacf77c900e9b982d35a6095b22ec6 commit 5c6fae9d27dacf77c900e9b982d35a6095b22ec6 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-01 10:14:22 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-27 15:11:34 +0000 tests: bridge: Add regression test for gif(4) interface as bridge member if_bridge(4) should not prohibit adding a gif(4) interface which is assigned with IP addresses as a bridge member regardless of the setting of sysctl variable net.link.bridge.member_ifaddrs. Assigning IP addresses on the gif(4) interface should not be affected no matter whether it is member of a bridge interface or not. PR: 227450 Reported by: Siva Mahadevan <me@svmhdvn.name> Reviewed by: ivy (previous version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52200 (cherry picked from commit b944c8ff17971b1c8f61d5612eac146f5d589e87) tests/sys/net/if_bridge_test.sh | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=52dbbe3f37ffda10751c3146b9ec0e11772fd5b6 commit 52dbbe3f37ffda10751c3146b9ec0e11772fd5b6 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-01 10:14:22 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-27 15:11:35 +0000 bridge: Fix adding gif(4) interface assigned with IP addresses as bridge memeber and fix assigning IP addresses to the gif(4) interface when it is a member of a if_bridge(4) interface. When setting the sysctl net.link.bridge.member_ifaddrs to 1, if_bridge(4) can eliminate unnecessary walk of the member list to determine whether the inbound unicast packets are for us or not. Well when a gif(4) interface is member of a if_bridge(4) interface, it acts as the tunnel endpoint to tunnel Ethernet frames over IP network, aka the EtherIP protocol, so the IP addresses configured on it are independent of the if_bridge(4) interface or other if_bridge(4) members, hence the sysctl net.link.bridge.member_ifaddrs should not have any influnce over gif(4) interfaces's behavior of assigning IP addresses. PR: 227450 Reported by: Siva Mahadevan <me@svmhdvn.name> Reviewed by: ivy, #bridge MFC after: 1 week Fixes: 0a1294f6c610 bridge: allow IP addresses on members to be disabled Differential Revision: https://reviews.freebsd.org/D52200 (cherry picked from commit 9764aa1ccad08a7ec53ed9b80741b9553f3fa4e6) sys/net/if_bridge.c | 6 +++--- sys/netinet/in.c | 4 ++-- sys/netinet6/in6.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e5f01421ddbfee935546271121e6254472dcc7f5 commit e5f01421ddbfee935546271121e6254472dcc7f5 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-08-08 10:17:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-27 15:11:34 +0000 tests: gif(4): Add regression tests for setup with EtherIP Tunnel IPv[46] traffic over IPv[46] should still function when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup. PR: 227450 Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 (cherry picked from commit 04d0dc4c0c65592a21225cff43f25e0a0da64eb9) tests/sys/net/if_gif.sh | 154 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6e605ed6df40c91120f8d64924652f8565bc05f0 commit 6e605ed6df40c91120f8d64924652f8565bc05f0 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-08-08 10:17:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-10-04 16:43:20 +0000 EtherIP: Fix passing the address family from if_bridge(4) to gif(4) Given IPPROTO_IPV4, IPPROTO_IPV6 and IPPROTO_ETHERIP have different protocol numbers, then it is perfect valid to tunnel IPv4, IPv6 and Ethernet traffic over IPv[46] by the same interface. Since gif(4) has already utilized the inbound csum_data field to carry address family, also teach if_bridge(4) to do that, rather than checking if a gif(4) interface is member of a if_bridge(4) interface. Without this fix, tunnel IPv[46] over IPv[46] will not work when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup, as the address family passed from gif_output() will be overwritten with the wrong one AF_LINK by gif_transmit(), and end up with incorrectly encapsulated packets. PR: 227450 Reviewed by: kp Tested by: meta Fixes: 8a0308722372 gif(4): Assert that gif_output() isn't called for EtherIP MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 (cherry picked from commit f4744b8acb932fbb3e48b71d31b7cd585566b668) (cherry picked from commit aeb8f341ad20b5f49561fff688e8bee601b0e15a) sys/net/if_bridge.c | 6 ++++++ sys/net/if_gif.c | 10 +++------- 2 files changed, 9 insertions(+), 7 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a3fbecac6879990afd88bbe95aad84abbbe8c2c8 commit a3fbecac6879990afd88bbe95aad84abbbe8c2c8 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-08-08 10:17:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-10-04 16:43:20 +0000 tests: gif(4): Add regression tests for setup with EtherIP Tunnel IPv[46] traffic over IPv[46] should still function when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup. PR: 227450 Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 (cherry picked from commit 04d0dc4c0c65592a21225cff43f25e0a0da64eb9) (cherry picked from commit e5f01421ddbfee935546271121e6254472dcc7f5) tests/sys/net/if_gif.sh | 154 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1a9f9b4e38c370eb505554edba6041542b8ba701 commit 1a9f9b4e38c370eb505554edba6041542b8ba701 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-16 15:58:24 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-10-04 16:43:21 +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) (cherry picked from commit b4c6c3db0379a5b3d34143325805cd7e68cf3d9a) sys/netpfil/ipfw/ip_fw2.c | 7 +++++++ 1 file changed, 7 insertions(+)