bpfilter

Summary Add as an exclusive packet logging mode. The implementation introduces a dedicated ELF stub that emits compact records containing source and destination addresses, source and destination ports, and the transport protocol. It supports complete IPv4/IPv6 TCP/UDP tuples while preserving the existing fixed-size reservation and ring-buffer capacity. Unsupported packets do not emit a tuple record or fall back to raw-header logging. Their counters, marks, verdicts, and normal rule execution remain unchanged. Related issue Fixes #568 Testing Added coverage for: valid syntax, with and without rejection of combinations with packet-layer options rejection on option conversion and rule serialization IPv4 and IPv6 with TCP and UDP tuple addresses, ports, protocols, rule ID, and verdict no tuple record for ICMP and non-IP packets counters and verdicts when tuple logging is skipped unsupported packets not consuming the rate-limit interval unchanged raw-header logging behaviour Debug build with sanitizers and coverage enabled: Release build: Additional verification: fixstyle test debug ASan/UBSan execution coverage generation — 84.4% lines and 95.5% functions final lint, IWYU, checkstyle, and diff whitespace checks Notes for the reviewer is mutually exclusive with , , and . Tuple records are emitted only for IPv4/IPv6 packets using TCP or UDP, following the eligibility behaviour discussed in #568. The eligibility check happens before rate-limit bookkeeping, so an unsupported packet does not consume the rule's interval. is intentionally unsupported for this mode. Existing raw packet logging and socket-address logging remain unchanged. The new log type and ELF-stub identifiers are appended so existing identifier values remain stable. AI disclosure I used AI for codebase exploration, understanding the existing logging and BPF code-generation paths, design iteration, parts of the implementation and tests, verification, review, and wording of this PR. I reviewed the resulting design and test evidence and remain responsible for the submitted changes. Checklist [x] I understand every line in this PR and can explain why it is correct [x] I built the project and ran the tests covering this change [x] passes and the code follows the style guide [x] Commits are formatted as [x] I have disclosed any AI usage above

Summary add a typed unpack helper while preserving the wire format reject packed values above and update the affected unpack call sites add focused unit coverage for normal and overflowing values Fixes #548

Summary Implements port ranges in set elements (#562). now recognises range syntax () in a set element's components and expands it into individual set elements. For example: produces a set containing (14 elements). Range detection reuses the parsing that already backs the standalone matcher operator — a component is treated as a range only when the token contains a and the component's matcher type registers ops. This scopes the feature to the matcher types that already support ranges (ports today) without hardcoding anything port-specific, and non-range / multi-component parsing is unchanged. Behaviour Each value in is expanded into its own element and inserted into the set's hashset, deduplicated like any other element. Expanded values are re-parsed through the existing single-value () path, so their in-memory representation is byte-identical to an element written as a plain value. Range bounds are validated by the existing : both bounds must be valid decimal ports , and . , , and are rejected. Scope / limitations A couple of things are intentionally left out to keep this a minimal, focused change — flagging them for maintainer input: Printing is unchanged. Expanded ranges are printed element-by-element, not re-factored back into a range. This is the open question raised in #562; happy to add range factorization on in a follow-up if that's the preferred direction. One ranged component per element. A set element with more than one ranged component (e.g. ) returns rather than performing a Cartesian expansion. This avoids surprising blow-up in element count; can revisit if Cartesian expansion is wanted. A note on element separators The issue's example is written as , but bpfilter separates set elements with and components within an element with (e.g. vs ). So the range form is . This PR does not change the grammar, so the comma-separated form from the issue's example still parses as multiple components. If treating as an element separator for single-component sets is desired, that's a separate grammar change and I'm glad to take it on separately. Tests Added unit tests in : single-component range expansion ( → 14 elements) range boundaries (, degenerate ) invalid ranges (, , ) a range in one component of a two-component key ( → 3) ranges in both components of an element (rejected) All tests pass (28/28).