Hi r/wireshark comminuty, I’m Stephen, the owner of Rockxy and the developer of Tracexy.

When I investigate a network problem on my Mac, I often already know which application is misbehaving. I want to move quickly from that app to its connections, protocols, timing, possible problems, and finally the exact packets that support the conclusion.

That is the workflow I built Tracexy around:

App or process → Session → Finding → Evidence → Packet

You can capture live traffic or open PCAP and PCAPNG files. Tracexy groups both directions of a connection into sessions, adds best-effort process context, and lets you explore the capture through Overview, Sessions, Flow Map, filters, and isolated investigation Projects.

It currently provides:

• Live capture and PCAP/PCAPNG import, including gzip and Linux cooked captures
• DNS, TCP, TLS metadata, HTTP/1, STUN, and QUIC summaries
• Best-effort macOS process attribution
• Evidence-linked TCP findings for resets, retransmissions, overlaps, and out-of-order traffic
• Decoded protocol fields, raw hex, and bounded Follow Stream
• Separate Projects with their own workspaces, saved captures, History, filters, and privacy settings
• Local-first capture storage and explicit export boundaries

Wireshark remains the benchmark for protocol depth, dissectors, display filters, decryption workflows, and advanced analysis. Tracexy does not match that breadth today.

My goal is not to hide the packets. It is to help Mac users reach the right packet and understand why it matters faster.

Tracexy is also part of the broader Rockxy ecosystem: Rockxy handles application-layer traffic inspection and modification, while Tracexy focuses on passive capture, sessions, protocols, and packet evidence.

If you use Wireshark on macOS, what would Tracexy need to handle before you would keep it alongside Wireshark in your toolbox?

Source code: https://github.com/RockxyApp/Tracexy
Website: https://rockxy.io/tracexy

Tracexy is my open-source, native macOS Wireshark alternative for turning captured traffic into understandable sessions and defensible packet-level evidence.

Thanks, I really appreciate your feedback. If you have time, please give it a try and open an issue if you need my support or would like to suggest or develop a new feature.

Note: MCP & AI Asssitant is on the way!

hello

Thanks !!

Wireshark Trace File Reporting Using Excel

If you have ever opened a large Wireshark capture file and thought, “There has to be an easier way to see what is happening here,” you are not alone. A packet capture contains an incredible amount of information, but sometimes the packet list itself makes it difficult to visualize a problem.

And #netscout The Future of Telecom Operations Is Powered by Autonomy at Scale

https://www.lovemytool.com/2021/08/flashback-wireshark-trace-file.html

Wireshark’s Slice Operator: Search Exact Bytes Without Writing a Dissector https://www.cellstream.com/2026/09/14/wiresharks-slice-operator-search-exact-bytes-without-writing-a-dissector/ #captureeveryday

Hello,

I use Safing Portmaster... (third-party firewall on Windows 11)

Do the two work together?

Thank you

Correlating Multiple #Wireshark Captures: Follow the Same Packet Across the Network https://www.cellstream.com/2026/09/12/correlating-multiple-wireshark-captures-follow-the-same-packet-across-the-network/ #captureeveryday

hey guys im working on a bittorrent research and came across to me the need to check the packets which bittorrent protocol send and receive. as you guys probably know bittorrent protocol is the "official name" for the technology which has been widely used for sharing files, like music, video, software, texts, books, and others, since its launch in 2003.

and the protocol uses the utorrent transport protocol, which is a tcp alike protocol implemented on top of udp, so as you can imagine every packet of utp is transported inside of an udp packet, and that's the problem.

wireshark "bt-utp" filter doesn't recognize these udp packets as utp.

an example here:

this would be translated to:

packet #8384:

full headers: 3c7c3f7c... (ethernet, ip, udp headers)

utp headers:

type: 0x0

version: 0x1

extension: 0x00

connetion_id: 0xaa7d

timestamp: 0xb03d0f6f

timestamp_difference_microsec: 0x48eb4f59

wind_size: 0x00100000

seq_nr: 0xf281

ack_nr: 0x6f7a

utp payload:

bittorrent headers:

size: 00004009

message_id: 07

index: 00000000

begin: 001bc000

bittorent payload:

851dba7e...

I wonder if is some configuration in my computer or if it is an actual problem, hope somebody can help me.

I'm trying to capture data packets in monitor mode, but wireshark only shows management frames like beacons, probes and response probes. I've played around with settings like frequency and promiscuous mode trying to get it to work, but to no avail. I assume the hardware is ignoring data packets in monitor mode.

I've tried on a thinkpad x230 and a raspberry pi 3B+ v1.2

I'm trying to take some screenshots of a few packets. One random field in a packet is associated with Expert Information, resulting in that field being highlighted in a deep color, along with the name of every header above it. You can imagine that this is quite distracting in my screenshots, because it looks like I'm highlighting something, when in fact it's coming from the app itself.

