As engineers, we’re all familiar with the time-consuming task of manually sifting through countless packets while trying to recall IP addresses, port numbers, and protocol details. With the introduction of tools like Google AI, much of that tedious process can be streamlined, allowing us to parse and interpret network data more quickly and, in many cases, more accurately than by relying solely on visual inspection.

But the key question is: can we simply input targeted prompts or queries into Google Gemini to aid with network analysis? Was I able to extract instant, context-aware insights from Wireshark data? Or generate a network diagram? Let’s find out.

It’s worth noting that Wireshark’s native PCAP format is not currently supported by Gemini. To work around this, I exported the capture into a CSV file. (See the link below for the list of supported file formats.)

https://www.datastudios.org/post/google-gemini-file-upload-types-formats-and-capabilities#:~:text=Gemini%20supports%20a%20wide%20variety,seamlessly%20without%20requiring%20separate%20uploads.

As you might expect, I’ve kept the traffic capture intentionally minimal to avoid exposing unnecessary details about my live network, limiting it to basic Google searches and the generation of Microsoft 365/Azure-related traffic. With that in place, let’s get started.

This article is the third instalment in a series examining how AI tools can complement Wireshark to enhance the way network engineers capture, inspect, and analyse network traffic.

Part One – ChatGPT Network Analysis with Wireshark

Part Two – Microsoft Copilot Network Analysis with Wireshark

From the Wireshark Interface, Select the NIC you want to capture traffic from.

Start Capturing Traffic, by selecting Capture/Start.

Keep the capture file to about 500 packets for best results. (if traffic populates too quickly reduce the amount of applications in your taskbar)

Pause the Traffic Capture by selecting Capture/Stop and File/Export traffic and save PCAP file as .CSV file.

Login to Gemini and upload the .CSV file or you could simply copy and paste the .CSV contents into the prompt.

Note you have to give Gemini context of what it’s about to analyse so just enter “Can you analyse my Wireshark Capture?”

So before me even prompting for further analysis Gemini gave me an overview of the capture’s findings.

Note the dollar signs mistakenly prefixed to the IP addresses below were amusing and surprising, given how confident the tool appeared initially.

Gemini <Output>

I can certainly start analyzing your Wireshark capture file, wireshark.csv!

To give you the most useful analysis, I’ll begin by looking at the summary statistics and the most frequent communication patterns.

Initial Summary

Here are some key statistics extracted from the first few rows of your capture:

• Total Frames/Packets: 428 (based on the last numbered frame in the snippet).
• Local IP Address: Your device appears to be 192.168.1.103. This is a private IP address commonly used within a home or small office network.
• Default Gateway/Router: The MAC address Arcadyan_3e:7f:cb is involved in ARP (Address Resolution Protocol) requests, which often indicates the gateway or another device trying to resolve an address.
• Time Duration: The capture spans about 40.5 seconds (from $0.000000$ to $40.558234$).

 Key Protocols & Common Traffic

I’ve analyzed the Protocol column to see what kind of traffic is dominating your network:

1. QUIC (Quick UDP Internet Connections)

• Observation: This is the most prevalent protocol in the provided snippet.
• Implication: QUIC is a transport layer network protocol developed by Google, used heavily by services like Google/YouTube (e.g., $142.250.140.94$, $142.250.151.139$) and often by web browsers for faster, more secure connections than traditional TCP. The Protected Payload (KP0) in the info column means the data inside the QUIC packet is encrypted.

2. ARP (Address Resolution Protocol)

• Observation: Several ARP requests for 192.168.1.241 are being sent by Arcadyan_3e:7f:cb (likely the router/gateway).
• Implication: This is normal network housekeeping, where a device is asking, “Who has this IP address? Tell me your MAC address.” However, if this address (192.168.1.241) is non-existent or misconfigured, excessive ARP requests could indicate an issue or background activity.

3. UDP (User Datagram Protocol)

• Observation: Some UDP traffic is present, including communication with 52.98.207.34 on port 443 (often used for HTTPS, but here over UDP, which is common for QUIC or other encrypted/tunneling services).
• Implication: UDP is often used for fast, connectionless data transfer where a little packet loss is acceptable, like DNS lookups or video/audio streaming (though the ports here suggest encrypted web traffic).

4. TCP (Transmission Control Protocol)

• Observation: There is at least one TCP connection to 74.125.206.188 (also a Google IP address).
• Implication: This is the traditional, reliable, connection-oriented protocol for web browsing, file transfer, and email.

Specific Communication Examples

The majority of the traffic points to your device (192.168.1.103) engaging in heavy, encrypted web activity, most likely with Google-owned services.

Now that the .CSV file is uploaded we going to use the following tried and tested “prompts” to query the Wireshark Capture.  Again, be creative and use prompts that are applicable to your network context.

Prompts I used

• Generate a table of all destination IPs by count?
• Extract HTTP/HTTPS URLs and hostnames from this capture?
• Produce a table mapping each hostname to the IP addresses?
• List the Azure services?
• Create simplified diagram showing application traffic flows?

Below is each prompt directly typed into Google Gemini dialog box and the output generated.

Each of these prompts can be used individually to generate a range of responses from the AI interface.

Sample outputs for each of these are shown below.

Gemini seemed to automatically assume I wanted them in percentage form, which was nice touch.

Gemini Output

Here is a table showing all destination IPs and their respective packet counts from your Wireshark capture:

Key Observations:

Gemini kindly hid my private IP addresses which it didn’t do for the previous prompt, but kept the public IP addresses notation fully viewable. However at no point in its output did it give me an organic URL, but it did give me an explanation for why no URLs were present.

