How one request runs
- Entry: A .pcapng capture
- Orchestration: Pyshark, over Wireshark’s tshark - Pyshark, Wireshark
- In parallel
- Application protocols - HTTP, HTTPS, DNS, FTP, SMTP
- Transport and control - TCP, UDP, ICMP, ARP
- Addressing - IP, Ethernet
- Output: One row per packet - Expandable, and counted into the charts - Tkinter, Matplotlib
Overview
The paper covers how network traffic is analysed and why PCAP became the standard format for it. The application puts that into practice: open a capture, and it shows what each packet carries, protocol by protocol.
Wireshark runs underneath it - Pyshark drives its tshark - and that is what gives the parsing its reach. Built on top, the application asks the same fixed set of questions of every packet in a file and lays the answers out in one place, which is the shape you want when you are looking for something and do not yet know which packet it is in.
Technologies
- Interface
- PythonTkinter
- Capture
- PysharkWireshark
- Charts
- Matplotlib
Architecture
The capture is read once
A file dialog takes a .pcapng or .pcap, Pyshark opens it, and every packet is pulled into a list in memory before the file handle is closed. Nothing reads the file again after that, which is what makes the filters cheap: they re-run over the list rather than re-parsing the capture.
Each packet is walked layer by layer
The protocol names come from the packet’s own layer stack rather than from a lookup, so a packet reports what it actually contains and the tally at the end counts real layers. Twelve extractors then run in sequence, each one asking whether its protocol is present before it touches anything.
Every extractor asks before it reads
A field that a given packet does not carry is not an error but the normal case, so every extractor checks each attribute exists before reading it and simply omits what is absent. That is why the tree is uneven: one HTTP packet shows a dozen fields and the next shows two, and both are correct.
What is in plain text comes out in plain text
HTTP Basic credentials are base64-encoded, not encrypted, so the extractor decodes them. FTP sends its username and password as text, so those come out too. That is the honest demonstration the paper wanted: not a claim that these protocols are insecure, but the decoded string sitting in a tree in front of you.
The results land in a tree and in charts
Each packet becomes one row - timestamp, source and destination IP, length, protocol list - and each row expands into a node per protocol and a leaf per field. The same pass returns a count per protocol, which Matplotlib draws as a pie and a bar chart embedded straight into the window.
What it does
Twelve protocols, per packet
HTTP, HTTPS, DNS, FTP, SMTP, ARP, ICMP, IP, Ethernet, TCP, UDP and FPP, each with its own extractor and its own set of fields.
Filters over five criteria
A date and time range, a source IP, a destination IP, and a comma-separated protocol list. An empty time falls back to the whole day, from 00:00:00 to 23:59:59.
A tree, not a wall of text
Packet, then protocol, then field, and each level opens only when you ask for it, so a capture of thousands of packets stays readable.
Protocol distribution at a glance
A pie chart for the share and a bar chart for the count, redrawn every time a filter is applied, so you can see what a filter actually removed.
Credentials in the clear, shown as such
Decoded HTTP Basic authentication and FTP usernames and passwords, which is the shortest possible argument against using those protocols unencrypted.
Both PCAP generations
The dialog accepts .pcapng and .pcap. The newer format carries more metadata and more interfaces, and reads back through the same code.
What I took from it
The discipline the format forces is what makes this work on any capture you hand it. A packet promises nothing about which fields it holds, so every read is guarded and an absent field is a normal outcome rather than a failure. Writing the twelve extractors out one by one is what keeps that explicit, and it is why a two-packet capture and a two-thousand-packet one go through the same code with no special case.
Reading the capture once is what makes the rest feel immediate. Every filter, every recount and every redrawn chart works from the list already in memory, so changing a date or an IP address returns a new view of the same capture straight away instead of going back to the file.