|
Hi,
Sure, sorry the earlier message wasn't clear — here are some more details.
What this is about
------------------
NetScaler is an application-delivery / load-balancer appliance. For each request it processes, it can log which of its internal policies (rules) that request matched — a feature it calls "policy tracing." When you capture traffic on the device in its native
nstrace format (which Wireshark already reads), the device writes one of these policy-trace summaries into the same capture file, as a record with type byte 0x9C.
The important point: this 0x9C record is NOT a packet. It never went over the network — the device generates it once per transaction (at the end of the flow) to summarize the policy decisions. Today Wireshark's NetScaler reader doesn't recognize this record
type, so it's just dropped and never shown. My MR only teaches the reader to recognize and surface it.
What changed in the revised version
------------------------------------
-
Originally I surfaced the record as if it were a packet, tagged with WTAP_ENCAP_USER15 (a private link-layer type). The feedback was that upstream code shouldn't produce those — agreed.
-
Since the record isn't a packet, the suggestion was to use Wireshark's file-type-specific record types (REC_TYPE_FT_SPECIFIC_EVENT / _REPORT). The revision now tags it as REC_TYPE_FT_SPECIFIC_EVENT, so it goes through the wtap_fts_rec
path instead of the packet/encapsulation path — no USER15, no WTAP_ENCAP_, and no linktype involved.
-
I used EVENT rather than REPORT because the record carries a real, meaningful timestamp — the appliance stamps it when it emits the record at flow end (≈ the transaction's end time), and the reader surfaces that as the frame's time.
Happy to switch to REPORT if you'd prefer.
-
The detailed field-by-field decode of the record body is done by a separate Lua dissector (a plugin, not part of this MR). The in-tree change only recognizes and surfaces the record; the Lua does the decode.
Happy to go deeper on any specific part — just let me know which piece is unclear and I'll expand on it.
Thanks,
Aman Agrawal
From: Jamil Ahmad <ahmadjamil09335@xxxxxxxxx>
Sent: Saturday, October 17, 2026 12:52 PM
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Cc: Goutham Shetlur Mohan <Goutham.ShetlurMohan@xxxxxxxxxx>; Ashwin Jagadish <ashwin.jagadish@xxxxxxxxxx>; Aman Agrawal <aman.agrawal@xxxxxxxxxx>
Subject: Re: [Wireshark-dev] Re: Review request — MR !26753: wiretap/netscaler: add 0x9C policy-trace record support
I didn't get it right, what all these means ? Appreciate if can explain it to me,
Regards,
JA
HRA
Hi All,
Thanks for reviewing the initial changes to MR !26753 (adding the NetScaler 0x9C policy-trace record to the nstrace reader) and sharing your feedback.
I've pushed a revised version addressing the comments:
-
No more WTAP_ENCAP_USER15. A policy-trace record is a synthetic,
-
non-packet summary emitted once at flow end (not a captured frame), so
the reader now surfaces it as REC_TYPE_FT_SPECIFIC_EVENT — which removes
the USER0-15 private-linktype concern entirely. I went with EVENT rather
than REPORT because the record carries a meaningful flow-end timestamp,
but I'm happy to switch to REPORT if you feel that fits better.
-
Dissection is now routed the standard way for file-type-specific records,
-
via the wtap_fts_rec table keyed by the nstrace file type — no
WTAP_ENCAP_* or LINKTYPE involved. This adds a small recognition hook in
epan/dissectors/packet-nstrace.c alongside the wiretap change; the
detailed field decode still lives in an out-of-tree Lua dissector, as
-
Please review the revised version whenever someone has a moment.
Thanks,
Aman Agrawal
Hi all,
I've opened a small merge request adding one new record type to the existing NetScaler capture-file reader, and would appreciate a core-developer review when someone has a moment.
What it does
NetScaler nstrace policy tracing emits a synthetic, non-packet record (type 0x9C, NSPR_PDPKTRACEPOLICY_V35) alongside the normal packet-trace records in a V30/V35 capture. The current reader doesn't recognize this type, so these records are not surfaced. The
change:
-
adds the NSPR_PDPKTRACEPOLICY_V35 0x9C #define in wiretap/netscaler.h
-
handles it in nstrace_read_v30() and nstrace_seek_read_v30(), surfacing the record verbatim as its own frame carrying its embedded nanosecond timestamp.
It's self-contained (touching only wiretap/netscaler.c and netscaler.h); no existing record handling is modified.
A design point I'd like feedback on
The reader is intentionally scoped to just identifying and surfacing the record; decoding of the record body is handled by a Lua dissector (not part of this MR). The record is surfaced with encapsulation WTAP_ENCAP_USER15, which the Lua dissector registers
on to decode it.
Process note
The fork pipeline couldn't run (free-tier CI identity verification), so the pipeline on the MR may need to be run in the Wireshark project.
Thanks for taking a look.
Aman Agrawal
_______________________________________________
Wireshark-dev mailing list --
wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to
wireshark-dev-leave@xxxxxxxxxxxxx
|