There's a big difference between knowing a network tool exists and actually sitting down, running it, watching the packets pile up, and then making sense of what you captured. This post walks through exactly that — installing Daemonlogger on Kali Linux, generating real mixed traffic using ping, curl, iperf3, and a browser, then loading the .pcap file into Wireshark and pulling out meaningful numbers.

Everything here is from my own hands-on session. The screenshots are real, the packet counts are real, and the mistakes I made along the way were very real too.

Why Daemonlogger?

Most people reach for Wireshark when they want to capture traffic. That's fine for short sessions, but Wireshark's live capture is heavy — GUI, real-time rendering, constant screen updates. Daemonlogger is the opposite: a lightweight, command-line tool that runs quietly in the background and writes everything to a .pcap file. No GUI, no overhead. You generate traffic, stop it when you're done, and then open the file in Wireshark to analyze at your own pace.

For anything resembling real-world passive monitoring, that's a much cleaner workflow.

Environment

  • OS: Kali Linux 2026.1 (Oracle VirtualBox)
  • Network Interface: eth0 — IP 10.0.2.15
  • Tools used: daemonlogger, iperf3, curl, ping, Firefox browser, wireshark

Step 1 — Install Daemonlogger 

sudo apt-get install daemonlogger -y
Enter fullscreen mode Exit fullscreen mode

After installation, run it with --help to confirm it's working and to review the available flags:

daemonlogger --help
Enter fullscreen mode Exit fullscreen mode

The key flags you'll use most:

Flag Purpose
-i <intf> Capture from this network interface
-l <path> Write log files to this directory
-n <name> Set the output filename prefix
-d Daemonize (run in background)

Step 2 — Identify Your Network Interface

Before starting any capture, confirm which interface is active and note its IP address.

ip link show
ifconfig
Enter fullscreen mode Exit fullscreen mode

In my setup, eth0 was the active interface at 10.0.2.15. The loopback lo was also present but not useful for capturing external traffic.

Step 3 — Create Log Directory and Start Capture

Create the directory where Daemonlogger will save the .pcap file:

sudo mkdir /var/log/daemonlogger
Enter fullscreen mode Exit fullscreen mode

Then start the capture:

sudo daemonlogger -i eth0 -l /var/log/daemonlogger/ -n capture
Enter fullscreen mode Exit fullscreen mode

Once you see "sniffing on interface eth0" and the .pcap filename appear, Daemonlogger is running and capturing everything. Leave this terminal open and move on to generating traffic.

Step 4 — Generate Traffic

ICMP — Ping 

ping google.com -c 50
Enter fullscreen mode Exit fullscreen mode

The ping resolved google.com to 142.250.187.78 and sent 22 packets before I stopped it. Zero packet loss. The curl to testph.vulnweb.com on port 80 timed out with a connection error — that attempt still generated DNS + TCP SYN traffic worth capturing.

HTTP — curl 

curl http://testph.vulnweb.com
Enter fullscreen mode Exit fullscreen mode

Even a failed connection creates traffic. DNS resolution, TCP handshake attempts, and RST/timeout packets all end up in the capture file.

TCP Throughput — iperf3

Open two terminals. In the first, start the iperf3 server:

iperf3 -s
Enter fullscreen mode Exit fullscreen mode

In the second, connect as a client:

iperf3 -c 127.0.0.1 -t 30
Enter fullscreen mode Exit fullscreen mode

The iperf3 test pushed ~43–46 Gbits/sec over loopback for 30 seconds. This floods the capture with a burst of TCP segments that show up clearly later in the IO Graph.

Website Visits — Browser

With Daemonlogger still running, I opened Firefox inside the Kali VM and visited several sites — including an intentionally unencrypted HTTP site:

http://neverssl.com
Enter fullscreen mode Exit fullscreen mode

NeverSSL is designed specifically for this — it never redirects to HTTPS, so the full HTTP request and response are visible in the capture as plain text.

Step 5 — Stop Capture and Check the File

Stop Daemonlogger with:

sudo pkill daemonlogger
Enter fullscreen mode Exit fullscreen mode

Then check what was saved:

ls -lh /var/log/daemonlogger/
Enter fullscreen mode Exit fullscreen mode

Result: 13,439 packets captured in a 9.6 MB file. Zero drops — the system kept up with every single packet.

Step 6 — Install Wireshark and Open the File 

sudo apt-get install wireshark -y
wireshark /var/log/daemonlogger/capture*.pcap
Enter fullscreen mode Exit fullscreen mode

Wireshark loaded the full 13,439-packet capture without any issues.

Step 7 — Wireshark Analysis

HTTP Traffic

Display filter:

http
Enter fullscreen mode Exit fullscreen mode

HTTP packet count: 25 (0.2% of total capture)

HTTPS Traffic

Display filter:

ssl || tls
Enter fullscreen mode Exit fullscreen mode

HTTPS packet count: 1,833 (13.6% of total capture)

