Re: Allow libpcap to read files with some additional link-layer type values

Thanks. (By the way, when testing this on a 7.3 virtual machine, I saw the problem that I suspect this change to sys/net/if_loop.c: revision 1.97 date: 2023/07/21 22:24:41; author: bluhm; state: Exp; lines: +10 -1; commitid: zlUMTFeyu4Tpey4p; Do not dump corrupted

Allow libpcap to read files with some additional link-layer type values

>Synopsis: Allow libpcap to read files with some additional link-layer >type values >Category: library >Environment: System : OpenBSD 7.3 Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023

Some libpcap function arguments and return values should be const pointers

Some functions in libpcap were changed some time ago to take const pointer arguments rather than non-const pointer arguments and to return a const pointer value: the prefix argument to pcap_perror(); the return value of pcap_strerror(); the filter expression argument

Re: The second argument of ether_ntohost() should be "const struct ether_addr *"

On Aug 7, 2016, at 7:07 PM, Philip Guenther <pguent...@proofpoint.com> wrote: > On Sun, 7 Aug 2016, Guy Harris wrote: > ... >> --- lib/libc/net/ethers.c14 Sep 2015 11:01:47 - 1.24 >> +++ lib/libc/net/ethers.c8 Aug 2016 01:28:39 - &

The second argument of ether_ntohost() should be "const struct ether_addr *"

>Synopsis: The second argument of ether_ntohost() should be "const struct >ether_addr *" >Category: >Environment: System : OpenBSD 5.9 Details : OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016

BPF(4) man page's list of permitted ioctl on a locked BPF descriptor doesn't include BIOCGDIRFILT

The list of permitted ioctls in the description of BIOCLOCK in BPF(4) is incomplete - BIOCGDIRFILT is also allowed, according to sys/net/bpf.c. Here's a patch. Index: share/man/man4/bpf.4 === RCS file:

BPF(4) man page doesn't document BIOCGQUEUE or BIOCSQUEUE

The BPF(4) man page appears to document all the ioctls in sys/net/bpf.h except for BIOCGQUEUE and BIOCSQUEUE.

bpf_filter()'s bounds checks can allow out-of-bounds loads due to overflow on 32-bit platforms

If you do sudo tcpdump -i {interface} -O 'link[0xFFFC:4] != 0xf00ba4f' the generated code is (000) ld #0xfffc (001) st M[0] (002) ldx M[0] (003) ld [x + 0] (004) st M[1] (005) ld #0xf00ba4f

Re: bpf_filter()'s bounds checks can allow out-of-bounds loads due to overflow on 32-bit platforms

(BTW, thanks to Andy Wingo for pointing this out in a bug report for libpcap; the same problem exists in userland.)

Re: bpf_filter()'s bounds checks can allow out-of-bounds loads due to overflow on 32-bit platforms

On Aug 31, 2014, at 1:40 AM, Brad Smith b...@comstyle.com wrote: You have to send any diffs as inline text. OK: Index: bpf_filter.c === RCS file: /cvs/src/sys/net/bpf_filter.c,v retrieving revision 1.24 diff -u -r1.24

p-cc can go negative in libpcap

In pcap_read_bpf(), ep is set based on the return value of read(), but read() from a BPF device doesn't necessarily return a value that's a multiple of the alignment value for BPF_WORDALIGN(). However, whenever we increment bp, we round up the increment value by a value rounded up by

bpf_validate() uses BPF_RVAL() when it should use BPF_SRC()

In bpf_validate, when it checks whether the divisor in a BPF_DIV instruction is a constant 0, it does case BPF_DIV: /* * Check for constant division by 0. */