What is an srsRAN F1-U capture and why does Wireshark only show GTP?

The srsRAN_Project DU writes its F1-U interface (the CU-UP to DU user-plane path) as a bare GTP-U packet under a DLT_USER link type — DLT=156, shown as 'User 9' — with no Ethernet/IP/UDP wrapper. VisualEther auto-detects this and maps the DLT to the gtp dissector, so GTP-U decodes with no flags. Wireshark stops there because the GTP-U T-PDU does not carry plain IP: it carries an NR RAN Container extension header with an NR-U / NRUP frame (TS 38.425), and the T-PDU payload is a PDCP-NR PDU. tshark cannot set the PDCP-NR SN length over the GTP path, so the inner user plane (the VoNR SIP/RTP) is not directly dissected — which is exactly the symptom reported in srsRAN issue #1289.

How do you reconstruct the inner VoNR IP packets from a bare GTP-U over DLT_USER capture?

First confirm the PDCP is null-ciphered (NEA0): inspect a T-PDU and check it begins with 0x80 (a PDCP-NR data PDU, D/C=1) and that byte 4 is 0x45 (an IPv4 header). In this capture the layout is a 3-byte PDCP-NR header (18-bit SN) with no SDAP header, immediately followed by the inner IPv4 packet. The reconstruction is: run tshark to extract frame.time_epoch and gtp.tpdu_data for every T-PDU frame; strip the first 3 bytes (the PDCP header) off each; and rebuild a raw-IP pcap with text2pcap using -l 101 (LINKTYPE_RAW), preserving the original timestamps via a strptime format with %f fractional seconds. DL Data Delivery Status frames carry no T-PDU and are naturally skipped. Ciphered PDCP (NEA1/NEA2) cannot be recovered this way — it needs the UE keys.

Why does the F1-U sequence diagram use constant CU-UP and DU labels instead of IP addresses?

A bare GTP-U F1-U capture has no IP layer at all — extract_endpoints returns zero addresses — so there is nothing to place on the participant axis. Instead the FXT uses generic elements with constant axis labels: a / address that watches a field present on every packet (gtp.teid) and replaces its value wholesale with a fixed string. Direction is driven by the NR-U PDU type: DL User Data (nrup.pdu_type 0) flows CU-UP to DU, and DL Data Delivery Status (nrup.pdu_type 1) flows DU to CU-UP. Two message templates, one per direction, hardcode the correct CU-UP and DU endpoints. This is the same constant-axis-label pattern VisualEther recommends for non-Ethernet linktypes like PPP or Frame Relay serial.

How do you separate two NR-U message types that share the same opcode field?

DL User Data and DL Data Delivery Status differ by the value of nrup.pdu_type, so an opcode regex separates them directly. But 'final' versus 'non-final' Data Delivery Status share the same opcode value — they differ only in nrup.final_frame_ind — so opcode matching alone cannot split them. A element is not allowed inside a , so the discriminator is a param marked required='true': a on nrup.final_frame_ind gates the template. When the field is present and matches 'Frame is final' the template fires and closes the tunnel session (success::final-frame); otherwise the template is dropped and the packet falls through to the ongoing-flow template. This is VisualEther's first-match-wins gating for templates that share an opcode.

Why is there RTP voice media but no visible SIP INVITE in the reconstructed VoNR capture?

The cleartext SIP in the reconstructed capture shows only REGISTER, 100 Trying and 401 Unauthorized (the IMS-AKA challenge) for two UEs, yet 1,670 RTP frames of voice media flow between them. The INVITE and 200 OK are not missing — they are protected. In IMS, once the IPsec security associations are established during registration, all subsequent SIP signalling travels inside IPsec ESP (transport mode). The capture contains 208 ESP frames on the same bearer, which is where the call setup lives. The RTP media itself is not IPsec-protected here, so it stays visible (surfaced with the RTP heuristic, since there is no readable SDP to pin the dynamic ports), while the signalling that set it up is ESP-encrypted and opaque without the SA keys.

