How do you build VisualEther FXT configs when no single sample covers the capture?

Combine samples. This noisy browsing pcap needed the http3 sample (DNS, TCP, TLS, QUIC, HTTP/3, QPACK, HTTP/2, HTTP/1.x) plus the mdns_llmnr sample (mDNS, LLMNR, NBNS, ARP, SSDP). The name-resolution templates are grafted in at priority 110 — above the generic DNS templates at 100 — because mDNS and LLMNR reuse the dns.* field names, so without the higher priority the unicast DNS templates would steal multicast packets and mislabel them.

How do you coalesce IPv4 and IPv6 onto one lifeline for the same host?

The diagram axis groups by the friendly name in hosts.txt, so giving an address pair the same name collapses both families into one lifeline. Here the client (192.168.0.21 and fe80::ea41:25df:ab56:5e55) shares the name Client-PC, and the mDNS (224.0.0.251 / ff02::fb) and LLMNR (224.0.0.252 / ff02::1:3) multicast groups each get one shared name.

Are there TCP retransmissions in the capture, and where?

Yes — 3 TCP retransmissions, frames 693-695, all on TCP stream 10, sent from www.gstatic.com (74.125.199.94) to the client. They are 1412-byte TLS Application Data segments carrying the bulk body of the OneGoogle bar's static JavaScript and CSS, plus 4 minor duplicate-ACK / out-of-order frames.

Are there QUIC retransmissions, and which connections do they belong to?

Yes — 5 QUIC retransmissions. Four (frames 1102, 1103, 1106, 1107) are on QUIC connection 2 to ogads-pa.clients6.google.com — the OneGoogle AsyncData gRPC-over-HTTP/3 call — and hit both directions. One (frame 1260) is on QUIC connection 3 to play.google.com. The main www.google.com QUIC connection (number 0) had no retransmissions.

Was packet loss actually harming the page load?

No. Both loss clusters are on the OneGoogle bar machinery — its static assets over TCP/HTTP-2 and its dynamic async RPC over QUIC/HTTP-3 — plus one stray on play.google.com. It is light, transient loss recovered immediately during a normal page load, with no persistent problem on any single server and the main page connection untouched.

QUIC & TCP Retransmissions in a Noisy Google Browsing Capture: VisualEther FXT Authoring & Loss Triage

01UserAuthor FXT + hosts.txt

Generate explore.fxt.xml, sessions.fxt.xml and hosts.txt from www.google.com.pcapng.

(mid-task) Consider coalescing the IPv4 and IPv6 axis if they represent the same machine.

02ClaudeCombine samples & render

Capture: 1,388 packets. analyze_capture detected 11 protocols — DNS, TLS, QUIC, HTTP/3, HTTP/2, mDNS, LLMNR, NetBIOS-NS, ARP, TCP, IPv6 — with a sidecar sslkeylog.log for TLS/QUIC decryption. The best single sample (http3) covered only ~82%, so I authored by combining two built-in samples.

FXT composition strategy

Source sample	Covers
`http3`	DNS, TCP, TLS, QUIC, HTTP/3, QPACK, HTTP/2, HTTP/1.x — the dominant browsing traffic
`mdns_llmnr`	mDNS, LLMNR, NBNS, ARP, SSDP — the “noise”

Priority gotcha. mDNS and LLMNR reuse the dns.* field names, so the grafted name-resolution templates run at priority 110 — above the generic DNS templates at 100. Otherwise the unicast DNS Query/Response templates would steal multicast packets and mislabel them. auto-v6="true" auto-generates the IPv6 (udpv6/tcpv6) variants.

Validation & render

File	Templates	PCAP coverage
`explore.fxt.xml`	102	62% (826 frames)
`sessions.fxt.xml`	67 (+6 session types)	49%

The uncovered remainder is the high-volume bare QUIC 1-RTT data the templates deliberately skip to keep the diagram readable. Session outcomes from extract_sessions:

Type	Outcome	Count
dns-query	success::dns-resolved	5
http3-stream	success::http3-2xx	27
http3-stream	incomplete::no-close	3
http2-stream	success::http2-2xx	5
http2-stream	incomplete::no-close	1
quic-connection	incomplete::no-close	4
tcp-connection	success::graceful-fin	3
tcp-connection	incomplete::no-close	4

Coalescing IPv4 + IPv6 lifelines

The diagram axis groups by the name in hosts.txt, so giving an address pair one name collapses both families into a single lifeline. Three machines appeared under both families:

