As already stated in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701#c80, FreeBSD-SA-24:05 causes log entries like: "pf: ICMP error message too short (ip6)" See: https://forum.opnsense.org/index.php?topic=42632.msg211600#msg211600 In order to create the issue, use an iperf3 test over a FreeBSD machine that is configured as a router. As told before, all of these logs entries disappear after reverting the changes introduced by the SA.
Dr. Uwe Meyer-Gruhl, any specific parameters to iperf3 except target IP address? P.S. Assigning to the committer of the supposed regression.
No, the iperf3 test only creates a load high enough that this will turn up more early. Other than that, any routed TCP traffic will show such log entries sooner or later.
I see you've changed the version to 14.1-STABLE from -RELEASE; can you provide the precise version you're testing (i.e., git hash from uname -v). In particular there are a series of pf changes in stable/14 beyond the SA-24:05.pf patch and it's important to know if those changes are included or not.
"uname -v" shows FreeBSD 14.1-STABLE stable/14-n268665-4938f554469b GENERIC.
Dr. Uwe Meyer-Gruhl, can you please do some checks for me on your host? Here is what I did on my 14.1-STABLE n268665-4938f554469 GENERIC bare virtual machine: [root@stable14 ~]# pkg install python3 py311-scapy ndisc6 ... [root@stable14 ~]# kldload pf [root@stable14 ~]# kyua test -k /usr/tests/sys/netpfil/pf/Kyuafile icmp6 icmp6:repeat -> passed [4.626s] icmp6:ttl_exceeded -> passed [0.629s] icmp6:zero_id -> passed [19.268s] Results file id is usr_tests_sys_netpfil_pf.20240910-193038-760286 Results saved to /root/.kyua/store/results.usr_tests_sys_netpfil_pf.20240910-193038-760286.db 3/3 passed (0 failed) Let's check first that these three tests all pass on your host.
Also thank you for reporting this one. Before trying to replicate this issue locally, I checked the linked resources and at least one of the comments[0] mentions that they're running a virtualized OPNsense on proxmox. So maybe you could double-check that this isn't caused by the bridge issue identified in bug #281395 (MLD snooping doing something to icmp6). So that would basically mean: - Turn MLD snooping back on - Enable pf on your test host: (echo "set debug misc"; echo pass) >/etc/pf.conf service pf onestart - Turn on some traffic (iperf3, like you mentioned) - Check /var/log/messages if it complains about short ICMP packages - If yes, turn off MLD snooping and see if it continues You might need to configure your instance as a gateway though: sysctl net.inet.ip.forwarding=1 sysctl net.inet6.ip6.forwarding=1 I *think* that this config should be enough to have pf debug output end up in /var/log. If it turns out this is not caused by proxmox's default bridge setting, I'll try to dig into it a bit more and see if I can reproduce it in one of my vms. [0] https://forum.opnsense.org/index.php?topic=42632.msg211497#msg211497
I so far haven't been able to trigger any of the reported messages running iperf3 through a stable/14 IPv6 router. (In reply to Michael Gmelin from comment #6) With MLD snooping enabled, I see a couple of 'pf: dropping packet with ip options' messages.