Created attachment 153698 [details] Check for pseudo_AF_HDRCMPLT to allow tcpreplay on loopback Capturing a pcap file for loopback/null encapsulation and then replaying with tcpreplay doesn't work. Reproduce: * Capture a trace on lo0 e.g. tcpdump -i lo0 -s 0 -n -w loopback.pcap * echo "bla" | nc localhost 1234 * Stop the capture. It has two packages.. the UDP message and ICMP * Install tcpreplay with pkg install tcpreplay * Monitor loopback for traffic tcpdump -i lo0 -s 0 -n -X * Replay with tcpreplay --intf1=lo0 loopback.pcap Expectation: * Replayed packets arriving on the loopback device Outcome: * $ dmesg looutput: af=31 unexpected looutput: af=31 unexpected Reason: tcpreplay is using libpcap for replay and is setting the complete header field open("/dev/bpf0",O_RDWR,00) = 3 (0x3) ioctl(3,BIOCVERSION,0xbfbfe7c8) = 0 (0x0) ioctl(3,BIOCSETIF,0xbfbfe7d0) = 0 (0x0) ioctl(3,BIOCGDLT,0xbfbfe7c4) = 0 (0x0) ioctl(3,BIOCSHDRCMPLT,0xbfbfe7c0) = 0 (0x0) ioctl(3,BIOCGDLT,0xbfbfe808) = 0 (0x0) This means that in bpf.c:bpfwrite if (d->bd_hdrcmplt) dst.sa_family = pseudo_AF_HDRCMPLT; will be executed but in if_loop.c:looutput /* BPF writes need to be handled specially. */ if (dst->sa_family == AF_UNSPEC) bcopy(dst->sa_data, &af, sizeof(af)); else af = dst->sa_family; will be checked. This means that the local variable "af" will contain pseudo_AF_HDRCMPLT which is not handled in the switch. Proposal. Change the check from AF_UNSPEC to pseudo_AF_HDRCMPLT or at least check for pseudo_AF_HDRCMPLT as well.
This appears broken since 1999 when pseudo_AF_HDRCMPLT was introduced and it might apply to if_tun.c as well.
Mr. BPF expert, can you please look at this? :)
It turns out I recently fixed this in head in r285190 in exactly the same way as the patch attached here (without searching the bug database first - oops!). MFC to stable/10 is still pending. I did not look into the if_tun question raised in Comment 1, so that still remains.
This has been merged to stable/10 and so will appear in 10.2-BETA2 and beyond.
Should be fixed now in 10 and beyond.
FYI: I don't believe this was fixed for if_tun devices (per Comment #1 and Comment #3) as of FreeBSD 13-RELEASE. I have opened Bug #256587 about this issue for if_tun devices.