Machine	IPv4	IPv6	Shared name
Client	`192.168.0.21`	`fe80::ea41:25df:ab56:5e55`	`Client-PC`
mDNS group	`224.0.0.251`	`ff02::fb`	`mDNS-Multicast`
LLMNR group	`224.0.0.252`	`ff02::1:3`	`LLMNR-Multicast`

Finally, materialize_config wrote visualether.toml (TLS keylog + hosts.txt wired in) so a downstream visualether generate needs no flags.

03UserAny retransmissions?

Do we see QUIC and TCP retransmissions?

04ClaudeTCP & QUIC retransmit counts

Yes — both are present. Checked directly with tshark expert-info filters rather than inferred from the diagram.

TCP retransmissions

Frames	tcp.stream	Direction	Count
693, 694, 695	10	`74.125.199.94` → `Client-PC`	3
(dup-ACK / out-of-order)	—	mixed	4

Three back-to-back retransmitted segments on a single Google server stream, plus 4 minor loss-signal frames.

QUIC retransmissions

Five retransmissions — frames 1102, 1103, 1106, 1107, 1260 — detected via Wireshark’s quic.retransmission expert field (which needs the keylog to see into the encrypted stream — which we have).

In the diagrams

TCP retransmits render in tangerine (“🔄 TCP Retransmission”, priority 155).
QUIC retransmits render at priority 210 — deliberately above HTTP/3 (200) so a retransmitted H3 STREAM frame is classified as a loss event, not normal HEADERS/DATA.
Both are bookmark="true", so they show in the bookmark sidebar.

So this is a lightly lossy trace — not a major problem. Want me to pull the SNI / authority behind stream 10 and the QUIC frames so you can see which server/page they belonged to?

05UserWhich servers?

Yes.

06ClaudeMapping loss to hosts

Every retransmission ties back to ancillary content loaded while rendering www.google.com.

TCP retransmissions → www.gstatic.com

TCP stream 10 = Client-PC ↔ www.gstatic.com (74.125.199.94:443), HTTP/2 over TLS (SNI confirmed). Frames 693–695 are three 1412-byte TLS Application Data segments — the bulk body of the gstatic asset responses, i.e. the JavaScript/CSS for Google’s “One Google” top bar:

frame 680 → /og/_/js/k=og.asy.en_US…   (JS)
frame 717 → /og/_/ss/k=og.asy…        (CSS)

QUIC retransmissions → two connections

Mapping each retransmit’s quic.connection.number to its SNI:

Frames	QUIC conn	Server (SNI)	Direction / content
1102, 1103	2	`ogads-pa.clients6.google.com` (`142.250.73.106`)	server → client
1106, 1107	2	`ogads-pa.clients6.google.com`	client → server; frame 1107 carries the H3 request `/$rpc/…AsyncDataService/GetAsyncData`
1260	3	`play.google.com` (`74.125.20.101`)	server → client

Connection 2 (4 of the 5 QUIC retransmits) is the OneGoogle AsyncData gRPC call — gRPC over HTTP/3 to ogads-pa.clients6.google.com that populates the dynamic bits of the One Google bar (account / notifications). Loss hit both directions. Connection 3 is a single retransmit toward play.google.com.

SNI per QUIC connection

Conn	SNI	Server IP	Retransmits
0	`www.google.com`	`142.251.157.119`	none
1	`www.gstatic.com`	`74.125.199.94`	none (QUIC)
2	`ogads-pa.clients6.google.com`	`142.250.73.106`	4
3	`play.google.com`	`74.125.20.101`	1

Bottom line

Static assets www.gstatic.com over TCP/HTTP-2 — 3 retransmits on the OneGoogle JS/CSS bundle.
Dynamic RPC ogads-pa.clients6.google.com over QUIC/HTTP-3 — 4 retransmits on the GetAsyncData call, plus 1 stray to play.google.com.
Main page the www.google.com QUIC connection (conn 0) saw no retransmissions at all.

Light, transient loss during a normal page load on the OneGoogle bar machinery — nothing pointing at a persistent problem with any one server.

Method. Configs authored and rendered with VisualEther via its MCP integration with Claude — analyze_capture → author explore.fxt.xml / sessions.fxt.xml from combined samples → extract_endpoints for hosts.txt → validate_fxt → materialize_config → explore + extract_sessions. Retransmission counts and host/SNI mapping cross-checked with tshark expert-info and quic.connection.number / tcp.stream queries against the TLS-key-decrypted pcap.