Duplicate of #348: Mac userspace packet filter (D340) #351

New issue

Closed

opened 2026-11-04 18:37:14 +00:00 by kayg · 4 comments

kayg commented

2026-11-04 18:37:14 +00:00

Owner

Objective

Implement a fail-closed inbound packet filter on the macOS userspace dataplane using the compiled access rules already enforced on Linux.

Acceptance

Match protocol, destination port, and source peer after decryption and before TUN delivery; apply policy to ICMP.
Deny when rules are missing or stale, atomically swap updates, and allow bounded per-peer connection return state.
Keep mesh status aligned with the active filter.
Add red-first tests for rule matching and bounded connection tracking.
Measure Mac throughput and p99 latency with and without the filter.
Prove allowed and denied ports, coordinator denial, live rule update, and return traffic on the real Mac VM with a Linux peer.

Plan (estimate: 6 hours)

Read D228/D235/D336/D337/D340, issue #265 and J162 review; trace Linux enforcement and Mac receive/TUN path.
Add failing rule-match and bounded connection-table tests, then implement the smallest filter and atomic policy publication.
Run focused checks and compare Mac throughput/p99 latency; run all real-Mac cases under the required VM lock.
Run quick, then fast on the less-queued eligible VM; commit and push each logical change, attach evidence, and report the final SHA.

No merge or deployment.

## Objective Implement a fail-closed inbound packet filter on the macOS userspace dataplane using the compiled access rules already enforced on Linux. ## Acceptance - Match protocol, destination port, and source peer after decryption and before TUN delivery; apply policy to ICMP. - Deny when rules are missing or stale, atomically swap updates, and allow bounded per-peer connection return state. - Keep mesh status aligned with the active filter. - Add red-first tests for rule matching and bounded connection tracking. - Measure Mac throughput and p99 latency with and without the filter. - Prove allowed and denied ports, coordinator denial, live rule update, and return traffic on the real Mac VM with a Linux peer. ## Plan (estimate: 6 hours) 1. Read D228/D235/D336/D337/D340, issue #265 and J162 review; trace Linux enforcement and Mac receive/TUN path. 2. Add failing rule-match and bounded connection-table tests, then implement the smallest filter and atomic policy publication. 3. Run focused checks and compare Mac throughput/p99 latency; run all real-Mac cases under the required VM lock. 4. Run quick, then fast on the less-queued eligible VM; commit and push each logical change, attach evidence, and report the final SHA. No merge or deployment.

kayg commented

2026-11-04 18:39:48 +00:00

Author

Owner

Started on branch macos-filter-j197, based on origin/dev at 600ae5eb1d. Existing pushed WIP is fd097f932; one local draft change remains in crates/plugins/mesh/src/packet_filter.rs. I checked both Linux build-slot queues and compute01 processes: no J197 quick run is queued or running now. I will inspect the draft and required design/code context, then continue from the existing worktree. Plan and 6-hour estimate are in the issue body.

Started on branch macos-filter-j197, based on origin/dev at 600ae5eb1d45f7ccd62374ca13021786a701d234. Existing pushed WIP is fd097f932; one local draft change remains in crates/plugins/mesh/src/packet_filter.rs. I checked both Linux build-slot queues and compute01 processes: no J197 quick run is queued or running now. I will inspect the draft and required design/code context, then continue from the existing worktree. Plan and 6-hour estimate are in the issue body.

kayg commented

2026-11-04 18:52:25 +00:00

Author

Owner

Code inspection findings: J162 F1 is still present in the Mac path: macos_node.rs keeps the coordinator in installed_peers regardless of inbound policy (lines 456-461), and main.rs reports enforcement=unavailable with text saying the server reaches every port (lines 427-443). Linux applies each peer inbound/outbound policy in firewall.rs and iptables.rs using conntrack state; the new packet_filter module is not wired into macos_node yet (the WIP commit touches only lib.rs and packet_filter.rs). The unstaged duplicate-flow regression also targets a concrete table issue: insert_flow inserts before checking for an existing key, so a duplicate can replace the admitted entry. I am verifying the red case before changing it.

kayg changed title from ~~Mac userspace packet filter (D340)~~ to Duplicate of #348: Mac userspace packet filter (D340)

2026-11-04 19:02:26 +00:00

kayg commented

2026-11-04 19:02:33 +00:00

Author

Owner

The existing issue #348 already tracks this exact task and contains the original plan and J197 progress. This issue was created by the restarted run before I found #348, so #348 is the canonical work record from here. I am leaving this issue open because jobs do not close issues; all implementation findings, evidence, and gate output will go on #348.

kayg referenced this issue

2026-11-04 19:02:53 +00:00

Mac userspace packet filter (D340) #348

kayg commented

2026-11-05 17:48:47 +00:00

Author

Owner

Canonical issue: #348. Merge commit: not applicable to this duplicate-only record; this closure does not claim the canonical implementation is complete.

Rechecked all comments and issue timestamps immediately before closure; no activity in the last 12 hours. Audit: #369.

J256 housekeeping, authorized by kayg. Closing: The issue explicitly identifies itself as an accidental duplicate of canonical #348. All implementation, findings and acceptance evidence continue there; #348 stays open. Canonical issue: https://git.kayg.org/kayg/infraternal/issues/348. Merge commit: not applicable to this duplicate-only record; this closure does not claim the canonical implementation is complete. Rechecked all comments and issue timestamps immediately before closure; no activity in the last 12 hours. Audit: #369.

kayg closed this issue

2026-11-05 17:48:47 +00:00

kayg referenced this issue

2026-11-05 17:50:38 +00:00

Housekeeping 2026-11-05 #369

kayg referenced this issue

2026-11-05 18:10:54 +00:00

Housekeeping 2026-11-05 #369