I am a ChatGPT subscriber to the basic (not PRO) service. I saw the following post on LinkedIn and was fascinated:
Think about the implications. You don’t need to know how to use Wireshark other than to do a capture. You certainly don’t need to know how to troubleshoot packet captures as ChatGPT can do it all!! I have to try this. Keep in mind your results may vary.
I am going to use ChatGPT 5.
Test 1
I have a TCP session that had an issue. The only thing in the capture is the specific TCP session in question. I called it test1.pcapng, and asked Chat GPT to tell me what is wrong with it:
Now it took ChatGPT some time. It did not throw up, it simply went through a bunch of analysis steps, and after several minutes, output the following:
WOW!
The analysis is correct.
Test 2
I tried another capture called test2.pcapng. This trace is only ARP traffic.
Using the same prompt, this time ChatGPT bailed:
OK – my confidence was significantly lowered but I liked that I was provided some options. The most obvious to me was to save the file in .pcap format instead of .pcapng.
Test 3
I did the conversion and tried again. You can see that once again ChatGPT bailed:
Again the good news is I am given options, but my confidence is shattered.
Test 4
Some of you may note at this point that I uploaded .pcapng and .pcap files, which is not what the LinkedIn post says. It says, export to CSV first.
OK so let’s repeat these steps using that procedure beginning with the same capture we used in Test 1. Does ChatGPT answer the same?
Below I uploaded the CSV with the same prompt:
First, it only took 39 seconds for ChatGPT 5 to analyze the CSV.
Second, the analysis was more specific as to the contents of the TCP conversation and focused on the RTSP, and states that the issues probably would not create a service disruption, whereas the first analysis was more accurate.
Test 5
OK – now for the capture that ChatGPT bailed out on – the test2 file, again exported to CSV.
There was an interesting set of “thinks” done on this, but in the end, the answer is right on the money, first try.
Confidence is returned.
Conclusion
The post on LinkedIn is accurate, at least to this level of testing, especially if you use CSV format. That said, ChatGPT is still probably learning, and the more you and I upload these captures to test this capability the better it will become. The analysis of the test1 capture was better as a .pcapng file than CSV, in my opinion anyway.
Will ChatGPT replace all the Wireshark wizards? I think in many cases it already does, though the depth of my testing for this post is very limited. For example, I don’t think you can span a port, capture 100 Gigs of traffic – dump it into ChatGPT and get a report on any and all issues. I think as long as you know how to narrow down the capture and feed that to ChatGPT the better it will work. Certainly in the future, we won’t need their assistance especially as ChatGPT gets better and better (learning). No special people or web sites needed for packet analysis is almost today.
What do you think? We would love to hear comments.
Comments are welcomed below from registered users. You can also leave comments at our Discord server.
If you would like to see more content and articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!
In a great discussion with Roland on the Wireshark Discord site, he pointed out that LLM’s will have limited capability to perform packet analysis due to their design. I agreed fundamentally, but for my readers, I wanted to explain this a little further. Packet analysis is a deterministic, time-series, binary-parsing problem that programs like Wireshark get us on a perfect starting place; general-purpose LLMs are probabilistic text predictors. That mismatch creates hard ceilings:
* Data modality mismatch – PCAPs are byte streams with strict bit/field semantics; LLMs tokenize text. Turning packets into text loses fidelity (padding, flags, bitfields, nanosecond timing, checksums).
* Determinism vs. probability – Protocol decoding (e.g., TCP reassembly, QUIC coalescing, IPv6 EH parsing) must be exact. LLM outputs vary and can hallucinate fields that don’t exist.
* Context window limits – Real traces can be millions of packets; LLMs can’t ingest entire captures, so cross-flow/long-duration correlations (RTO evolution, out-of-order bursts, multi-path reordering) get lost.
* Timing & math precision – Diagnoses often hinge on microsecond deltas (jitter, RTT, RTO, CWND behavior). LLMs are weak at precise arithmetic and clock-edge reasoning.
* Stateful reassembly – Correct analysis requires maintaining per-flow state (seq/ack windows, selective ACK blocks, TLS/QUIC handshake state). LLMs don’t maintain long-lived, exact state without external tools.
* Encryption – Modern traffic (TLS 1.3, QUIC) hides payloads; useful signals are side-channel features (sizes, timings, JA3/JA4, packetization). Extracting and interpreting those features is algorithmic, not linguistic.
* NIC/OS offloads & vantage quirks – GSO/TSO/LRO, ACK decimation, mirrored/SPAN artifacts, and capture drops must be corrected by parsers; LLMs can misread these as “network problems.”
* Label scarcity & ground truth – Supervised “what’s wrong in this trace?” datasets are rare and environment-specific. Models trained on one network often fail on another.
* Forensics & repeatability – Analysts need auditable, reproducible evidence (“these exact frames show 21 lost segments”); stochastic text isn’t acceptable as proof.
What LLMs can do well (and where they shine):
* Turn structured outputs (Zeek logs, tshark JSON, tcptrace stats) into explanations, playbooks, and next actions.
* Generate filters/queries/scripts (tshark, Scapy, Zeek, Wireshark display filters).
* Triage: given precomputed features (loss rate, dupACK bursts, window graphs), propose the most likely root cause and tests to confirm.
* Education and documentation: clarify protocol behavior, visualize flows, draft RCA reports.
Practical pattern that works today
* Deterministically decode first (libpcap/Wireshark/Zeek) → compute features/metrics/flags.
* Feed the compact, structured summary (per-flow stats, graphs, anomalies) to an LLM for reasoning, explanation, and decision support.
* Keep the LLM tool-using: let it call parsers, run filters, and return verifiable numbers; use the LLM for narrative, not ground truth.
Bottom line: LLMs aren’t great packet decoders; they’re great packet interpreters—once a reliable parser has distilled the bytes into facts. My testing above clearly stumbled on the ability of ChatGPT as an LLM to call on those decoder functions to be successful. That said – it is pretty darned impressive and when you take the ^2 progress AI is making….well, who knows. And that my friends is the point of the post!