Re: pkg/55446 (scapy function send() does not work)

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

The following reply was made to PR pkg/55446; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/55446 (scapy function send() does not work)
Date: Fri, 01 Oct 2021 12:33:36 -0400

 Having looked at this a bit more (spurred by a Scapy commit which
 improved things at their end), it seems neither tun nor lo in NetBSD
 will accept packets Scapy outputs via bpf. I tested using lo (I don't
 have a tun setup to work with) and see one problem is that it rejects
 the address family type that bpf associates with the packets. That is,
 they aren't AF_INET or AF_INET6, they end up as pseudo_AF_HDRCMPLT
 type, which gets rejected. There is a similar approach in the tun code,
 though it's a little more generous (it tries to also work with
 AF_UNSPEC), so there, too, packets from Scapy would be rejected.
 FreeBSD had the same approach in its lo until about six years ago, when
 it was fixed. Evidently, FreeBSD's tun still won't work with Scapy
 either (according to the recent notes in the Scapy pull request),
 though Darwin's utun now will.
 
 I think these are kernel bugs, so I've filed a separate PR (kern/56430)
 with these specifics, and will suspend this PR. (There could still be
 other things that need addressing upstream with Scapy.)
 
 Separately, you were using i386, which I found had an unrelated issue
 in Scapy code. It was assuming universal 64-bit time offsets when
 evaluating packet headers, when it should be 32 bits for those kinds of
 architectures. I've fixed this in pkgsrc, but haven't had time to
 really test it. (This, like the other item, was really helped by
 FreeBSD people looking at equivalent problems at their end.)
 
 Dave