You can attach a packet capture to a chat in aimo and ask about it in plain words: “why is this download slow?”, “which connections were reset?”, “is DNS failing?”. The model does not read the file itself. It hands the file to Wireshark through a tool server, and answers from Wireshark’s own numbers.
This article follows one capture from the upload to the answer, so that an administrator can see what is protecting the file and a user can see what to expect. It describes version 0.2.1 of the packet-capture server, checked against the running product on 5 October 2026.
Who does what
| What | Who | Where |
|---|---|---|
| Allow people (or API keys) to use the capture tools | Administrator | Console, /mcp → the packet-capture server → Access |
| Show the server in aimo to those people | Administrator | Same editor, Show in aimo, then Sync aimo now |
| Attach a capture and ask about it | Each person | aimo chat |
| Switch the capture tools on for the chat | Each person | The chat’s Integrations menu → Tools |
What you can attach
Files ending in .pcap, .pcapng or .cap, and the same three with .gz. A capture
is a binary file with no text in it, so aimo’s document reader cannot process it.
A warning toast about the file format appears when you attach one. That is expected
and does not mean the upload failed.
Aimo hands the tools at most 12 MiB per upload. For a bigger file, split it first
with Wireshark’s editcap -c, which cuts a capture into pieces of a given packet
count.
The request, one step at a time
- You attach the capture. aimo stores the file. Its document reader fails on it, which causes the toast above.
- A filter prepares the chat. A global filter, Packet Capture Uploads, takes the
capture out of the document-search path, so no search query is wasted on a binary
file. It adds one note for the model that names the file as
aimo-file:<id>and lists the tools to call, starting withanalyze_capinfosandanalyze_expert_info. If the capture tools are not switched on in the chat, the note tells the model to say so, and the model tells you to switch on Packet capture analysis (mcpcap) in the Tools menu instead of guessing. - The model calls a tool with the id. It never receives the bytes, only the id.
For example it calls
analyze_tcp_retransmissionswithpcap_file = "aimo-file:<id>". - The platform checks the call. The call passes through the platform’s governed relay. It checks that the calling person (or API key) holds a grant, scans the arguments against the policy rules, writes an audit record and attaches a short-lived signed statement of who is calling. A caller with no grant receives the same “not found” answer that a server that does not exist would give, so nobody can discover the server by probing.
- The server fetches your file, and only yours. The packet-capture server verifies the signed statement, then asks the platform for the upload. It opens the file only when the uploader’s e-mail address equals the verified caller’s. Someone else’s file reads exactly like a missing file and is refused before anything is stored.
- Wireshark analyses it. The server runs
tsharkandcapinfosin a restricted sandbox. The result comes back through the same path, and the model writes its answer from it.
Why Wireshark does the counting
An earlier version used the analysis code of the open-source mcpcap project. On a real capture of a slow download, taken at the client, it reported zero retransmissions. Asked again with the threshold set to zero, the model confirmed zero. Wireshark counts 153 retransmitted or out-of-order segments in the same file, 911 duplicate acknowledgements, and a 32.66 second stall that contains all seven of the client’s zero-window advertisements, meaning the client had stopped reading.
The cause was a rule: a segment counted as retransmitted only if it overlapped bytes already captured. When the loss happens before the capture point, which is the usual case when you capture at the client, the original packet never appears, so every retransmission fills a gap and none overlaps. The tool answered the common case with full confidence and was wrong.
Since version 0.2.0 every TCP verdict is Wireshark’s own tcp.analysis.* flag, read
as it is. A 150,000-packet capture also takes about 11 seconds instead of one to two
minutes.
One thing to know when you compare against your own Wireshark. Different Wireshark versions split the same segments between retransmission and out-of-order differently: version 4.4.19, which the server runs, reports 88 and 65 on that capture, and 4.6.9 reports 79 and 74. The sum, 153, is the same. The results therefore quote the sum and the Wireshark version they came from.
What the server cannot reach
The packet-capture server can reach the platform and DNS, and nothing else: no
internet, no local network, and no other services. It accepts no file path and no web
address, only an aimo-file: id or a capture embedded in the request. A server that
reads private files and can also reach the internet is one malicious capture away from
leaking them, so the second half is simply not there.
Each analysis runs with name resolution switched off, so the addresses in a capture are never turned into DNS queries. It gets its own empty configuration, a memory limit, a time limit of 80 seconds and a read limit of 500,000 packets, so one bad capture costs one failed call and not the service. Anything written inside the capture, such as host names or HTTP headers, was written by whoever sent the packets. Each result lists those strings as untrusted and the model is told not to act on them.
Who is allowed to use it
The server starts closed: nobody can call it until an administrator adds people on /mcp → Access. A grant names either a person or an API key, and either is enough.
| Caller | Capture embedded in the request | aimo upload |
|---|---|---|
| A granted person in aimo | Yes | Yes, their own uploads only |
| A granted API key with no person behind it | Yes | No |
| Neither | Refused, as if the server did not exist | Refused |
A key with no person cannot open an aimo upload, because the owner check needs a person to compare against.
Two cautions for administrators. Granting a shared key grants everyone behind it, so the editor flags aimo’s own service key as one that grants every aimo user: grant aimo people as people. And Open WebUI administrators see every tool connection in the list, but the platform still refuses their calls unless they hold a grant.
What to try
With the tools switched on, attach a capture and ask:
- “Give me an overview of this capture and anything Wireshark flags as wrong.”
- “Are there TCP retransmissions or zero-window events, and when do they start?”
- “Which hosts talk the most, and what protocols do they use?”
- “Did any DNS query fail? Show the names.”
- “Show me the packets between 203.0.113.5 and 203.0.113.9 on port 443.”
The last one uses query_packets, which accepts any Wireshark display filter. If the
model names a field that does not exist, the server answers with the closest real
names, so the model can correct itself instead of telling you the value is unavailable.
Limits
- 12 MiB per upload through aimo.
- Encrypted payloads, such as TLS or SIP over TLS, are only as visible as Wireshark makes them without keys. There is no way to supply a key log.
- A person who was just granted access and has not yet signed in to aimo appears in the tool’s access list after the next sync, within about 15 minutes of their first sign-in.
- The model’s summary is only as good as the tool results it asked for. If a number matters, ask the model which tool and which filter produced it.
Seen working
On 4 October 2026 a 94-packet capture with faults planted in it was attached to a new chat by an ordinary user. The model called nine tools. All nine were recorded as allowed in the audit trail, taking 1.3 to 2.0 seconds each. It reported that six of six connection attempts to one port had been reset by the server, four retransmissions on one HTTPS connection (5.0 per cent of its segments), a failed name lookup, and a host reported unreachable. Those were the planted faults.