WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/lib/libpcap?h=master 2021-01-20T12:37:26Z 2021-01-20T12:37:26Z sthen sthen@openbsd.org 2021-01-20T12:37:26Z urn:sha1:6ea1460922840db4dd799430eb5154b2905a7dcc 2021-01-18T09:26:35Z sthen sthen@openbsd.org 2021-01-18T09:26:35Z urn:sha1:ff78d6edd4ee27e44eebf250095a6ef702022eff libpcap, ok dlg@ https://github.com/the-tcpdump-group/libpcap/commit/74b2de364f3443fc2414d0160b0b942f347c6fd4 https://github.com/the-tcpdump-group/libpcap/commit/117cb5eb2eb4fe212d3851f1205bb0b8f57873c6 2020-09-12T09:27:22Z kn kn@openbsd.org 2020-09-12T09:27:22Z urn:sha1:fe3e795b55c6e630825f5c45b44a1e13b74085e3 Fixing filters on DLT_LOOP revealed that we treat DLT_NULL, DLT_ENC and DLT_LOOP the same way even though DLT_LOOP stores the AF value in network not byte order like the rest. This amends the missing conversion which ought to land with the recent commit exposing the byte order mismatch: revision 1.53 date: 2020/07/21 22:44:55; author: dlg; state: Exp; lines: +2 -2; DLT_LOOP does have a link header, so tell pcap-filter so it can use it. ... debugged with and ok kn@ Discussed with bluhm who reported src/regress/sys/netinet6/rip6cksum/ failing on i386 after above commit. The comment in this commit is taken from libpcap upstream as is modulo additional file-save related byte-order handling which we don't seem to do. OK bluhm 2020-08-03T03:47:12Z dlg dlg@openbsd.org 2020-08-03T03:47:12Z urn:sha1:6b2850a6aefad9f1b3eebff6c5ecf79c204e7a7e pointed out by tb@, who also provided the diff. maybe someone should/could add a Symbols.list here? ok tb@ deraadt@ 2020-08-03T03:40:02Z dlg dlg@openbsd.org 2020-08-03T03:40:02Z urn:sha1:2cba36b56b1c3fd3bbf6a036e01b16253c887425 the use of the sample keyword matches similar config in other products. NUM can be a number between 2 and 1048576, and is used to divide 0x100000000 into a threshold that is then compared against a randomly generated number produced by a load of BPF_RND. having sampling as part of the grammar means you can write things like "icmp or sample 128". this lets you capture all icmp traffic and a sample of the rest of the traffic. ok jmatthew@ kn@ tb@ 2020-08-03T03:29:58Z dlg dlg@openbsd.org 2020-08-03T03:29:58Z urn:sha1:a8e9f808963388af56d210337c14dd50c91412d5 this adds "rnd" and "random" as keywords in the grammar, and handles them as an arithmetic operator. the decoder recognises the load, so tcpdump can print it as 'ld #random'. most of the handling is copied from the "len"/"length" keywoard handling that generates and decodes a load of the actual wire length of the packet. ok jmatthew@ tb@ kn@ 2020-07-21T22:44:55Z dlg dlg@openbsd.org 2020-07-21T22:44:55Z urn:sha1:0918526a4b077332bde6e58017c9a114d03110f9 matthieu@ reported that asking tcpdump to look at ip or ip6 traffic on a wg(4) interface caused all packets to be captured. this is because pcap assumes that if your link type doesn't have a link header then it is always ip or ip6 (which is weird anyway) and captures everything. there was already code to generate a filter for the DLT_LOOP link header, it was just bypassed cos earlier code said that there wasn't one. debugged with and ok kn@ 2020-05-29T05:51:19Z jmc jmc@openbsd.org 2020-05-29T05:51:19Z urn:sha1:bcdfdb4ab1703478281fdce7a7095a2d333a4ca9 ok djm 2020-05-27T04:24:01Z dlg dlg@openbsd.org 2020-05-27T04:24:01Z urn:sha1:c5e4be465a16a5443f18a26b06c2477e1d4700f7 djm pulled support in for pcap_breakloop on the bpf side of things, this makes it work when reading files too. from Caspar Schutijser lteo@ seems keen ok djm@ 2019-12-17T15:22:48Z jca jca@openbsd.org 2019-12-17T15:22:48Z urn:sha1:5d69de98a728e4b6e9bda9d21514c412871a38c6