NetBSD Problem Report #56430

From www@netbsd.org  Fri Oct  1 16:16:41 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 5396A1A921F
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  1 Oct 2021 16:16:41 +0000 (UTC)
Message-Id: <20211001161639.B9D151A9239@mollari.NetBSD.org>
Date: Fri,  1 Oct 2021 16:16:39 +0000 (UTC)
From: david@gutteridge.ca
Reply-To: david@gutteridge.ca
To: gnats-bugs@NetBSD.org
Subject: lo(4) and tun(4) devices do not support "header complete" packets via bpf(4)
X-Send-Pr-Version: www-1.0

>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:    gutteridge
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 01 16:20:00 +0000 2021
>Closed-Date:    
>Last-Modified:  Fri Feb 24 16:13:57 +0000 2023
>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:/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.)

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->gutteridge
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Thu, 09 Feb 2023 01:52:54 +0000
Responsible-Changed-Why:
Take. Half of this is fixed with revisions 1.249 and 1.251 to bpf.c.

State-Changed-From-To: open->pending-pullups
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Sun, 19 Feb 2023 02:25:54 +0000
State-Changed-Why:
netbsd-10 pullup #103.

State-Changed-From-To: pending-pullups->open
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Fri, 24 Feb 2023 16:13:57 +0000
State-Changed-Why:
The tun(4) aspect still remains to be dealt with.

>Unformatted:

Home	PR Database Search