A folder of captures is not a regression suite until a machine can tell a good file from a bad one. You want a fixed set of pcaps, a command that analyses each one, and an exit code or a report row that is PASS or FAIL — so a pull request, a nightly job or a lab rack can stop on a real problem.
This article compares offline checks on recorded captures with live checks against a device under test, and a workflow with PCAP Workbench and, where you have a lab node, Mobile Core Generator. Keep live tests on an authorized, isolated network.
What a regression packet set needs
A useful set is more than "some traffic that once worked":
- Stable inputs. Each case is a file (or a small, generated scenario) with a documented purpose: a happy-path attach, a rejected Create Session, a TCP stream with a reset, a DNS exchange.
- An expected outcome. Offline: every request has a response, no unexpected late answers, TCP retransmissions stay under a limit, the file still parses. Live: the DUT answers with the expected Cause or status.
- A machine-readable result. An exit code, a JSON/CSV/HTML report, or both.
- A clean failure. When a case fails, the report names the packet, the procedure or the stream, not just "error".
Build the captures first (a generator, an editor, or an authorized lab take), then lock the checks. The earlier articles on generating GTPv2-C/PFCP traffic and on editing captures without breaking checksums cover those prep steps.
Option 1: tshark scripts
tshark can filter a file and print fields, and a shell script can treat a non-empty result as a failure. That is fine for one or two invariants (a display filter that must match zero packets, a count that must stay constant).
Good for: a narrow, well-named check in a pipeline that already uses Wireshark.
Limits: you write the pairing of requests and responses, the latency policy and the report format yourself. A suite of GTP, PFCP, SIP and DNS cases becomes a project.
Option 2: PCAP Workbench matching, TCP analysis and recipes
PCAP Workbench can gate a recorded capture without sending anything. According to the product page and User Guide:
- Response matching (
PCAP tools → Analyze → Response matching, or--analyze-matching) pairs GTPv2-C, GTPv1-C, PFCP, GTP-U Echo, SIP, DNS, DHCP, ICMP, ARP, RADIUS, Diameter and other listed protocols, and reports unanswered requests, unmatched or late responses, retransmissions, and a Cause / status histogram as JSON or CSV. --fail-on-issuesmakes that command exit 1 when a request is unanswered, a response is unmatched or late — a CI-friendly fail. It is a Full Edition feature; without a license the process ends with exit code 6 and writes nothing. The report itself is not limited to 10 packets, even in Community Edition.- TCP analysis (
--analyze-tcp, or a TCP analysis report recipe step) lists handshake RTT, retransmissions, out-of-order segments, duplicate ACKs, zero windows and resets. In a recipe, optional thresholds fail the step (exit code 1) after the report is written:max_retransmission_pct,max_rst,max_zero_windows,max_out_of_order. - Recipes chain tools (for example Anonymize, then a matching report) and run from the CLI:
LooshaPcapWorkbench.exe --analyze-matching lab.pcap --protocols gtpv2-c,pfcp --timeout 3 --report lab_matching.csv --fail-on-issues
LooshaPcapWorkbench.exe --run-recipe "lab checks" -i case.pcap -o out\ --set "TCP analysis report.max_rst=0"
Community Edition can run one input per --run-recipe (a script can loop). Several --input files in one run are Full Edition. Recipe steps that write a capture are capped at 10 packets in Community; the two analysis reports still read the whole file when they come first.
Option 3: Mobile Core Generator probe and conformance suite
When the question is not "is this file consistent?" but "does this lab node still answer?", Mobile Core Generator (Full Edition) adds live checks:
- Probe sends a capture and matches responses (loss, latency, Cause). Loopback is the default; a real interface needs
-allow-remote. - Conformance suite (
gtpcore suite) runs JSON test cases against a lab SGW, PGW or UPF, and reports PASS, FAIL, ERROR or SKIP with a reason, plus HTML, JSON or CSV. Exit code 0 means every case was PASS or SKIP; 4 means at least one FAIL or ERROR; 3 is Community Edition (the suite is Full only).
gtpcore suite -list
gtpcore suite -self-test
gtpcore suite -iface NAME -target-ip IPV4 -target-mac MAC -report-html report.html -allow-remote
-list prints the cases and sends nothing. -self-test runs them against an in-process fake node, with no network. A real DUT run belongs only on an isolated lab segment: the suite creates and deletes sessions on the node you aim at.
A practical regression workflow
- Assemble the cases. One pcap (or one generated scenario) per behaviour you care about. Keep a golden copy.
- Add offline gates first. Run
--analyze-matching --fail-on-issuesand, for user-plane TCP, a TCP analysis recipe with thresholds that match your tolerance. - Automate. Call the same commands from CI. Treat exit 1 as a failed case, exit 6 as "this check needs Full Edition", and a missing input as exit 4.
- Only then, if you have a lab node, add live tests. Start with
gtpcore suite -self-test, then a bounded probe or suite run on loopback or a dedicated adapter. - Keep the reports. JSON or HTML next to the pcap is what you will compare after a change.
Which tool when?
| Need | Good fit |
|---|---|
| One display-filter invariant | tshark + a small script |
| Offline request/response and Cause checks, CI exit code | Workbench --analyze-matching --fail-on-issues (Full) |
| Offline TCP health with fail thresholds | Workbench TCP analysis report in a recipe |
| Repeatable chain (sanitize, then check) | Workbench recipes (--run-recipe) |
| Live PASS/FAIL against a lab SGW/PGW/UPF | Mobile Core suite (Full); -self-test first |
Editions
PCAP Workbench Community Edition is free for personal, educational and non-commercial use, with a 10-packet cap on capture-writing operations. Matching and TCP reports can read a full file. --fail-on-issues and multi-file recipe runs need the Full Edition ($59 one-time). Mobile Core Generator Community Edition is free for non-commercial evaluation (100 subscribers/sessions); probe and the conformance suite are Full Edition (one-time $89). Both run on Windows 10/11 64-bit; Linux builds are available on request.
Limitations
--fail-on-issuesflags unanswered, unmatched or late responses. It is not a full 3GPP conformance suite.- TCP thresholds are the ones documented above; they do not invent application-level assertions.
- The Mobile Core suite talks to a lab node on UDP 2123, 8805 and 2152. Never point it at a production or third-party system.
- Community Workbench still caps written captures at 10 packets, even when a recipe also writes a report.
FAQ
Can Community Edition fail a CI job on unmatched responses?
Not with --fail-on-issues (exit 6, no report written). You can still export a matching report and apply your own policy, or use Full Edition for the exit-code gate.
Does a matching report send packets?
No. It reads the file once, offline.
What is the difference between FAIL and ERROR in the suite?
ERROR means a setup step failed or the case could not be built (the node could not be prepared). FAIL means the node answered, but not as the case expected.
How do I try the suite without a DUT?
gtpcore suite -list prints the cases. gtpcore suite -self-test runs them against a fake in-process node and sends nothing to the network.