Why are two DNS queries sent but only one DNS response received?

It is DNS resolver failover, not a lost response. The UE is configured with a primary resolver (8.8.8.8) and a secondary (8.8.4.4). It sends the query to the primary first; when no answer arrives within roughly 1.95 seconds it retransmits the identical query — same DNS transaction ID — to the secondary, which answers about half a second later. So one logical lookup is two query packets and one response. Across the whole capture, all 13 queries to 8.8.8.8 got zero responses while all 23 queries to 8.8.4.4 were answered — the primary is silent for every query, so every lookup pays a fixed primary-timeout penalty before succeeding on the secondary. Because both query packets share the transaction ID, a VisualEther session keyed on dns.id correctly stitches the retransmit and the response into one session that closes as success::resolved.

How are F1-U GTP-U tunnels grouped into sessions when there is no connection setup or teardown?

F1-U user-plane tunnels have no explicit open/close handshake, so sessions are keyed on gtp.teid — one session per GTP-U tunnel (per DRB direction) — with a direction-agnostic, auto-start session type. Because there is no natural stop, an idle-timeout closes a tunnel after a gap in activity, and an optional final-frame Data Delivery Status closes it gracefully as success::final-frame when one appears. In this 37,871-frame capture that produced 49 tunnels: 4 high-volume tunnels still active at the end of the capture and 45 shorter tunnels closed by the idle-timeout.

srsRAN F1-U pcap Analysis: Bare GTP-U, NR-U/NRUP, PDCP Reconstruction to Inner VoNR SIP/RTP & DNS Failover

01UserDownload #1289, generate flows + toml

Please download the pcap from srsRAN_Project issue #1289 and generate explore and session level flows. Please generate FXT files as well as visualether.toml.

02ClaudeF1-U transport: NRUP over bare GTP-U

Pulled du_f1u.zip from the issue attachments and extracted du_f1u.pcap (2.2 MB, 37,871 frames). analyze_capture detected the shape immediately: a bare GTP-U packet under DLT_USER — DLT=156 / “User 9” — which VisualEther auto-maps to the gtp dissector. This is the srsRAN F1-U interface (CU-UP↔DU user plane).

The GTP-U T-PDU is not plain IP. Every packet carries an NR RAN Container extension header holding an NR-U / NRUP frame (TS 38.425), and the payload below it is a PDCP-NR PDU. extract_fields confirmed two NR-U PDU types and no IP endpoints at all:

nrup.pdu_type	Direction	Role
`0` DL User Data	CU-UP → DU	Downlink PDCP delivery
`1` DL Data Delivery Status	DU → CU-UP	Flow-control feedback (delivered/desired buffer)

With zero IP addresses to axis on (extract_endpoints returned empty), I authored the FXTs with generic <message> elements and constant CU-UP/DU axis labels — a <source>/<destination> that watches gtp.teid (present on every packet) and replaces it wholesale:

<source><address match=".*" replace="CU-UP">gtp.teid</address></source>
<destination><address match=".*" replace="DU">gtp.teid</address></destination>

Direction comes from the opcode value (nrup.pdu_type), one template per direction. Sessions key on gtp.teid — one session per F1-U tunnel — direction-agnostic and auto-start, with a 2 s idle-timeout since user-plane tunnels have no handshake. Both FXTs validated at 100% coverage. materialize_config wrote visualether.toml persisting the DLT_USER→gtp mapping so a plain visualether generate Just Works.

The explore diagram rendered all 37,871 messages; the session view split into 49 tunnels:

Session outcome	Count
timeout::idle 2.000s	45
incomplete::mid-capture (still active)	4

The four active tunnels are the high-volume data bearers (~8,000 messages each); the 45 idle-closed tunnels are shorter flows. The inner VoNR (SIP/RTP) the issue reporter wanted is below PDCP-NR and not yet visible — that comes later.

03UserGate shared opcodes with required

