On 2023/08/02 13:12, Guy Harris wrote: > 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.
Thanks for the confirmation on that. That fix will be in 7.4; other than post-release patch branches (7.2-stable, 7.3-stable, etc; mainly used for fairly serious or widely seen issues) we just have a single repo branch and version numbering is a simple +0.1 each time, nothing special about an x.0 release. > 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.)
