Introduction & Concept
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.)
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
Step One
From the Wireshark Interface, Select the NIC you want to capture traffic from.

Step Two
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)

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

Step Four
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?”

- 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$).
- 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.
- 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.
- 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).
- 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.
| Source | Destination | Protocol | Activity |
| 192.168.1.103 | 142.250.x.x | QUIC | Heavy communication with Google/YouTube servers (very likely web browsing or video viewing). |
| Arcadyan_3e:7f:cb | Broadcast | ARP | Repeatedly asking for the MAC address of 192.168.1.241. |
Step Five
- 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?
Example Prompts
- 1) Generate a table of all destination IPs by count
- 2) Extract HTTP/HTTPS URLs and hostnames from this capture
- 3) Produce a table mapping each hostname to the IP addresses
- 4) List the Azure services
- 6) Create simplified diagram showing application traffic flows
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.
1) Generate a table of all destination IPs by count
| Destination IP | Count | Percentage | Notes |
| 192.168.1.103 | 204 | 46.68% | Local Device Traffic (Your Device): This is likely your device receiving responses from external servers (the vast majority of packets are responses to the traffic you initiated). |
| Broadcast | 43 | 9.84% | Network Housekeeping: These are packets sent to all devices on your local network (e.g., ARP requests). |
| 52.98.207.34 | 26 | 5.95% | External Server: Commonly associated with Amazon Web Services (AWS). |
| 142.250.140.94 | 19 | 4.35% | Google/YouTube: A common IP for Google services. |
| 192.168.1.254 | 14 | 3.20% | Local Gateway/Router: Likely the default gateway for your network, receiving packets from your device. |
| 142.250.151.139 | 14 | 3.20% | Google/YouTube: Another common IP for Google services. |
| 142.251.30.100 | 12 | 2.75% | Google/YouTube: Another common IP for Google services. |
| 81.134.107.209 | 12 | 2.75% | BT Group (UK ISP): Likely related to DNS or other services from your Internet Service Provider. |
| 81.134.107.216 | 9 | 2.06% | BT Group (UK ISP): Likely related to DNS or other services from your Internet Service Provider. |
| 40.99.151.162 | 8 | 1.83% | Microsoft Azure: A common IP for Microsoft services. |
| (17 other IPs) | 76 | 17.40% | All remaining traffic. |
Key Observations:
- The largest destination by far is 192.168.1.103, which is your device (the source of most requests). This confirms the capture is primarily showing you browsing or streaming, as traffic flowing to your device will naturally be the highest count.
- Google/YouTube is the Main External Activity: The three Google-owned IP ranges (142.250.x.x and 142.251.x.x) make up a significant portion of the external connections, reinforcing the initial finding that QUIC (a Google protocol) is heavily used.
- ISP Activity: The presence of 81.134.107.x (BT Group) confirms that your device is communicating with your ISP's infrastructure, most likely for DNS resolution.
2) Extract HTTP/HTTPS URLs and hostnames from this capture
| Destination IP Range | Likely Host/Service | Protocol | Evidence |
| 142.250.x.x | Google / YouTube | QUIC / TCP | Heavy traffic, using the Google-developed QUIC protocol. |
| 142.251.x.x | Google / YouTube | QUIC | Heavy traffic, using the Google-developed QUIC protocol. |
| 52.98.207.34 | Amazon Web Services (AWS) | UDP | High volume of UDP traffic to a common cloud provider IP. |
| 40.99.151.162 | Microsoft Azure | TCP | Connection to a common cloud provider IP. |
3) Produce a table, mapping each hostname to the IP addresses
| Hostname | IP Address | Service |
| assets.msn.com | 81.134.107.240 | Microsoft / ISP (BT Group) |
| beacons.gcp.gvt2.com | 142.250.140.94 | Google (Google Cloud Platform beacon) |
| catalog.gamepass.com | 81.134.107.202 | Xbox Game Pass / ISP (BT Group) |
| downloads77-windows.nordcdn.com | 84.17.50.24 | CDN77 / NordVPN (File Download) |
| gemini.google.com | 142.250.151.113 | Google (AI Service) |
| play.google.com | 142.251.30.101 | Google (Play Store/Services) |
| www.google.com | 216.239.38.120 | Google (Search) |
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.
5) List the Azure services
| IP Address | Protocol | Destination Port | Traffic Type | Inferred Service Category |
| 40.99.151.162 | TCP | 443 | Encrypted (TLS/HTTPS) ACK/Control | Microsoft Azure Cloud Services |
- 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
- Xbox Game Pass: DNS lookups for catalog.gamepass.com.
- MSN Assets: DNS lookups for assets.msn.com.
6) Create simplified diagram showing application traffic flows
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:


- 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.
- 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.
- 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.
- 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.
- 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.
Conclusion
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.
Feedback & Further Discussion
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.