param fields can be marked with required="true" to match different templates using the same opcode.

04ClaudeFinal-frame stop via required param

Applied. DL User Data and DL Data Delivery Status differ by opcode value, so the opcode regex already separates them. But “final” vs “non-final” Data Delivery Status share the same opcode value (nrup.pdu_type) — they differ only in nrup.final_frame_ind. A <qualify> can’t live inside a <message>, so I gated a dedicated session-stop template with a required param:

<param required="true" match=".*(Frame is final).*"
       replace="🏁 Final Frame: $1">nrup.final_frame_ind</param>

Only a “Frame is final” Data Delivery Status matches this gate and closes its tunnel as success::final-frame; every other Data Delivery Status fails the gate and falls through to the ongoing-flow template. This capture is entirely “not final”, so it falls through today (tunnels still close on the 2 s idle-timeout), but the FXT now closes tunnels cleanly whenever a final frame appears — and it cleared the FXT-LIFECYCLE “never closes gracefully” warning. Re-validated at 100% NR-U coverage.

05UserReconstruct the inner VoNR pcap

Reconstruct the inner VoNR pcap from the PDCP.

06ClaudeStrip PDCP, rebuild raw-IP pcap

First I inspected the raw T-PDU bytes rather than guessing a strip length. The layout is unambiguous and the PDCP is NEA0 / cleartext:

80 00 00 | 45 00 00 2c 8d b4 ... 0a 2e 00 be 0a 2a 00 b2 13 c4 13 c4 ...
┗━PDCP━┛   ┗━ inner IPv4 (0x45): 10.46.0.190 → 10.42.0.178, TCP 5060/5060

Byte 0 = 0x80 → a PDCP-NR data PDU (D/C=1), 18-bit SN → 3-byte header.
Byte 3 = 0x45 → the inner IPv4 header starts right after — no SDAP header.
The inner payload is already readable: SIP over TCP/5060, a REGISTER to ims.mnc070.mcc001.3gppnetwork.org, even DNS to 8.8.8.8.

So reconstruction is: strip the first 3 bytes off every non-empty T-PDU and rebuild a raw-IP pcap. I wrote reconstruct_inner.py — it runs tshark to pull frame.time_epoch + gtp.tpdu_data, validates each T-PDU (0x80… then 0x45 at offset 3), emits a text2pcap hexdump with per-packet timestamps, and rebuilds with text2pcap -l 101 (LINKTYPE_RAW):

tshark -r du_f1u.pcap -o 'uat:user_dlts:"User 9 (DLT=156)","gtp",...' \
  -T fields -e frame.time_epoch -e gtp.tpdu_data
… strip 3-byte PDCP header, keep inner IPv4 …
text2pcap -t "%Y-%m-%d %H:%M:%S.%f" -l 101 inner.txt du_f1u_inner.pcap

Result — 2,960 inner IP packets, timestamps preserved; 34,911 DL Data Delivery Status frames correctly skipped (they carry no T-PDU); 0 non-IPv4. The protocol hierarchy of what was hidden inside the PDCP:

Protocol	Frames	Detail
SIP	6	REGISTER / 100 / 401 (over TCP 5060)
RTP	1,670	Voice media, payload type 107
RTCP	14	Media control
TLS	273	XCAP / Ut over HTTPS
ESP	208	IPsec (transport mode)
DNS	59	IMS / app discovery
HTTP	4	Provisioning

Verified the reconstruction dissects cleanly: the first five frames are the TCP three-way handshake on port 5060 followed by the SIP REGISTER, all at the original capture timestamps. This is exactly the traffic issue #1289 reported as invisible — Wireshark stopped at GTP because the T-PDU is PDCP-NR, not IP.

07UserGenerate the VoNR flows

Yes, generate the VoNR flows for du_f1u_inner.pcap.

08ClaudeSIP/RTP + the ESP-hidden INVITE

