[tcpdump-workers] NetBSD CI breakage

Guy Harris gharris at sonic.net
Thu Jul 14 02:16:18 EDT 2022


On Jul 10, 2022, at 2:48 PM, Denis Ovsienko via tcpdump-workers <tcpdump-workers at lists.tcpdump.org> wrote:

> The last CI build of the libpcap-1.10 branch failed on netbsd-aarch64
> because the latter now uses GCC 12.  Commit 4e7f6e8 makes a lazy fix
> for that in the master branch; if a more sophisticated solution is not
> required,

I changed it to a slightly different fix.

The problem was that, on platforms without a cloning BPF device, the BPF device open code iterates over BPF device names, and the loop index was a signed integer, so, in theory, if you have 2^31 BPF devices, from /dev/bpf0 to /dev/bpf2147483647 open, the loop index will go from 2147483647 to -2147483648, and, while 2147483647 requires 10 characters, -2147483648 requires 11.  Thus, the length of the buffer had to be increased.

I changed the index to an unsigned integer, so it goes from 0 to 4294967295, all of which require 10 characters.

On most OS versions without a cloning BPF device, you're unlikely to have 2^32 BPF devices (almost certainly not on an ILP32 platform, for obvious reasons!), or even 2^31 BPF devices, so, in practice, this won't be a problem.

The only OS I know of that 1) has no cloning BPF device and 2) auto-creates BPF devices if you try to open one that's past the maximum unit number (it's named after a British naturalist and evolutionist whose last name is not "Huxley" :-)).  It uses "bpf%d" to generate the device names, so it could, in principle, create a device named /dev/bpf-2147483648, but the default upper limit on the number of BPF devices is 256, so you'd have to sysctl it up to a value above 2^31 (the sysctl value is unsigned, so you can do it; that also means that "bpf%d" should be "bpf%u", so it's time to file a Radar^WFeedback on that).

> a simple cherry-pick into libpcap-1.10 should be sufficient
> to pass CI again.

I've backported a bunch of changes to 1.10, including your change and mine for that; the netbsd-aarch64 build now seems to be working for libpcap-1.10.

(Or should that be netbsd-a64, or netbsd-arm64?  Thanks, Arm, for making "architecture" names so complicated....)


More information about the tcpdump-workers mailing list