Thanks.
(By the way, when testing this on a 7.3 virtual machine, I saw the problem that
I suspect this change to sys/net/if_loop.c:
revision 1.97
date: 2023/07/21 22:24:41; author: bluhm; state: Exp; lines: +10 -1;
commitid: zlUMTFeyu4Tpey4p;
Do not dump corrupted packets on loopback bpf.
lo(4) used to dump to bpf only for output. It seems that when
if_bpf_mtap() was introduced, this changed and lo(4) dumps an
additional truncated packet. The default bpf_mtap_ether() is not
suitable for lo(4).
Install a dummy lo_bpf_mtap() to suppress bpf on input.
OK mvs@
fixes - the captures I did on lo0 had two copies of each packet, the first of
which has no DLT_LOOP header, the second of which does. That change should
perhaps be backported to the 7.x branch if a 7.4 release is likely to happen.
Given that a link-layer type value of 12 means DLT_RAW on macOS and on BSDs
other then OpenBSD, reading the capture file with tcpdump on those OSes means
that the *first* packet is correctly dissected and the *second* packet is
reported as damaged; DLT_ collisions such as that are the reason why I
introduced the notion of LINKTYPE_ values, to be used in pcap and now pcapng
files, and changed libpcap so that it writes DLT_RAW captures with a link-layer
type value of 101 and, when reading captures, maps a link-layer type value of
101 in the file to DLT_RAW.)