analyze_capture on the reconstructed pcap detected 8 protocols (SIP, RTP, RTCP, DNS, TLS, HTTP, ESP/IPsec, TCP). I took VisualEther’s sip-rtp sample as the base (SIP/SDP + RTP/RTCP, with SIP-over-TCP support this capture needs) and extended it with DNS, TLS, HTTP and ESP/IPsec templates so the diagram tells the full VoNR story. Six session types — sip-dialog, sip-registration, rtp-stream, dns, tls, esp-ipsec — both FXTs validated at 100% coverage (RTP surfaced with -o rtp.heuristic_rtp:TRUE, required because there is no readable SDP to pin the dynamic ports). Session summary:

Session type	Count	Outcome
dns	23	success::resolved
tls	28	idle-closed
esp-ipsec	8	4 active + 4 idle-closed
sip-registration	2	incomplete::no-close
rtp-stream	2	idle-closed

Finding. The cleartext SIP is only REGISTER→100→401 (IMS-AKA challenge) for two UEs — there is no visible INVITE, yet 1,670 RTP frames of voice flow between them. That is the expected IMS pattern: once the IPsec SA is established during registration, the INVITE/200 OK travel inside the ESP-encrypted tunnel (the 208 ESP frames, transport mode). The media stays visible; the signalling that set it up is protected. So the “incomplete” SIP registration is not a failure — the call setup is simply opaque without the IPsec SA keys.

09UserTwo DNS queries, one response?

Please explain the DNS queries in the du_f1u_inner capture. I see that two DNS queries are sent but one response is received.

10ClaudeDNS resolver failover, silent primary

It’s DNS resolver failover, not a lost response. Take transaction 0xda1e (connectivitycheck.platform.hicloud.com):

Frame	Time	Src → Dst	Type
6	0.14 s	UE → 8.8.8.8	Query
44	2.09 s	UE → 8.8.4.4	Query (retransmit, same ID)
45	2.55 s	8.8.4.4 → UE	Response

Both queries share the same DNS transaction ID and question. The UE hits its primary resolver 8.8.8.8 first, gets nothing, waits ~1.95 s, then retransmits the identical query to its secondary 8.8.4.4, which answers 0.46 s later. One logical lookup = two query packets + one response.

Why the primary never answers

Aggregated over the whole capture, the root cause is unambiguous:

Resolver	Queries	Responses
8.8.8.8 (primary)	13	0
8.8.4.4 (secondary)	23	23

Every DNS response comes from 8.8.4.4; the primary 8.8.8.8 is silent for every query — unreachable or filtered on the testbed’s N6/UPF egress. So every lookup pays a fixed ~2 s primary-timeout penalty before succeeding on the secondary. Because both query packets share the transaction ID, the dns session (keyed on dns.id) correctly stitches the retransmit and the response into one session that closes as success::resolved — which is why the session count reported 23 resolved lookups rather than double-counting the retries. These lookups (HiCloud / Huawei / AMap / Baidu endpoints) are the handset’s background connectivity checks riding the same DRB, and they survived reconstruction intact because they are cleartext UDP/53 — unlike the IPsec-protected SIP INVITE.

Method. Two pcaps analyzed with VisualEther via its MCP integration with Claude. For the F1-U transport: analyze_capture to detect bare GTP-U / DLT_USER and the NR-U/NRUP stack, hand-authored explore.fxt.xml / sessions.fxt.xml with constant CU-UP/DU axis labels and a required-param final-frame gate, validate_fxt on every edit, then explore + extract_sessions and materialize_config. The inner VoNR pcap was reconstructed with a tshark→strip-PDCP→text2pcap -l 101 pipeline, then diagrammed with an extended sip-rtp FXT (RTP heuristic on). Every field cited (nrup.pdu_type, gtp.teid, PDCP/IP layout, SIP methods, RTP streams, ESP frame counts, dns.id and per-resolver query/response counts) was read from the rendered NDJSON and cross-checked with tshark across all 37,871 + 2,960 frames.