[GH-ISSUE #3115] [Feature] Admit TShark packet inspection on Windows under the existing Job Object memory bound #1081

New issue

Open

opened 2026-10-15 18:30:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:30:55 +00:00

Owner

Originally created by @lumatic2 on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3115

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Provider or capability discovery

Current limitation

On Windows, the same TShark binary can summarize a capture but cannot inspect selected fields from it.

Observed on main f3534749 built from source (Windows native addon built with the documented MinGW lane), Windows 11 x64 build 26200, TShark 4.6.9, on a self-made 3-packet UDP sample.pcap:

rea inspect-pcap-capture sample.pcap --json succeeds (exit 0) under the existing Windows boundary, with the limitation "Each owned Windows tool tree has a 1 GiB Job Object committed-memory limit; this is not a machine-wide quota."
rea inspect-packet-capture sample.pcap --fields ip.addr --fields udp.port --display_filter udp --format json is refused (exit 1):

{"code":"capability_unavailable","category":"unsupported_provider","message":"Packet inspection requires Linux with util-linux prlimit and REA_TSHARK_COMMAND so expanded captures are processed under an enforced address-space limit. ..."}

The refusal comes from the platform gate in src/captures/TsharkCaptureProvider.ts:135, while src/pcap/PcapNativeBound.ts:19-26 already admits win32 with a Job Object memory limit for the same tool.

Use cases

Inspecting selected fields, display filters and decode-as rules in a capture recorded from a Windows application, on the Windows host where it was recorded. The summary family gives address/DNS/SNI/URI inventories, but not field-level answers.

Desired outcome and success criteria

inspect_packet_capture and inspect_packet_fields run on Windows under the same 1 GiB Job Object committed-memory limit that pcap summaries use.
Bounds that Windows does not enforce are stated in the result limitations instead of implied. Today prlimit also sets 30 CPU seconds, 64 MiB per file and no core dumps; the native authority only sets JOB_OBJECT_LIMIT_JOB_MEMORY (native/windows/src/process.cc:27). The 30 s wall-clock timeout and the input/output caps are unchanged.
The capability inventory remediation (src/application/CapabilityInventory.ts:407-413) and docs/packet-captures.md name the Windows requirements. macOS stays refused.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Windows x64 only. No new authority, no traffic acquisition, no C++ change. A Job Object CPU-time limit would need a native change and is out of scope here.
Non-goal: SigrokRecordingProvider (src/signals/SigrokRecordingProvider.ts:131) has the same gate and could follow the same pattern later; it is not part of this request.
Scope question: is "CPU-time and file-size bounds not enforced on Windows, disclosed in limitations" acceptable — the same trade-off pcap summaries already make?

Verification available so far

I have a prototype or observed results

Verification details (optional)

The observed results above (summary succeeds, field inspection refused) on the same host, binary and file. For a change, I would add unit coverage for the win32 branch and limitation text, and attach a real TShark 4.6.9 run on Windows 11 x64; the current real TShark lane runs on ubuntu-24.04 only.

Alternatives considered

Using inspect_pcap_capture only: no selected fields, filters or decode-as rules.
Running REA under WSL: works around the gate but leaves the Windows path and owned-process boundary unused, and captures recorded on Windows must be moved into the Linux filesystem.

Possible direction

Reuse the preparePcapNativeBound shape: on win32, return { memoryLimitBytes: 1024 ** 3 } and the Windows limitation text, and pass it through runOwnedCommand instead of building a prlimit argument vector.

References

src/captures/TsharkCaptureProvider.ts:135, :385
src/pcap/PcapNativeBound.ts:19-26
src/application/CapabilityInventory.ts:407-413
docs/packet-captures.md, docs/pcap-analysis.md
#2318 (TShark packet inspection), #2507 (pcap refusal wording)

Originally created by @lumatic2 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3115 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Provider or capability discovery ### Current limitation On Windows, the same TShark binary can summarize a capture but cannot inspect selected fields from it. Observed on main `f3534749` built from source (Windows native addon built with the documented MinGW lane), Windows 11 x64 build 26200, TShark 4.6.9, on a self-made 3-packet UDP `sample.pcap`: - `rea inspect-pcap-capture sample.pcap --json` succeeds (exit 0) under the existing Windows boundary, with the limitation "Each owned Windows tool tree has a 1 GiB Job Object committed-memory limit; this is not a machine-wide quota." - `rea inspect-packet-capture sample.pcap --fields ip.addr --fields udp.port --display_filter udp --format json` is refused (exit 1): ``` {"code":"capability_unavailable","category":"unsupported_provider","message":"Packet inspection requires Linux with util-linux prlimit and REA_TSHARK_COMMAND so expanded captures are processed under an enforced address-space limit. ..."} ``` The refusal comes from the platform gate in `src/captures/TsharkCaptureProvider.ts:135`, while `src/pcap/PcapNativeBound.ts:19-26` already admits `win32` with a Job Object memory limit for the same tool. ### Use cases Inspecting selected fields, display filters and decode-as rules in a capture recorded from a Windows application, on the Windows host where it was recorded. The summary family gives address/DNS/SNI/URI inventories, but not field-level answers. ### Desired outcome and success criteria - `inspect_packet_capture` and `inspect_packet_fields` run on Windows under the same 1 GiB Job Object committed-memory limit that pcap summaries use. - Bounds that Windows does not enforce are stated in the result limitations instead of implied. Today `prlimit` also sets 30 CPU seconds, 64 MiB per file and no core dumps; the native authority only sets `JOB_OBJECT_LIMIT_JOB_MEMORY` (`native/windows/src/process.cc:27`). The 30 s wall-clock timeout and the input/output caps are unchanged. - The capability inventory remediation (`src/application/CapabilityInventory.ts:407-413`) and `docs/packet-captures.md` name the Windows requirements. macOS stays refused. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) - Windows x64 only. No new authority, no traffic acquisition, no C++ change. A Job Object CPU-time limit would need a native change and is out of scope here. - Non-goal: `SigrokRecordingProvider` (`src/signals/SigrokRecordingProvider.ts:131`) has the same gate and could follow the same pattern later; it is not part of this request. - Scope question: is "CPU-time and file-size bounds not enforced on Windows, disclosed in limitations" acceptable — the same trade-off pcap summaries already make? ### Verification available so far I have a prototype or observed results ### Verification details (optional) The observed results above (summary succeeds, field inspection refused) on the same host, binary and file. For a change, I would add unit coverage for the `win32` branch and limitation text, and attach a real TShark 4.6.9 run on Windows 11 x64; the current real TShark lane runs on ubuntu-24.04 only. ### Alternatives considered - Using `inspect_pcap_capture` only: no selected fields, filters or decode-as rules. - Running REA under WSL: works around the gate but leaves the Windows path and owned-process boundary unused, and captures recorded on Windows must be moved into the Linux filesystem. ### Possible direction Reuse the `preparePcapNativeBound` shape: on `win32`, return `{ memoryLimitBytes: 1024 ** 3 }` and the Windows limitation text, and pass it through `runOwnedCommand` instead of building a `prlimit` argument vector. ### References - `src/captures/TsharkCaptureProvider.ts:135`, `:385` - `src/pcap/PcapNativeBound.ts:19-26` - `src/application/CapabilityInventory.ts:407-413` - `docs/packet-captures.md`, `docs/pcap-analysis.md` - #2318 (TShark packet inspection), #2507 (pcap refusal wording)

bsakaguchi added the

enhancement

label

2026-10-15 18:30:55 +00:00

bsakaguchi referenced this issue

2026-10-17 21:08:23 +00:00

[PR #1081] [CLOSED] fix(artifacts): bound ZIP entry extraction to the 64 MiB per-entry budget #2629

bsakaguchi added

enhancement

and removed

enhancement

labels