Packet capture analysis is often like finding a needle in a haystack—usually the last rung on the ladder of troubleshooting efforts.

I’ve been analyzing pcaps since the early 90s, back when I was running snoop on Sun Solaris. That was an era when SMTP servers were open relays, and encrypted traffic was a rarity reserved for e-commerce. Even then, encryption was weak, and certificate chaining wasn't the complex headache it is today.

Recently, I wanted to find a realistic use case for the Google Gemini CLI in modern network defense and packet analysis.

A common scenario we face in the SOC or NOC is a secure connection failing to establish. You check the application logs: nothing. You check the system logs: silence. So, we resort to the "source of truth"—the pcap. Traditionally, if we are on the server side, we capture from that point, though capturing from multiple points yields better data. I wanted to see if Gemini could shorten this analysis cycle.

**

The Challenge: Why "Just an LLM" Wasn't Enough

I started with some basic tests: exporting Wireshark packets to a JSON file for Gemini to ingest. It worked for high-level questions (e.g., "Is there a Client Hello?"), but it fell short on deep dissection.

This highlighted a core limitation of using generative AI for technical analysis: if you feed an LLM (Large Language Model) too much raw, unstructured data, it gets "noisy." It couldn't reliably parse the nuances of hex codes in cipher suites or validate complex certificate chains—the exact details you need when a handshake fails silently.

Enter WireMCP: The Tool Belt

Then I found WireMCP. It is a Model Context Protocol (MCP) server that leverages the node.js framework and the power of tshark (the command-line cousin of Wireshark) to do the heavy lifting.

Instead of asking the LLM to "read" a massive file directly and guess the contents, WireMCP gives the AI agent a toolbox..

After installing and configuring it, the difference was an eye-opener. WireMCP exposes specific functions that the AI can "call" to do deterministic work on your network:

• capture_packets: Sniffs live traffic on a specific interface for a set duration. Great for catching momentary bugs.
• analyze_pcap: Reads a pre-saved packet capture file (.pcap) and converts it into structured data.
• get_summary_stats: Provides a high-level breakdown (e.g., "80% HTTPS, 5% TCP errors") for a quick health check.
• check_threats: Checks IPs against threat intelligence databases like URLhaus.

**

The Pivot: Direct TShark Orchestration

While those pre-built tools are useful, I found the most value in calling tshark directly via the prompt.

By crafting a specific prompt, we can force the AI to act like a senior engineer, looking for specific use cases quickly and efficiently. I used a sample file containing a "silent failure" (Spoiler Alert: it’s a bad certificate chain).

Here is the "SOP" (Standard Operating Procedure) prompt I inputted into the Gemini CLI. This is the input that drives the entire analysis:

Input Prompt

Context: I am troubleshooting a silent SSL connection failure. File: @/tmp/bad_cert_chain.pcap
Task: You must use your tshark tool to strictly dissect the TLS and TCP headers. Do not run generic summary commands. You need to extract specific field values to diagnose the root cause.
Execution Strategy: Run tshark commands using the -T fields flag to extract the following specific parameters. Group your analysis into these three logic checks:
1. Connection Termination & Alerts (The "Smoking Gun")
2. Certificate Chain Validation (The "Trust" Check)
3. Cipher & Protocol Negotiation
Final Conclusion: Synthesize the dissected data to explain why the connection failed.

• Command Logic: Filter for packets containing alerts or TCP resets.
• Fields to Dissect: -e frame.number -e ip.src -e tcp.flags.reset -e tls.alert_message.level -e tls.alert_message.desc
• Analysis: Did the server send a Level 2 (Fatal) alert? If so, what is the description (e.g., "Decrypt Error", "Unknown CA")? If there is no alert, did we see a TCP RST?
• Command Logic: Filter for the Certificate Handshake (tls.handshake.type == 11).
• Fields to Dissect: -e x509.subject.commonName -e x509.issuer.commonName -e x509.validity.notAfter -e x509.subjectAltName
• Analysis:
  • Ordering: Verify the chain order (Server → Intermediate → Root).
  • Completeness: Is the Intermediate CA missing (a common cause of silent failures on mobile/Java clients)?
  • Validity: Are any certificates expired?
• Command Logic: Filter for Client Hello (1) and Server Hello (2).
• Fields to Dissect: -e tls.handshake.version -e tls.handshake.ciphersuite -e tls.handshake.extensions_server_name
• Analysis:
  • Does the Client Hello include the correct SNI?
  • Compare the Client's list of ciphers vs. the single cipher chosen in the Server Hello.
  • If there is a handshake failure immediately after Client Hello, confirm if the protocol versions match.

Under the Hood: What the AI Executed

This is where the magic happens. Gemini didn't guess based on training data; it acted as an orchestrator, executing precise tshark commands on my local machine.

Here is the breakdown of the logic the AI applied:

1. The "Smoking Gun" Check

Command Run: tshark -r /tmp/bad_cert_chain.pcap -Y "tls.alert_message || tcp.flags.reset==1" -T fields ...

• Why: The AI first satisfied the "Connection Termination & Alerts" requirement. It filtered specifically for TLS alerts or TCP resets to determine if the server explicitly killed the connection.

2. The "Trust" Check (The Syntax Bridge)

Next, the AI needed to verify the certificate chain. It recognized that it needed specific fields to do this accurately.

3. The Deep Dive (Verbose Verification)

To get the expiration dates, the AI realized the summary fields weren't enough and autonomously decided to run a verbose (-V) check on the handshake packets.

**

The Final Verdict

The AI synthesized the data from those three deterministic tshark commands into this final conclusion. This is the output delivered back to the analyst in the terminal.

• ✦ The AI Conclusion

The SSL connection failed due to an expired certificate chain.

1. Connection Termination & Alerts ("The Smoking Gun")

• Result: No fatal TLS alerts or TCP resets were observed.
• Analysis: The connection did not terminate with a specific error message from the server. The failure was a result of the client rejecting the handshake.

2. Certificate Chain Validation ("The Trust Check")

• Result: The server presented a three-certificate chain.
• Analysis:
  • Ordering: The chain was correctly ordered: Server → Intermediate → Root.
  • Completeness: The intermediate CA was present.
  • Validity:
    • The server certificate (*.badssl.com) expired on April 12, 2015.
    • The root certificate (AddTrust External CA Root) expired on May 30, 2020.
• Conclusion: The expired certificates are the root cause of the connection failure.

3. Cipher & Protocol Negotiation

• Result: The client and server successfully negotiated TLS parameters.
• Analysis:
  • SNI: The Client Hello correctly included the SNI expired.badssl.com.
  • Cipher Suite: The client and server agreed on TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
  • Protocol Version: Both client and server negotiated TLS 1.2.

Summary

The silent SSL connection failure is caused by the client rejecting the server's certificate chain because both the server certificate and the root CA certificate are expired.

🚀 Recommended Remediation

Since this appears to be a test against badssl.com (a site specifically designed to test security errors), the system is behaving exactly as intended.

However, if this were a production environment, the immediate next steps would be:

1. Renew the Server Certificate: Generate a new CSR and acquire a valid certificate from a trusted Certificate Authority (CA).
2. Update the Chain: Ensure the web server is serving the correct, unexpired Intermediate certificates.
3. Check Root Store: If you control the client, ensure its root store is updated (though in this specific case, the server's presented root was the issue).