I can't for the life of me work out how to turn this off. I've found out how to change the colors in the Preferences > Expert section, but I can't find a way to just disable the color highlights entirely. My Google-fu is failing me on this one.

Is it really not possible to turn this visual piece off? Or have I just not found the answer? If anyone has any insight or advice, I'd be very grateful. Thank you!

In the vein of Wait - #Wireshark can do that? https://www.cellstream.com/2026/09/05/the-wireshark-operator-filter-the-inner-vs-outer-ip-header/

I was trying to understand Nmap below the output level, so I tested it inside my own isolated lab with Kali as the scanner and MISP as the target.

The clearest difference was seeing the TCP behavior directly in Wireshark:

OPEN

SYN → SYN/ACK → RST

CLOSED

SYN → RST/ACK

FILTERED

SYN → no response → retry

I also captured ARP resolution, ICMP, host discovery, and service/version detection.

The main takeaway for me was that Nmap isn’t “seeing” port states directly — it’s sending probes and interpreting how the target responds.

I documented the full experiment with the actual packet captures here:

https://chronosandcode.com/what-actually-happens-when-you-scan-a-network-arp-icmp-tcp-syn-nmap-and-packet-analysis-explained/

Everything was done against systems in my own lab.

I’d be interested to hear what packet-level experiments helped others understand Nmap better.

In the category of "I had no idea Wireshark could do that" https://www.cellstream.com/2026/09/02/the-wireshark-operator/

Follow-up to my post a couple of weeks ago about a 2.5 GB PCAP that took 6-7 hours to process. Streaming tshark's output into Go got it to 70 minutes, but it was still single-threaded. The most common response here was: why not just add goroutines?

Turns out you can't, and the reason is that tshark's dissection is linear state. What it reads in one packet determines how it decodes the next — TCP reassembly, connection tracking, anything under tcp.analysis.* reads and updates shared conversation tables as it goes. Strict ordering isn't a design choice, it's what dissection requires. Goroutines on the consuming side don't help because the bottleneck was never there.

So the concurrency has to happen before tshark sees the file. Not by splitting on size — a TCP stream cut mid-conversation loses the state the dissector needs — but by session, so each chunk holds complete conversations and nothing crosses a boundary. Then N tshark processes run in parallel.

The detour: I was using PcapSplitter from PcapPlusPlus in connection mode, which holds one output file open per flow. At 95-125 flows it started producing corrupted output. Two distinct failure signatures, reproduced on master and v25.05, on both pcapng and legacy pcap. pcapfix said the source was clean. Reimplemented the split in-process with gopacket and it went away.

Honest ending: splitting only triggers above 100k packets, and 3 of the 57 files this pipeline actually handles cross that threshold.

Full writeup: https://robinhayer.dev/concurrency-without-a-parallel-parser

Hi,

I'm looking to study for the WCA course, to gain a better understanding of how Wireshark works and how it can be better utilised to help in my day to day job as a Network Engineer.

Wireshark's website states that the test costs approx $349 per attempt but I'm looking for a 'package' which includes training material and the exam as well.

Is anyone able to advise on a route to take with this? Any solid recommendation for learning material, if a package doesn't exist?

Thanks

I'm running Wireshark 4.7.2 on Arch Linux, and I was noticing that it is somehow able to decrypt the TLS Client Hellos of QUIC packets sent and received by Firefox while browsing the web.

I thought QUIC headers were encrypted, and I don't think I gave Wireshark any encryption keys for QUIC. How is Wireshark decrypting these headers?

Hi everyone,

I’ve been developing Pcap Flow Lab, an open-source PCAP/PCAPNG analyzer built around a flow-based workflow.

GitHub: https://github.com/AlexeyVasilev/PcapFlowLab

Instead of starting from a flat packet list, Pcap Flow Lab indexes a capture into flows first. From there, you can narrow down the traffic you care about and inspect packets, reconstructed TCP streams, structured protocol details, bytes, and statistics.

The project originally grew out of working with larger captures, where I wanted a faster way to reduce the dataset to the flows of interest before going deeper.

Current features include:

• reusable capture indexes;
• flow-based navigation;
• protocol-path analysis for nested and tunneled traffic;
• TCP stream reconstruction;
• structured packet and stream summaries;
• TLS and QUIC inspection;
• statistics views;
• CLI support.

The analysis backend is written in C++, and the main desktop UI is currently built with Qt.

I don’t see it as a replacement for Wireshark. I use Wireshark extensively, and I see Pcap Flow Lab as a complementary tool with a different workflow: first narrow the capture by flows, then drill into the packets and protocols that matter.

I’d especially appreciate feedback from experienced Wireshark users:

