Date: Fri, 19 Dec 2025 21:22:31 -0800 From: Kevin Oberman <rkoberman@gmail.com> To: FreeBSD Current <freebsd-current@freebsd.org> Subject: Panic during boot on assertion in ipfw strtup Message-ID: <CAN6yY1uY3LEX4jJre0EqxyvziU6NLPWNwqHEXADZ19EsuWWdrA@mail.gmail.com>
index | next in thread | raw e-mail
[-- Attachment #1 --] As of current as of Dec 16 21:22:39 UTC 2025 m system panics when starting ipfw. was not happening on 2f29d0f3e6d2 on Saturday Dec 13. I tried to get a dump, but the system did an immediate reboot when I tried 'panic'. Here is the panic output: Dec 19 07:12:30 ptavv kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled Dec 19 07:12:30 ptavv kernel: panic: Assertion tap->rule == rule failed at /usr/src/sys/netpfil/ipfw/ip_fw_bpf.c:86 Dec 19 07:12:30 ptavv kernel: cpuid = 11 Dec 19 07:12:30 ptavv kernel: time = 1766124707 Dec 19 07:12:30 ptavv kernel: KDB: stack backtrace: Dec 19 07:12:30 ptavv kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00eb3d3900 Dec 19 07:12:30 ptavv kernel: vpanic() at vpanic+0x136/frame 0xfffffe00eb3d3a30 Dec 19 07:12:30 ptavv kernel: panic() at panic+0x43/frame 0xfffffe00eb3d3a90 Dec 19 07:12:30 ptavv kernel: ipfw_tap_alloc() at ipfw_tap_alloc+0x2f7/frame 0xfffffe00eb3d3ac0 Dec 19 07:12:30 ptavv kernel: add_rules() at add_rules+0x137/frame 0xfffffe00eb3d3b30 Dec 19 07:12:30 ptavv kernel: ipfw_ctl3() at ipfw_ctl3+0x365/frame 0xfffffe00eb3d3ce0 Dec 19 07:12:30 ptavv kernel: sogetopt() at sogetopt+0x15a/frame 0xfffffe00eb3d3d40 Dec 19 07:12:30 ptavv kernel: kern_getsockopt() at kern_getsockopt+0xb5/frame 0xfffffe00eb3d3dd0 Dec 19 07:12:30 ptavv kernel: sys_getsockopt() at sys_getsockopt+0x52/frame 0xfffffe00eb3d3e00 Dec 19 07:12:30 ptavv kernel: amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe00eb3d3f30 Dec 19 07:12:30 ptavv kernel: fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00eb3d3f30 Dec 19 07:12:30 ptavv kernel: --- syscall (118, FreeBSD ELF64, getsockopt), rip = 0x1d91f7dd13da, rsp = 0x1d91f513d1a8$ Dec 19 07:12:30 ptavv kernel: KDB: enter: panic I saw no commits to netpfilt that look like candidates during hte three day window, so I suspect that it is triggered by some other part of the ipfw start. I can do a bisect if nothing else seems useful. I'm afraid that I don't have a hash for the one that is the initial failure on Dec 16, so I'll try to track down something close. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 [-- Attachment #2 --] <div dir="ltr"><div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">As of current as of Dec 16 21:22:39 UTC 2025 m system panics when starting ipfw. was not happening on 2f29d0f3e6d2 on Saturday Dec 13. I tried to get a dump, but the system did an immediate reboot when I tried 'panic'. Here is the panic output:</div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">Dec 19 07:12:30 ptavv kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled<br>Dec 19 07:12:30 ptavv kernel: panic: Assertion tap->rule == rule failed at /usr/src/sys/netpfil/ipfw/ip_fw_bpf.c:86<br>Dec 19 07:12:30 ptavv kernel: cpuid = 11<br>Dec 19 07:12:30 ptavv kernel: time = 1766124707<br>Dec 19 07:12:30 ptavv kernel: KDB: stack backtrace:<br>Dec 19 07:12:30 ptavv kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00eb3d3900<br>Dec 19 07:12:30 ptavv kernel: vpanic() at vpanic+0x136/frame 0xfffffe00eb3d3a30<br>Dec 19 07:12:30 ptavv kernel: panic() at panic+0x43/frame 0xfffffe00eb3d3a90<br>Dec 19 07:12:30 ptavv kernel: ipfw_tap_alloc() at ipfw_tap_alloc+0x2f7/frame 0xfffffe00eb3d3ac0<br>Dec 19 07:12:30 ptavv kernel: add_rules() at add_rules+0x137/frame 0xfffffe00eb3d3b30<br>Dec 19 07:12:30 ptavv kernel: ipfw_ctl3() at ipfw_ctl3+0x365/frame 0xfffffe00eb3d3ce0<br>Dec 19 07:12:30 ptavv kernel: sogetopt() at sogetopt+0x15a/frame 0xfffffe00eb3d3d40<br>Dec 19 07:12:30 ptavv kernel: kern_getsockopt() at kern_getsockopt+0xb5/frame 0xfffffe00eb3d3dd0<br>Dec 19 07:12:30 ptavv kernel: sys_getsockopt() at sys_getsockopt+0x52/frame 0xfffffe00eb3d3e00<br>Dec 19 07:12:30 ptavv kernel: amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe00eb3d3f30<br>Dec 19 07:12:30 ptavv kernel: fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00eb3d3f30<br>Dec 19 07:12:30 ptavv kernel: --- syscall (118, FreeBSD ELF64, getsockopt), rip = 0x1d91f7dd13da, rsp = 0x1d91f513d1a8$<br>Dec 19 07:12:30 ptavv kernel: KDB: enter: panic<br><br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">I saw no commits to netpfilt that look like candidates during hte three day window, so I suspect that it is triggered by some other part of the ipfw start.</div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">I can do a bisect if nothing else seems useful. I'm afraid that I don't have a hash for the one that is the initial failure on Dec 16, so I'll try to track down something close.</div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Kevin Oberman, Part time kid herder and retired Network Engineer<br>E-mail: <a href="mailto:rkoberman@gmail.com" target="_blank">rkoberman@gmail.com</a><br></div><div>PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683</div></div></div></div></div></div></div></div></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1uY3LEX4jJre0EqxyvziU6NLPWNwqHEXADZ19EsuWWdrA>