Bug 198211 - tcpreplay not working for lo0
Summary: tcpreplay not working for lo0
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexander V. Chernikov
Depends on:
Reported: 2015-03-02 22:21 UTC by holger
Modified: 2021-06-14 02:43 UTC (History)
4 users (show)

See Also:

Check for pseudo_AF_HDRCMPLT to allow tcpreplay on loopback (448 bytes, patch)
2015-03-02 22:21 UTC, holger
holger: maintainer-approval?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description holger 2015-03-02 22:21:34 UTC
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.


* 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

* Replayed packets arriving on the loopback device

* $ dmesg
looutput: af=31 unexpected
looutput: af=31 unexpected


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));
                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.
Comment 1 holger 2015-03-03 08:55:26 UTC
This appears broken since 1999 when pseudo_AF_HDRCMPLT was introduced and it might apply to if_tun.c as well.
Comment 2 Gleb Smirnoff freebsd_committer 2015-03-05 05:47:53 UTC
Mr. BPF expert, can you please look at this? :)
Comment 3 Patrick Kelsey freebsd_committer 2015-07-12 16:40:11 UTC
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.
Comment 4 Patrick Kelsey freebsd_committer 2015-07-15 16:58:29 UTC
This has been merged to stable/10 and so will appear in 10.2-BETA2 and beyond.
Comment 5 Kurt Jaeger freebsd_committer 2016-02-07 17:59:21 UTC
Should be fixed now in 10 and beyond.
Comment 6 Michael F 2021-06-14 02:43:42 UTC
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.