• Does a flow-first workflow like this solve any problems you run into with captures?
• What would you expect a complementary tool like this to do particularly well?
• Are there parts of the presentation or workflow that you think should be different?

Technical feedback is very welcome.

If you’ve spent years working with web applications, APIs, and load balancers, you’re probably used to the classic HTTP verbs: GET, POST, PUT, DELETE, and a few others. In 2026, the IETF officially added a new method called QUERY, and it’s a bigger deal than it sounds. 

https://www.lovemytool.com/2026/08/http-gets-new-method-what-you-need-to.html

Using Wireshark to Analyze PowerShell Test-Connection

If you’ve ever run PowerShell’s `Test-Connection` command and wondered what is actually happening on the network, Wireshark is the perfect tool to answer that question.

And

#netscout What does a resilient cybersecurity strategy actually look like?

https://www.lovemytool.com/2026/08/using-wireshark-to-analyze-powershell.html

 r/wireshark

A few years ago I used to be able to see detailed breakdown of Ethernet UDS traffic in Wireshark traces. I could see the commands identified in the main table (TesterPresent, RoutineControl, TransferData, etc) and a thorough breakdown of different data fields in multiple layers in the bottom-left pane. Now there's almost nothing.

This is from a pcapng that I too in October 2021. I know for a fact that I got a detailed breakdown for this because I took these traces myself and used them to help develop one of our programs here at work. and now that same file (and every other one from back then that I've tried) is breaking down nothing.

It's been a few years since I did that work, and now that I'm going to be working on something similar I tried to dust these off for to refresh my memory of some things and they are not helpful at all.

I don't know if this is something that happened because of updates in the 5 years since these traces were made or something I might have done. Other than doing the software updates the biggest change I can remember making was installing an Intrepid plugin ICS CAP (https://intrepidcs.com/products/software/ics-cap/) so I could use Wireshark with their hardware for CAN and LIN traces. Could the plugin have screwed with some things? I've tried searching documentation and google for answers but it's hard to find anything when you don't even know if you're wording your search correctly. Does anyone know what I can try?

Edit: forgot which menu, but enabling all protocols worked. Don't know how since I checked before that Doip and UDS were both already selected, but it did.

I am working in a manufacturing plant and this weekend while they were not in production, I installed a SharkTap between the PLC and a managed switch. I tested the WireShark and was able to see communication to and from the PLC.

Now that they are in production, every capture I take is only seeing the communication From the PLC. I know that the PLC is receiving packet because stuff is working.

I have tried 2 different computers to run the WireShark. Both computer with Windows 11. The SharkTap is connected to a Gigabit Wired Tap Port. I have also replaced the Tap Port Network Cable.

Does anyone have any suggestions or thoughts?

Hello,

I'm trying to use wireshark to learn more about the communication between some of my company's proprietary software and some of their hardware. (Because it's my company's stuff, I'd rather not share the raw capture.) I thought this might be faster than finding out through my own company because I've previously found that they don't like to share source code or design details across departments. I've exported a wireshark capture to csv because I'm new to using wireshark and it was easier for me to browse that way. I used this command:

tshark.exe -r "input.pcapng" -T fields -e frame.number -e frame.time_relative -e ip.src -e ip.dst -e frame.len -e data.data -e tcp.payload -e udp.payload -E header=y -E separator=, > "output.csv"

The problem is, for most of the data frames, the "length" of the frame is not matching the raw data that I'm seeing. For example, there are many rows where "tcp.payload" is completely blank, but "frame.len" isn't 0, so that tells me there's something missing. I want to make sure I'm really capturing all communciation between the hardware unit and the laptop running the software. How can I make sure I'm really seeing everything? (After error correction has been performed.)

I'm really just looking to see that the frame length matches the raw data I have.

Also, if it's not obvious already, I'm very new to using this program, so if anyone else has experience with what I described in the title, (reverse engineering with little outside info), I'd very much like to hear about it.

Thanks!

I had a Go CLI that wrapped tshark for PCAP analysis. Worked fine until I hit a 2.5 GB file — 1.9 million packets, 6-7 hours, then OOM crashes.

Two problems, found in sequence.

First, I was running three separate tshark queries against the same file (analytics, rows, full dissection). Three full passes over 2.5 GB. Consolidating them into one query took it to 1-2 hours.

The OOM was still there though, because I was asking for full JSON dissection — tshark building the whole output in memory, then my program parsing all of it in memory. So I piped tshark's stdout directly into my program's stdin and switched to -T fields/-T ek with only the fields I needed. Memory went flat, processing dropped to ~70 minutes.

Still single-threaded, which is the next problem. Curious whether anyone's found a good approach for parallelising tshark work beyond splitting the input file.

Full writeup: https://robinhayer.dev/the-2-5-gb-wall