pflogd failing to capture a log record

Jacob Leifman <[email protected]>
Newsgroups gmane.os.openbsd.tech
Message-ID <[email protected]>
While trying to debug what I believe is an authpf timing issue, I have 
come across an apparent bug in pflogd.

The system is a pretty vanilla OpenBSD 7.9 (STABLE) firewall with all 
three published errata applied via syspatch.

The following live packet capture:

root@mystic:/var/log:215# tcpdump -netttvvi pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Jul 02 14:35:32.703508 rule 35/(match) [uid 0, pid 46839] pass out on 
em1: 192.168.223.153.13445 > 192.168.223.154.3389: S 
4095823693:4095823693(0) win 16384 <mss 
1460,nop,nop,sackOK,nop,wscale6,nop,nop,timestamp 1452754311[|tcp]> (DF) 
(ttl 64, id 36919, len 64, bad ip cksum 14! -> 69fb)

did not have a corresponding record in the stored pflog file; however, 
there is the following entry in /var/log/daemon that matches up time-wise:

Jul  2 14:35:33 mystic pflogd[77507]: invalid size 180 (160/256), packet 
dropped

The rule referenced in live capture is:

@35 pass out log on mystic all flags S/SA tagged ALLOW

where 'mystic' is the unique group name of the em1 interface:

em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         index 2 priority 0 llprio 3
         groups: mystic
         media: Ethernet autoselect (1000baseT full-duplex,master)
         status: active
         inet 192.168.223.153 netmask 0xfffffffc broadcast 192.168.223.155

This issue is consistently reproducible on my system. What additional 
information do I need to provide to help debug this issue further?

Thank you,

-Jacob.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.