[GH-ISSUE #6595] [Bug] Packet capture inspection rejects valid TShark field aliases after canonicalization #3980

New issue

Closed

opened 2026-10-31 00:45:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:45:45 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6595

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

inspect_packet_capture accepts fields: ["bootp.type"], but its output parser rejects the dhcp.type key that supported TShark 4.4.9 emits for that alias. The request fails with AnalysisOutputError: TShark returned unordered frames or unselected fields. instead of returning the selected DHCP message type.

This is an executed REA source-boundary reproduction plus a source-derived public integration trigger. Real TShark and the complete CLI/MCP command were not executed. TShark canonicalization is established from its released source, rather than an invented producer observation.

Reproduction

Public trigger, derived from the complete source path: on the documented Linux/TShark 4.x/prlimit setup, inspect a stable existing PCAP containing a DHCP/BOOTP request with MCP {"name":"inspect_packet_capture","arguments":{"path":"/artifacts/discover.pcap","fields":["bootp.type"]}}. The alias is valid in TShark 4.4.9 and resolves to dhcp.type. All selectors satisfy REA's string, count, and aggregate argument guards. No display filter or decode-as override is needed. This public invocation was not run locally.

The following isolated boundary probe was actually executed once against the stated REA revision, with its lockfile dependencies and Node 24.22.1. Save it as alias-probe.mts, then run node --import ./node_modules/tsx/dist/loader.mjs /path/to/alias-probe.mts "$PWD" from a REA source checkout:

import { pathToFileURL } from 'node:url';
import { resolve } from 'node:path';
import assert from 'node:assert/strict';
const root = process.argv[2];
if (!root) throw new Error('Pass the REA source checkout path');
const load = (path: string) => import(pathToFileURL(resolve(root, path)).href);
const { inspectPacketCaptureInputSchema } = await load('src/domain/captures/packetCapture.ts');
const { parsePacketOutput } = await load('src/captures/parsePacketOutput.ts');
const request = inspectPacketCaptureInputSchema.parse({
  path: '/artifacts/discover.pcap', fields: ['bootp.type'],
});
// Producer shape follows the released TShark source cited below.
const text = JSON.stringify([{_source:{layers:{
  'frame.number':['1'], 'dhcp.type':['1'],
}}}]);
let failure: unknown;
try { parsePacketOutput(text, request.fields); } catch (e) { failure = e; }
assert(failure instanceof Error);
assert.equal((failure as {_tag?:string})._tag, 'AnalysisOutputError');
const control = parsePacketOutput(text, ['dhcp.type']);
assert.equal(control[0]['dhcp.type'][0], '1');
console.log((failure as Error).message);
console.log(JSON.stringify(control));

One boundary attempt reproduced the failure. The same input/output shape with the canonical selector passed in that probe. The probe does not need a capture file because it isolates validation and parsing; no claim is made that this synthetic JSON was collected from a running TShark.

Expected behavior

Return the field TShark selected through its supported alias, preserving the caller's requested selector and the producer's canonical field identity as appropriate. The recorded packet contract promises inspection of selected fields supported by the installed TShark. The input schema accepts this selector; no canonical-name-only restriction is documented or enforced during admission.

Impact and scope

A valid aliased field fails the entire packet inspection whenever the selected field is present. This is bounded compatibility failure, not a security finding. Other aliases with the same canonicalization can be affected; their individual coverage was not tested. Selecting dhcp.type directly is a practical workaround, supported by the same-output control and the released producer source. No files, configuration, or live targets were changed by the probe.

REA version

rea-agents 6.7.0 source, revision 642f6571ea9d333ea50114c25e648dbb5b8a3c46 on main. The npm registry latest version was checked before the audit. No installed rea --version command was run.

Runtime and platform

Node.js v24.22.1; Linux 7.2.8-9-omarchy x86_64; repository-pinned tsx 4.23.15 and lockfile dependencies. Producer applicability established from released Wireshark/TShark 4.4.9 source; TShark was not installed or executed for this finding.

Target and artifact context

Recorded DHCP/BOOTP PCAP; reduced selected-field JSON containing frame 1 and the canonical dhcp.type field for an aliased bootp.type selection. No private capture or credentials are involved.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Observed boundary output:

validated_fields: ["bootp.type"]
producer_fields: ["frame.number", "dhcp.type"]
alias_result.tag: AnalysisOutputError
alias_result.message: Invalid analysis output for inspect_packet_capture: TShark returned unordered frames or unselected fields.
canonical_control: [{"frame.number":["1"],"dhcp.type":["1"]}]

Expected source: REA's documented selected-field contract and accepted request schema linked above; TShark's released alias handling linked below.
Failure source: the executed source-boundary probe and exact-name output rejection.
Evidence provenance: observed for REA validation, failure and canonical control; static for the real producer's alias conversion and public integration trigger.
Local verification: reproduced at the parser boundary; public CLI/MCP and real-producer runtime reproduction not run.
Reproduction completeness: complete for the boundary failure and concrete static public call path; real-producer end-to-end execution remains unverified.

The public provider passes the original selectors to -e and later to the parser. Its Linux, executable-version, resource, capture-integrity and output-shape guards do not normalize aliases. In released Wireshark 4.4.9, the DHCP dissector registers bootp as an alias, proto_registrar_get_byalias replaces the protocol prefix and resolves the field, TShark's -e handling stores the canonical abbreviation, and selected-field JSON uses that stored abbreviation as its member name. Thus dhcp.type is a selected field rather than an unexpected producer field.

Typed outcome or recovery expected

Successful packet Evidence with the requested DHCP observation. After restoration, the alias case should return the same field value as the canonical control; genuinely unselected fields should continue to be rejected.

Analysis or suspected cause

Source-derived: parsePacketOutput compares every producer key with a set of literal caller strings. TShark canonicalizes recognized aliases before serializing keys. The two owners therefore disagree about the same selected field's identity. Protocol aliases and legacy column aliases are one potential identity class, not separate drafted bugs; only the DHCP alias premise is established here.

Additional context

Preliminary searches inspected the full supplied open-title index and queried open and closed issues for "TShark" "alias", "packet" "alias", "bootp", "unordered frames" and "unselected fields". No matching defect was found. Submission-time searches are performed separately immediately before filing.

Last-known-good version: NOT_ENOUGH_INFO; no historical regression boundary was established. AI assistance: an AI agent inspected source, executed the isolated probe, and prepared this report; no human review or maintainer acceptance is asserted. No code was changed, committed, or submitted.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: A valid TShark alias passes REA admission but its canonical field is rejected, aborting that bounded capture inspection; the parser failure and canonical control were directly observed, with producer behavior established from released source.
Workaround status: available
Workaround basis: Select the canonical field name (dhcp.type); the identical canonical output passed the same parser control, and released TShark source registers and emits that canonical field.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6595 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Evidence, artifacts, or reconstruction ## Observed behavior `inspect_packet_capture` accepts `fields: ["bootp.type"]`, but its output parser rejects the `dhcp.type` key that supported TShark 4.4.9 emits for that alias. The request fails with `AnalysisOutputError: TShark returned unordered frames or unselected fields.` instead of returning the selected DHCP message type. This is an executed REA source-boundary reproduction plus a source-derived public integration trigger. Real TShark and the complete CLI/MCP command were not executed. TShark canonicalization is established from its released source, rather than an invented producer observation. ## Reproduction Public trigger, derived from the complete source path: on the documented Linux/TShark 4.x/prlimit setup, inspect a stable existing PCAP containing a DHCP/BOOTP request with MCP `{"name":"inspect_packet_capture","arguments":{"path":"/artifacts/discover.pcap","fields":["bootp.type"]}}`. The alias is valid in TShark 4.4.9 and resolves to `dhcp.type`. All selectors satisfy REA's string, count, and aggregate argument guards. No display filter or decode-as override is needed. This public invocation was not run locally. The following isolated boundary probe was actually executed once against the stated REA revision, with its lockfile dependencies and Node 24.22.1. Save it as `alias-probe.mts`, then run `node --import ./node_modules/tsx/dist/loader.mjs /path/to/alias-probe.mts "$PWD"` from a REA source checkout: ```typescript import { pathToFileURL } from 'node:url'; import { resolve } from 'node:path'; import assert from 'node:assert/strict'; const root = process.argv[2]; if (!root) throw new Error('Pass the REA source checkout path'); const load = (path: string) => import(pathToFileURL(resolve(root, path)).href); const { inspectPacketCaptureInputSchema } = await load('src/domain/captures/packetCapture.ts'); const { parsePacketOutput } = await load('src/captures/parsePacketOutput.ts'); const request = inspectPacketCaptureInputSchema.parse({ path: '/artifacts/discover.pcap', fields: ['bootp.type'], }); // Producer shape follows the released TShark source cited below. const text = JSON.stringify([{_source:{layers:{ 'frame.number':['1'], 'dhcp.type':['1'], }}}]); let failure: unknown; try { parsePacketOutput(text, request.fields); } catch (e) { failure = e; } assert(failure instanceof Error); assert.equal((failure as {_tag?:string})._tag, 'AnalysisOutputError'); const control = parsePacketOutput(text, ['dhcp.type']); assert.equal(control[0]['dhcp.type'][0], '1'); console.log((failure as Error).message); console.log(JSON.stringify(control)); ``` One boundary attempt reproduced the failure. The same input/output shape with the canonical selector passed in that probe. The probe does not need a capture file because it isolates validation and parsing; no claim is made that this synthetic JSON was collected from a running TShark. ## Expected behavior Return the field TShark selected through its supported alias, preserving the caller's requested selector and the producer's canonical field identity as appropriate. The [recorded packet contract](https://github.com/morluto/rea/blob/642f6571ea9d333ea50114c25e648dbb5b8a3c46/docs/packet-captures.md#L3-L6) promises inspection of selected fields supported by the installed TShark. The [input schema](https://github.com/morluto/rea/blob/642f6571ea9d333ea50114c25e648dbb5b8a3c46/src/domain/captures/packetCapture.ts#L8-L21) accepts this selector; no canonical-name-only restriction is documented or enforced during admission. ## Impact and scope A valid aliased field fails the entire packet inspection whenever the selected field is present. This is bounded compatibility failure, not a security finding. Other aliases with the same canonicalization can be affected; their individual coverage was not tested. Selecting `dhcp.type` directly is a practical workaround, supported by the same-output control and the released producer source. No files, configuration, or live targets were changed by the probe. ## REA version `rea-agents` 6.7.0 source, revision `642f6571ea9d333ea50114c25e648dbb5b8a3c46` on main. The npm registry latest version was checked before the audit. No installed `rea --version` command was run. ## Runtime and platform Node.js v24.22.1; Linux 7.2.8-9-omarchy x86_64; repository-pinned tsx 4.23.15 and lockfile dependencies. Producer applicability established from released Wireshark/TShark 4.4.9 source; TShark was not installed or executed for this finding. ## Target and artifact context Recorded DHCP/BOOTP PCAP; reduced selected-field JSON containing frame 1 and the canonical `dhcp.type` field for an aliased `bootp.type` selection. No private capture or credentials are involved. ## Interface MCP ## Earliest failure stage Transport or result projection ## Relevant output or evidence Observed boundary output: ```text validated_fields: ["bootp.type"] producer_fields: ["frame.number", "dhcp.type"] alias_result.tag: AnalysisOutputError alias_result.message: Invalid analysis output for inspect_packet_capture: TShark returned unordered frames or unselected fields. canonical_control: [{"frame.number":["1"],"dhcp.type":["1"]}] ``` - Expected source: REA's documented selected-field contract and accepted request schema linked above; TShark's released alias handling linked below. - Failure source: the executed source-boundary probe and [exact-name output rejection](https://github.com/morluto/rea/blob/642f6571ea9d333ea50114c25e648dbb5b8a3c46/src/captures/parsePacketOutput.ts#L9-L25). - Evidence provenance: observed for REA validation, failure and canonical control; static for the real producer's alias conversion and public integration trigger. - Local verification: reproduced at the parser boundary; public CLI/MCP and real-producer runtime reproduction not run. - Reproduction completeness: complete for the boundary failure and concrete static public call path; real-producer end-to-end execution remains unverified. The public provider [passes the original selectors to `-e` and later to the parser](https://github.com/morluto/rea/blob/642f6571ea9d333ea50114c25e648dbb5b8a3c46/src/captures/TsharkCaptureProvider.ts#L330-L368). Its Linux, executable-version, resource, capture-integrity and output-shape guards do not normalize aliases. In released Wireshark 4.4.9, [the DHCP dissector registers `bootp` as an alias](https://github.com/wireshark/wireshark/blob/wireshark-4.4.9/epan/dissectors/packet-dhcp.c#L10487-L10489), [`proto_registrar_get_byalias` replaces the protocol prefix and resolves the field](https://github.com/wireshark/wireshark/blob/wireshark-4.4.9/epan/proto.c#L1065-L1095), [TShark's `-e` handling stores the canonical abbreviation](https://github.com/wireshark/wireshark/blob/wireshark-4.4.9/tshark.c#L1533-L1546), and [selected-field JSON uses that stored abbreviation as its member name](https://github.com/wireshark/wireshark/blob/wireshark-4.4.9/epan/print.c#L2611-L2636). Thus `dhcp.type` is a selected field rather than an unexpected producer field. ## Typed outcome or recovery expected Successful packet Evidence with the requested DHCP observation. After restoration, the alias case should return the same field value as the canonical control; genuinely unselected fields should continue to be rejected. ## Analysis or suspected cause Source-derived: `parsePacketOutput` compares every producer key with a set of literal caller strings. TShark canonicalizes recognized aliases before serializing keys. The two owners therefore disagree about the same selected field's identity. Protocol aliases and legacy column aliases are one potential identity class, not separate drafted bugs; only the DHCP alias premise is established here. ## Additional context Preliminary searches inspected the full supplied open-title index and queried open and closed issues for `"TShark" "alias"`, `"packet" "alias"`, `"bootp"`, `"unordered frames"` and `"unselected fields"`. No matching defect was found. Submission-time searches are performed separately immediately before filing. Last-known-good version: `NOT_ENOUGH_INFO`; no historical regression boundary was established. AI assistance: an AI agent inspected source, executed the isolated probe, and prepared this report; no human review or maintainer acceptance is asserted. No code was changed, committed, or submitted. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: A valid TShark alias passes REA admission but its canonical field is rejected, aborting that bounded capture inspection; the parser failure and canonical control were directly observed, with producer behavior established from released source. - Workaround status: available - Workaround basis: Select the canonical field name (`dhcp.type`); the identical canonical output passed the same parser control, and released TShark source registers and emits that canonical field.

bsakaguchi closed this issue

2026-10-31 00:45:45 +00:00

bsakaguchi referenced this issue

2026-10-31 01:11:51 +00:00

[PR #4160] [CLOSED] fix(reconstruction): keep overall behavioral claims unknown when capture unknowns remain #6099