Gemini Output

Result: The capture does not appear to contain any plaintext HTTP (port 80) traffic. All web-related traffic is either QUIC or other encrypted protocols, meaning no URLs or hostnames can be extracted directly from the packet data without the encryption keys.

Now because I didn’t include the word “URL” but rather only “hostname” in the prompt, it shows me all the organic DNS names which seems rather inconsistent.   

Gemini Output

I have analyzed the DNS response packets in your capture to create a table mapping each resolved hostname to its associated IP addresses.

Here are the hostname-to-IP address mappings found:

Summary of Activity

The DNS lookups confirm that during this capture, the device was actively communicating with services related to:

Google Services: Multiple connections to Google Search (www.google.com), Google Play (play.google.com), and the Gemini AI service (gemini.google.com).

VPN/CDN: A lookup for a NordCDN host, likely related to a software update or file download via the CDN77 content delivery network (potentially for NordVPN).

Microsoft/General: Lookups for assets.msn.com, often used for Microsoft content or widgets.

Gemini Output

Based on your Wireshark capture, the explicit traffic to a verified Microsoft Azure IP address (40.99.151.162) consists of a single, continuous TCP connection over port 443.

Since the traffic is on port 443 and uses TCP, it is an encrypted connection (TLS/HTTPS). Without the encryption keys, the exact Microsoft Azure service cannot be determined, but the pattern of the traffic provides strong clues. The traffic consists entirely of your device (192.168.1.103) sending ACK (Acknowledgment) packets back to the Azure server. This is typical of a long-lived, encrypted session where the Azure server is sending data (like a stream or a download) and your device is simply confirming reception of that data.

This IP address belongs to the Microsoft Azure cloud network and is generally used for a vast range of services, including:

• Microsoft Office 365/Teams/OneDrive
• Windows/Xbox/Game Pass services (in addition to the content delivery network (CDN) traffic seen in the DNS analysis)
• General cloud API traffic

Related Microsoft Services (Based on DNS)

While not directly on the Azure IP, the DNS analysis showed activity related to other Microsoft properties, which may also be hosted on Azure infrastructure:

• Xbox Game Pass: DNS lookups for catalog.gamepass.com.
• MSN Assets: DNS lookups for assets.msn.com.

In summary, the capture shows an active, persistent, encrypted connection to a Microsoft Azure Endpoint that is likely maintaining a session for a Microsoft-owned application or service.

Gemini generates a misleading diagram visually polished with all the usual presentation elements, but lacking any meaningful substance. Not a single IP address, port number, or relevant service from my network is represented. It is effectively a generic placeholder image. When selecting the “Explore” option, it attempts to describe the diagram in the context of my network and provide the information I previously requested, yet at no point does it display any IP addresses on the actual diagram.

Gemini <Output>

While I cannot generate an image file directly, I can create a clear, simplified text-based diagram to illustrate the application traffic flows and the key services your device communicated with during the capture.

The flows are summarized based on the protocols and hostnames identified through DNS:

Diagram Flow Breakdown

1. DNS Queries: Your device sends DNS requests (Hostname to IP) to your Local Gateway (192.168.1.254), which then forwards the responses back. This is how all the external connections are initiated.
2. ARP Requests: The Local Gateway repeatedly broadcasts ARP requests for an unknown IP (192.168.1.241). This is local network maintenance and appears to be the only regular local broadcast activity.
3. Google/YouTube: This represents the heaviest traffic flow by packet count. It uses the QUIC protocol, indicating you were likely watching video (YouTube) or heavily browsing/using Google services. The traffic is fully encrypted.
4. Microsoft/Azure: This is a persistent TCP/443 (HTTPS) connection to a verified Azure IP. This is likely a background session for a Microsoft service like Game Pass, Teams, or OneDrive, and the data is fully encrypted.
5. Gaming & CDN: This encompasses traffic associated with:
   • Steam (steamserver.net)
   • Xbox Game Pass (catalog.gamepass.com)
   • NordCDN (downloads77-windows.nordcdn.com) This traffic is used for downloads, updates, and service discovery related to gaming and VPN/CDN activity.

In summary, attempting to use Gemini for network analysis proved to be an unexpectedly arduous and ultimately painful exercise. The platform is, quite frankly, nowhere near a level of maturity required to assist network engineers in deriving meaningful insight from network data. From the very first prompt interaction to the incoherent and aesthetically embellished empty diagram it produced, the experience was defined more by frustration than by functionality in every way. What astonished me most was how readily Gemini provided data that was, just plainly empty with any useful information.

Over the course of this evaluation, I was able to identify only a single instance “Prompt 3 – Produce a table, mapping each hostname to the IP addresses?” in which Gemini delivered material value or demonstrated any analytical capability equal to that of ChatGPT. In several prompts it generated summaries so generic or so contextually misaligned that they contributed virtually nothing to my findings. I found myself repeatedly restating explicit context clues and re-stating information already contained within the provided CSV data.

Final Thoughts:

Gemini for network analysis was a bit like asking a toaster to perform heart surgery. The platform is  to put politely nowhere near the level of competence required to help network engineers derive actual insight from network data, Google has a significant amount of work to do in this domain. Once again ChatGPT continues to demonstrate a substantial lead in AI network-focused analysis.

This article is part of a three part series on WireShark Analysis with AI Tools, Part One (ChatGPT) and Part Two (Copilot) are also available. This article was written by our Senior Collaboration Architect, Dylan James. If you’d like to reach out to Dylan to discuss the article or any similar concepts, he’d be happy to hear from you. Please reach out to us via our contact page and we’ll get you in touch with him.

Thanks for reading.