TCP Traffic

Display filter:

tcp
Enter fullscreen mode Exit fullscreen mode

TCP packet count: 11,739 (87.4% of total capture)

This makes sense — HTTP, HTTPS, and iperf3 all run over TCP. Filtering tcp captures all of them plus the raw handshakes and teardowns.

Top Conversations

Navigate to: Statistics → Conversations → TCP tab

The machine at 10.0.2.15 was the top talker — all outbound traffic originated here. Top destinations:

Source IP Destination IP Port
10.0.2.15 34.107.243.93 443
10.0.2.15 34.223.124.45 80
10.0.2.15 34.223.124.45 443
10.0.2.15 44.228.249.3 443

Top Protocols by Usage

Navigate to: Statistics → Protocol Hierarchy

Protocol % of Packets
TCP 100%
HTTP 8.7%
OCSP 8.7%
ICMP present in unfiltered view

IO Graph

Navigate to: Statistics → I/O Graph

The IO graph tells the timing story of the entire session:

  • Spike at ~250s — the 30-second iperf3 burst pushing thousands of TCP segments per second
  • Quiet baseline — background HTTPS traffic from browser activity
  • Late spike near ~1000s — the NeverSSL and other website browsing sessions generating another burst

Capturing Login Credentials over HTTP

For any site using plain HTTP (no TLS), Wireshark can show form submissions in full. Apply this filter to find POST requests:

http.request.method == "POST"
Enter fullscreen mode Exit fullscreen mode

Then right-click any matching packet → Follow → HTTP Stream to read the complete request body, including any username and password fields submitted through an HTML form.

This is exactly why HTTPS matters. The same capture on an HTTPS connection shows only encrypted TLS Application Data — credentials are completely invisible.

Results Summary

Metric Value
Total packets captured 13,439
Capture file size 9.6 MB
HTTP packets 25 (0.2%)
HTTPS / TLS packets 1,833 (13.6%)
TCP packets 11,739 (87.4%)
Packets dropped by kernel 0
Top source IP 10.0.2.15
Top destination ports 443, 80

How to Verify

Step What to check
Daemonlogger started Output shows "sniffing on interface eth0"
Packets being captured .pcap file grows in size while traffic runs
Clean stop Output shows exact packet count and zero drops
Wireshark loads file Packet list populates, no parse errors
http filter Returns GET/POST/response packets
`ssl \ tls` filter
tcp filter Returns ~87%+ of all packets
Conversations tab Shows source/dest IP pairs with port numbers
IO Graph Shows visible spikes at iperf3 burst timing

What I Learned

Going through this hands-on made a few things click that reading never quite did:

TCP is everywhere. Filtering tcp returns 87% of the capture because HTTP, HTTPS, iperf3, and most real-world traffic all run over TCP. The protocol isn't just one thing — it's the transport layer underneath almost everything.

Daemonlogger is better than live Wireshark for background capture. No GUI overhead, no rendering lag, just packets written to disk. For any kind of monitoring scenario, that matters.

Plain HTTP credentials are genuinely, immediately visible. Not "theoretically exposed" — actually readable, in plain text, in a filter result. Seeing it in Wireshark removes any remaining abstract quality from the risk.

IO graphs are often the first place to look. When something unusual happens on a network, the IO graph shows when it happened before you've read a single packet. The iperf3 spike is unmistakable — it's the tallest feature on the graph.

Zero packet drops is worth celebrating. At 43–46 Gbits/sec of iperf3 traffic, the Kali VM kept up with every single packet. That's worth noting because packet drop is a real issue in high-throughput capture environments.

Common Mistakes

Mistake What happens Fix
Running daemonlogger without sudo Permission denied — raw socket access requires root Always prefix with sudo
Skipping mkdir for the log directory Daemonlogger exits immediately with path error Create the directory first
Wrong interface name No packets captured — capture starts but file stays empty Verify with ip link show before starting
Opening .pcap before killing daemonlogger Wireshark shows truncated/incomplete data sudo pkill daemonlogger first, then open
Using only ssl filter Misses QUIC and TLSv1.3 in newer captures Use `ssl \
Expecting to see HTTPS credentials Empty results from POST filter Credential visibility only works on plain HTTP

Conclusion

The full workflow — Daemonlogger for silent capture, mixed traffic from {% raw %}ping, curl, iperf3, and real browser sessions, then Wireshark for structured analysis — gives you a complete picture of what's happening on a network interface. The numbers from this session (13,439 packets, 87.4% TCP, 1,833 TLS packets, 25 HTTP packets, zero drops) aren't just statistics. They show exactly how a modern endpoint behaves: mostly encrypted HTTPS, with TCP as the invisible backbone underneath all of it, and a small but meaningful slice of plain-text HTTP that should never carry sensitive data.

If you want to actually understand network traffic rather than just read about it, start here. Capture it, count it, follow the streams, and look at the IO graph. The packets tell the whole story.