kern/56430: lo(4) and tun(4) devices do not support "header complete" packets via bpf(4)

[david%gutteridge.ca@localhost]

>Number:         56430
>Category:       kern
>Synopsis:       lo(4) and tun(4) devices do not support "header complete" packets via bpf(4)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 01 16:20:00 +0000 2021
>Originator:     David H. Gutteridge
>Release:        -current
>Organization:
TNF
>Environment:
NetBSD arcusxvi.nonus-porta.net 9.99.89 NetBSD 9.99.89 (GENERIC) #23: Wed Sep 29 08:48:19 EDT 2021  disciple%arcusxvi.nonus-porta.net@localhost:/home/disciple/netbsd-current/src/sys/arch/amd64/compile/obj/GENERIC amd64
>Description:
Writing packets to an lo(4) or tun(4) device via bpf(4) isn't possible
using means that set "header complete", such as net/tcpreplay or
net/scapy from pkgsrc, as the resulting address family associated by
bpf (pseudo_AF_HDRCMPLT) isn't recognized/accepted by those devices.

An example reproducer with a loopback device and tcpreplay:

shell#1>tcpdump -i lo0 -n -w loopback.pcap
shell#2>echo "test" | nc localhost 1234
(Then stop tcpdump capture in shell#1.)
shell#1>tcpdump -i lo0 -n -X
(Install net/tcpreplay from pkgsrc.)
shell#2>tcpreplay --intf1=lo0 loopback.pcap

In shell#2:
Warning: Unable to process unsupported DLT type: BSD loopback (0x0)
Warning: Unable to send packet: Error with bpf send() [1]:
Address family not supported by protocol family (errno = 47)

In dmesg:
[ 77234.342681] lo0: can't handle af30

I haven't tested a tun(4), but code inspection indicates it shares this
issue. if_tun.c does have handling for AF_UNSPEC, which if_loop.c does
not, but doesn't handle pseudo_AF_HDRCMPLT, either. (I'm not sure if
addressing this in if_tun.c is as simple as adding pseudo_AF_HDRCMPLT
to the same switch block as AF_UNSPEC.)

I compared with other BSDs, but their code significantly differs.
FreeBSD added a specific fix to address this issue in their if_loop.c
back in 2015, but simply following their approach doesn't work here.
FreeBSD's if_tun.c still does not have handling for this issue, but
there is a recent PR open about it with them. (Apparently a tunnel
device in macOS does support this capability, going by comments in the
scapy source code.)

(Now, continuing with the example reproducer, should we get lo(4)
accepting these packets, as I have with a kludgy patch I'm testing
with, tcpreplay will also still complain "Warning: Unable to process
unsupported DLT type: BSD loopback (0x0)" when we get to its
flows.c:flow_decode() function, but that's another matter.)

(A separate issue that may be relevant if broader code changes are
considered: there is another PR that discusses related limitations
with other types: PR 34907.)
>How-To-Repeat:
(As above.)
>Fix:
(Analysis incomplete at this point.)