Panic during boot on assertion in ipfw strtup
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 20 Dec 2025 05:22:31 UTC
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