The last time I reached for ngrep, I wasn’t trying to become a packet-analysis hero—I was trying to answer one blunt question: “Is the request actually leaving this host, and what does the payload look like right before it disappears into the network?” Logs were delayed, metrics were averaged, and the service was deployed in a way that made “just attach a debugger” a fantasy.
ngrep is the tool I use in that moment because it feels like putting grep on the wire. Instead of searching files, you search packet payloads as they cross an interface. You can match with extended regular expressions or with hex patterns, and you can combine that with classic capture filters (the same style you’d use with tcpdump).
If you’ve ever tailed logs while thinking “the evidence has to be on the network,” this is the workflow: pick the interface, narrow by protocol/host/port, then match the exact bytes you care about. I’ll show you how I run ngrep safely, how I build filters that stay readable under pressure, and how I apply it to real troubleshooting in 2026-era Linux environments (containers, systemd, TLS everywhere).
What ngrep is (and what it is not)
ngrep sits in a sweet spot between “raw capture tools” and “application logs.” It captures packets via libpcap and then searches inside packet payloads for patterns—either regex or hex expressions. If you’ve used tcpdump and then piped it through text tools, ngrep is the shortcut you wanted.
Here’s the mental model I keep:
tcpdumpanswers: “What packets exist, and what do the headers look like?”- Wireshark/tshark answers: “How do I decode protocols and reconstruct conversations?”
ngrepanswers: “Do these packets contain this string or byte sequence right now?”
That means ngrep shines when the payload is visible (plain HTTP, many internal protocols, syslog over UDP/TCP, custom text protocols, some binary protocols where you know a magic value). It struggles when payloads are encrypted (HTTPS, most modern service-to-service traffic), compressed, or segmented across multiple packets in a way that makes a single match unreliable.
Protocol-wise, you’ll see it used with IPv4/IPv6 over TCP/UDP/ICMP, and it can also operate on “raw” traffic depending on the interface.
A key limitation to internalize: packet payloads are not streams
I treat this as the “don’t lie to yourself” rule.
ngrep matches against packet payloads as they appear, not against a reconstructed TCP stream. If the string you care about is split across packets (very common with larger headers, larger JSON bodies, HTTP/2 frames, and basically anything under load), your perfect regex can produce “no matches” even though the request absolutely happened.
My workaround is pragmatic:
- First prove the flow exists (host/port/proto) with a broad payload match like
‘.‘. - Then match smaller, more reliably-contained tokens (method line, a single header name, a short magic prefix), not a long sentence.
- If I truly need full reassembly, I stop fighting and switch to a stream-aware toolchain (pcap + Wireshark/tshark) or application-level tracing.
Install and run it safely (modern Linux habits)
On most distros, ngrep is a package away:
# Debian / Ubuntu / Kali
sudo apt-get install ngrep
# Arch
sudo pacman -S ngrep
# Fedora
sudo dnf install ngrep
Root vs capabilities
Packet capture usually requires elevated permissions. My default is still sudo ngrep ... because it’s predictable and matches the “I’m debugging now” reality.
If you want a tighter posture for routine use, consider Linux capabilities so you don’t run the full process as root. The idea is to grant only what’s needed to capture packets (and only to that binary).
Common pattern (paths vary by distro):
# If your distro installs ngrep in /usr/bin/ngrep
sudo setcap capnetraw,capnetadmin=eip /usr/bin/ngrep
# Verify
getcap /usr/bin/ngrep
I treat this like production plumbing: do it intentionally, document it, and review it during security audits.
Pick the right interface first
When ngrep “shows nothing,” the most common reason is that you’re listening on the wrong interface.
Quick checks:
ip link
ip route
Then run with an explicit device:
# Common interfaces: eth0, ens160, wlan0, lo
sudo ngrep -d eth0
If you truly don’t care which interface (or you’re on a host with many), -d any can be useful:
sudo ngrep -d any
I avoid -d any on very busy nodes unless I also apply a capture filter, because it can generate a flood of matches you’ll never read.
Promiscuous mode (don’t enable it by accident)
By default, capture tools may put the interface into promiscuous mode. If you’re debugging only host traffic and want to avoid that, add -p:
sudo ngrep -p -d eth0
In many environments (VMs, cloud instances, locked-down networks), promiscuous mode either won’t help or will trigger security noise. I enable it only when I have a reason.
Keep ngrep from turning into a data-leak machine
When I’m working on production-ish systems, I follow a strict safety checklist before I hit Enter:
- Start with the smallest possible BPF filter: a single host, a single port, a single protocol.
- Prefer matching on “structural” tokens (
GET,Host:,User-Agent:) over secrets (Authorization, cookies, full JSON bodies). - Use
-W bylineso I can stop early; it makes scanning faster and reduces the temptation to dump everything. - If I must save a capture, save only matched packets (not the entire interface firehose), and delete it under whatever policy governs sensitive data.
This is less about paranoia and more about not creating an incident while debugging one.
The command shape I memorize
I keep this template in my head:
sudo ngrep [options] ‘pattern‘ [bpf-filter]
Two key pieces:
1) The pattern: what to match inside the payload.
- Regex:
‘errorfail timeout‘
- “Match anything” (useful as a payload/flow viewer):
‘.‘ - Hex patterns (when the payload isn’t text):
-X ‘16 03 01‘(example bytes)
2) The BPF filter: what packets to consider at all.
tcp and port 80udp and host 10.0.1.15 and port 5514icmp
If you do only one thing to make ngrep pleasant: use capture filters aggressively. It reduces noise and reduces the amount of work ngrep has to do.
Options I use constantly
-qquiet: suppresses the “reception hash marks” and other chatter so you see matches.-ttimestamps matches (useful for correlating with logs and traces).-Tdelta timestamps: prints time since the previous match (and with a second-T, time since the first match).-dchoose interface.-W bylineoutput mode that respects linefeeds, making HTTP and text protocols readable.
Example of a sane default for text protocols:
sudo ngrep -q -t -W byline -d eth0 ‘.‘ ‘tcp and port 80‘
Yes, that ‘.‘ looks odd. It means “match any payload,” turning ngrep into a quick payload viewer while the BPF filter keeps it under control.
Output modes: normal, byline, single, none
I’ve learned to pick output mode based on what I’m trying to do:
-W normal: default wrapping; fine, but I rarely choose it explicitly.-W byline: best for HTTP-ish text protocols; it wraps at embedded linefeeds.-W none: puts the entire payload on one line (useful when you’re copying and searching, but it can get wide fast).-W single: likenone, but includes header info on the same line (useful when you’re grepping ngrep output).
These modes are for non-hex output; when I’m in a hexdump view (-x) I don’t rely on -W.
“I need this to be scriptable” options
When I’m chaining tools, I’m usually reaching for a few flags that make output more predictable:
-lline-buffered stdout: helps when piping into another process so I don’t wait on buffering.-nstop after N packets: keeps ad-hoc commands from running forever.-Aalso dump N packets after a match: great when the first matching packet is just the “marker” and the next packet contains the interesting bytes.
For example, when I’m hunting for a short marker string but I actually want the following request body:
sudo ngrep -q -t -W byline -A 5 ‘X-Debug-Trace-Id:‘ ‘tcp and host 10.0.2.25 and port 8080‘
Snap length vs “how much payload do I actually see?”
Two knobs matter when payloads look truncated:
-ssets the capture length at the pcap layer (how many bytes are captured per packet).-Ssets an upper limit on how many bytesngreplooks at for matches/output (useful when you want to ignore huge bodies).
My typical approach:
- If I’m missing payload that I expect to see, I increase
-s. - If I’m drowning in large payloads, I cap with
-S.
Regex and hex patterns that hold up in real life
Most people start with “match the word I care about,” and that’s fine. But once you’re debugging modern services, you often want patterns that are:
- short (to reduce packet-splitting misses)
- stable (won’t change across deploys)
- safe (don’t print secrets)
Here are the patterns I’ve found worth memorizing.
Case-insensitive and word matches
If you’re scanning human text like logs-over-UDP or legacy protocols, -i and -w are surprisingly useful:
# Ignore case
sudo ngrep -q -t -W byline -i ‘error
panic‘ ‘udp and port 5514‘
# Word match (avoid matching inside other tokens)
sudo ngrep -q -t -W byline -w ‘error‘ ‘udp and port 5514‘
Invert match (when you want to see everything except the noise)
I reach for -v when there’s a predictable “spam” pattern and I want to focus on what remains:
# Show everything on port 80 except health checks
sudo ngrep -q -t -W byline -v ‘GET /healthz‘ ‘tcp and port 80‘
That command is dangerous in two ways: it can still print sensitive payloads, and it can still be a lot of output. I only do it with tight BPF filters (single host, single service) and I stop it quickly.
Matching HTTP without reading full bodies
When I want maximum value with minimum risk, I match only the request line and a small set of headers.
Request lines:
sudo ngrep -q -t -W byline ‘^GET
^PUT^DELETE ‘ ‘tcp and port 80‘
A specific header name (not the value):
sudo ngrep -q -t -W byline ‘^Host:
^Content-Type:‘ ‘tcp and port 80‘
If you’re in an environment with proxies or multiple virtual hosts, Host: alone can be enough to prove routing.
Hex matching for binary protocols
When payloads aren’t text, -X switches the match expression to a hexadecimal string.
A pattern I actually use: match on the beginning of a TLS record to prove “this is TLS-ish traffic,” even if I can’t decrypt it. (This is not a TLS parser; it’s just a quick byte-level sanity check.)
sudo ngrep -q -t -x -X ‘16 03‘ ‘tcp and port 443‘
A few notes from hard-won mistakes:
- Hex matching is about presence, not correctness. It can produce false positives if you’re too broad.
- Pair hex matching with a BPF filter that’s already narrow.
- If you’re looking for an application “magic” value, match the shortest unique prefix that you can justify.
The “marker + context” trick
One of my favorite workflows is:
1) Match a marker header or token that’s easy to inject (a request ID).
2) Use -A to capture a few packets after the match.
3) Use -O to save only those matched packets for offline review.
Example:
sudo ngrep -q -t -W byline -A 10 -O /tmp/trace-matches.pcap ‘X-Trace-Id: 7f3c2e‘ ‘tcp and host 10.0.2.25 and port 8080‘
That gives me something I can hand to a teammate (“here are the packets that contain the marker”) without capturing everything.
Building BPF filters that don’t lie
If your patterns are the “grep,” your BPF filters are the “find the right haystack.” I try to make BPF filters so specific that they read like a sentence.
My default BPF filter building order
When I’m stressed, I follow a checklist so I don’t forget the obvious:
1) Protocol: tcp, udp, icmp
2) Directional constraint (if useful): src host, dst host, src port, dst port
3) Host identity: host 10.0.2.25 (prefer IP during incidents)
4) Port identity: port 8080
5) Add only then: network ranges, interface-wide traffic, OR logic
Example for a single upstream:
sudo ngrep -q -t -W byline ‘.‘ ‘tcp and dst host 10.0.2.25 and dst port 8080‘
Example for “traffic from a container IP to the DB on 5432”:
sudo ngrep -q -t ‘.‘ ‘tcp and src host 172.17.0.5 and dst port 5432‘
I’ll often start without the payload match at all (or with ‘.‘) until I’m sure the BPF filter is correct.
Use parentheses early (future-you will thank you)
BPF parsing rules can surprise you if you assume normal boolean precedence.
I prefer:
sudo ngrep -q -t -W byline ‘.‘ ‘(tcp and port 80) and (host 10.0.2.25 or host 10.0.2.26)‘
…over clever one-liners that become uneditable.
Filter files for runbooks
If a filter gets long enough that it’s painful on the shell prompt, I’ll put the BPF portion in a file and use -F:
# /tmp/http-filter.bpf
tcp and port 80 and host 10.0.2.25
sudo ngrep -q -t -W byline ‘.‘ -F /tmp/http-filter.bpf
Targeted recipes I actually use
This is where ngrep pays rent: small, focused commands that answer a specific question.
1) Watch ICMP while you test reachability
If you’re doing a ping and want to confirm ICMP is flowing:
sudo ngrep -q ‘.‘ ‘icmp‘
What I look for:
- Requests leaving and replies coming back.
- Whether the traffic is on the interface I expect.
If I see requests but no replies, I stop blaming the application.
2) Filter by host (and keep it readable)
Host filters are great when you’re proving “this box talks to that box.”
sudo ngrep -q -t -W byline ‘.‘ ‘host 142.250.72.14‘
(When time is tight, I pin an IP because DNS can resolve to many addresses.)
3) See plain HTTP requests (port 80)
If you still have any HTTP in your world—internal health checks, legacy endpoints, sidecar-to-sidecar debug—ngrep is the fastest way to confirm request lines and headers.
sudo ngrep -q -t -W byline ‘^GET .* HTTP/1\.[01]‘ ‘tcp and port 80‘
If you want to view all HTTP payload lines (not just the request line):
sudo ngrep -q -t -W byline ‘.‘ ‘tcp and port 80‘
4) Confirm traffic on a specific port (443, 514, your own)
Port filtering is the bread-and-butter move:
sudo ngrep -q -t ‘.‘ ‘port 443‘
Two important notes:
- On
443, you generally won’t see “GET” or JSON. You’ll see TLS records (binary). - This still helps to prove “connections exist” and to correlate timing.
Syslog example (search for the word error):
sudo ngrep -d any -q -t -W byline ‘error‘ ‘port 514‘
5) Use service names from /etc/services
If you prefer names over numbers and your distro maps it:
sudo ngrep -d any -q -t -W byline ‘error‘ ‘port syslog‘
I still recommend numbers in runbooks because they’re unambiguous across environments, but names are nice when you’re working interactively.
6) A complete, runnable demo: generate traffic, then match it
When I teach teams this tool, I like a demo that doesn’t require external dependencies.
Terminal A (listen for messages on UDP port 5514):
sudo ngrep -q -t -W byline ‘error
panic‘ ‘udp and port 5514‘
Terminal B (send a few UDP messages):
python3 – <<'PY'
import socket
import time
addr = ("127.0.0.1", 5514)
messages = [
"service=checkout level=info msg=started",
"service=checkout level=warn msg=slow response 180ms",
"service=checkout level=error msg=payment gateway timeout",
]
sock = socket.socket(socket.AFINET, socket.SOCKDGRAM)
for m in messages:
sock.sendto(m.encode("utf-8"), addr)
time.sleep(0.2)
print("sent")
PY
What this proves:
- Your regex is working.
- Your capture filter is working.
- You can reproduce results without a whole stack running.
7) Catch a request ID at the edge (reverse proxies and gateways)
In real services, I often don’t care about the whole request; I care about one correlation token.
If you have an ingress proxy adding a request ID header (or you can inject one from a client), match the header name and a short prefix, then capture a little context.
sudo ngrep -q -t -W byline -A 10 ‘X-Request-Id: (abc
ghi)‘ ‘tcp and port 80 and host 10.0.2.25‘
This is the closest thing I have to “poor man’s tracing” when tracing is broken.
8) Verify an outbound webhook payload is leaving the host
When a service “fires a webhook” and the receiver says “we never got it,” I do two checks:
1) Does the TCP flow exist?
sudo ngrep -q -t ‘.‘ ‘tcp and dst host 203.0.113.10 and dst port 443‘
2) If it’s plain HTTP (rare but still happens internally), does the request line exist?
sudo ngrep -q -t -W byline ‘^POST ‘ ‘tcp and dst host 203.0.113.10 and dst port 80‘
If step (1) shows nothing, I stop arguing about app code and start looking at routing, DNS, firewalls, proxies, or egress policy.
TLS everywhere: how I use ngrep without lying to myself
In 2026, most payloads are encrypted. That’s good for users, but it changes what “packet payload search” means.
If you point ngrep at tcp and port 443 and search for Authorization: or JSON keys, you’ll see nothing—not because the traffic isn’t there, but because it’s not plain text.
Here’s how I stay effective anyway:
1) Use ngrep to confirm timing and presence, not content.
sudo ngrep -q -t ‘.‘ ‘tcp and port 443 and host 10.0.2.25‘
I’m watching for:
- Handshakes that happen when I expect.
- Any application-data-sized packets moving in both directions.
- Connection resets that correlate with errors.
2) Match on unencrypted adjacent signals when available.
Examples include:
- Plain HTTP on internal links (still happens in some orgs).
- DNS queries (often visible unless you’re using DoH/DoT everywhere).
- Syslog/metrics traffic that remains plaintext on trusted networks.
3) If I truly need decrypted content, I switch tools.
Depending on what’s allowed:
- Capture with
tcpdumpand inspect with Wireshark/tshark using session keys. - Use application-level tracing and structured logs.
- Use eBPF-based observability where policy permits.
My rule: ngrep is for “what’s on the wire,” not “what I wish were on the wire.”
A modern gotcha: HTTP/2 and gRPC
Even when traffic is “HTTP,” modern clients are often speaking HTTP/2 (especially over TLS), and payloads may be framed in a way that makes naive string matching unreliable.
If I’m debugging gRPC:
- I assume I won’t see meaningful plaintext on
:443. - I try to match only on something I know might exist in cleartext (rare) or I use
ngreponly for presence/timing. - I usually move up the stack: gRPC interceptors, server logs, tracing, or application-level request IDs.
Containers, namespaces, and Kubernetes: practical reality checks
A lot of Linux debugging today happens in containerized deployments, and networking is often namespaced. That changes two things: which interface you need and where you need to run the tool.
Docker and network namespaces
If your app runs in a container with its own network namespace, running ngrep on the host’s eth0 may miss what you care about (or show only NATed/forwarded traffic).
Options I use:
- Run
ngrepin the container (if I can install it and have permissions). - Run a debug container in the same namespace.
- Use
nsenterfrom the host to enter the namespace and capture there.
Even when I stay on the host, -d any plus a strict BPF filter can get me close:
sudo ngrep -d any -q -t ‘.‘ ‘host 172.17.0.5 and tcp and port 8080‘
Kubernetes
In Kubernetes, I usually pick one of these approaches:
- Ephemeral debug container attached to the Pod (modern clusters make this straightforward).
- Node-level capture if I’m debugging a CNI or node firewall issue (and I accept the extra noise).
What I avoid: wide-open captures on production nodes. It’s too easy to capture sensitive payloads, and it’s too easy to burn CPU on a busy interface.
If you need a quick “is traffic even reaching the Pod” check, start with the narrowest possible filter:
sudo ngrep -q -t ‘.‘ ‘host 10.244.2.17 and tcp and port 8080‘
Then tighten further by matching a known request marker if the protocol is plaintext.
Overlay networks and “why is the source IP weird?”
One Kubernetes-specific reality: depending on the CNI, what you see at the node level may be encapsulated (VXLAN/Geneve) or SNATed. That can make “host X talks to host Y” look wrong if you’re expecting pod IPs.
My coping strategy is simple:
- If I’m debugging application traffic, I try to capture inside the pod namespace (or on the pod veth) so I see the true source/destination.
- If I’m debugging network policy / CNI behavior, I capture at the node interface and accept that I’m looking at encapsulation and translated addresses.
Either way, ngrep still does its job: “does this payload token exist in this packet set?”—I just need to choose the right vantage point.
Saved pcaps: make the investigation reproducible
One of the most underrated uses of ngrep is offline searching.
Search a pcap file with -I
If you already have a capture (from tcpdump, from a controlled reproduction, from a lab), you can search it without touching a live interface:
sudo ngrep -q -t -W byline -I /tmp/capture.pcap ‘error|timeout‘ ‘tcp‘
This is huge for:
- post-incident analysis
- sharing a “known problematic” capture with a teammate
- iterating on patterns without generating new traffic
Dump matched packets with -O
When I need evidence but I don’t want the entire capture, I dump only matched packets:
sudo ngrep -q -t -O /tmp/matched-only.pcap ‘X-Request-Id:‘ ‘tcp and port 80 and host 10.0.2.25‘
The practical value here is that I can open /tmp/matched-only.pcap in Wireshark and get stream reassembly, protocol decoding, and better visual context—starting from a much smaller, pre-filtered dataset.
Replay captures with recorded timing
If you’re studying bursty behavior (timeouts, retries, rate limiting), recorded timing can matter. ngrep can replay pcap dumps with their recorded time intervals.
I don’t use this every day, but it’s handy when you’re trying to feel the cadence of a failure.
Performance and operational hygiene
ngrep is lightweight, but it’s still doing real work: capturing packets, scanning payloads, and printing output.
My “don’t melt the box” rules
When I’m on a busy node:
- Always start with a strict BPF filter.
- Prefer short patterns.
- Use
-nto limit the run. - If output is too verbose, stop and tighten rather than letting it scroll.
Example of a safe, time-boxed run:
sudo ngrep -q -t -W byline -n 200 ‘GET |POST ‘ ‘tcp and port 80 and host 10.0.2.25‘
Avoid self-inflicted packet loss
If your debug session causes packet drops, you can chase ghosts. Signs include:
- you see some traffic, but it’s inconsistent
- your
ngrepoutput looks “stuttery” under load
Mitigations:
- tighten the BPF filter further
- reduce output volume (don’t print entire payloads if you can avoid it)
- capture to file and inspect offline when you need deeper analysis
Don’t disable safety features casually
You’ll sometimes see flags that change privilege behavior (for example, options related to privilege dropping). I treat that class of option as “read the documentation, then decide,” not as something to copy-paste into a runbook.
Common mistakes I see (and how I avoid them)
Mistake 1: Searching without a capture filter
This is the fastest way to drown.
Bad:
sudo ngrep -q ‘.‘
Better:
sudo ngrep -q -t -W byline ‘.‘ ‘tcp and port 80 and host 10.0.2.25‘
On high-traffic links, this difference is the gap between a usable tool and a denial-of-service you created yourself.
Mistake 2: Expecting to read HTTPS payloads
If you need content-level evidence, plan for decryption or use tracing/logging. ngrep can still prove connectivity and timing on 443, but it won’t show your JSON keys.
Mistake 3: Quoting and regex pitfalls
Shell quoting matters. I recommend single quotes around patterns so your shell doesn’t interpret special characters.
Good:
sudo ngrep -q ‘User-Agent:|Authorization:‘ ‘tcp and port 80‘
If you need literal backslashes in the regex, remember you may have to escape them. (And if you’re embedding regex into JSON or another templating layer, you may need to escape again.)
Mistake 4: Forgetting output formatting
Raw output can be hard to scan. If you’re reading text protocols, -W byline is the difference between “I can read this” and “I’m guessing.”
sudo ngrep -q -t -W byline ‘.‘ ‘tcp and port 80‘
Mistake 5: Capturing secrets without thinking
If there’s any chance payloads include credentials, tokens, cookies, or PII, treat capture like production data handling.
Habits that help:
- Filter to the smallest host/port set.
- Match on safe markers, not entire payloads.
- Prefer header-only checks when possible.
- Store captures only when needed, and delete them promptly under your org’s policy.
Mistake 6: Confusing “no matches” with “no traffic”
No matches can mean:
- Wrong interface (
-dmismatch). - Wrong BPF filter.
- Payload doesn’t contain your pattern (or it’s encrypted/compressed).
- Traffic exists but doesn’t include payload in the packets you’re seeing.
When I’m unsure, I temporarily switch to ‘.‘ with a strict BPF filter to confirm payload exists at all.
Mistake 7: Matching something too long
If you’re matching a long JSON key path or a long phrase, it’s easy for the bytes to be split across packet boundaries. I prefer:
- match only the top-level key name
- match only the HTTP method and path
- match a short request ID prefix
The goal is to prove the event happened, then move to better tools for deep inspection.
Choosing ngrep vs other tools (my 2026 decision table)
I like simple decision rules. Here’s how I decide when time is tight.
Traditional approach
Where ngrep fits
—
—
tcpdump + manual scan
ngrep -W byline with regex Best-in-class for plaintext
netstat + logs
ss + ngrep/tcpdump Great for quick confirmation
“stare at logs”
ngrep only for timing presence
node captures
Useful but must be narrowed
Wireshark
ngrep is too shallow
hex editors
ngrep -X can work if you know bytesMy short recommendations:
- If the payload is plaintext and you know what string matters, I start with
ngrep. - If I need protocol decoding or reassembly, I capture with
tcpdumpand inspect with Wireshark/tshark. - If it’s encrypted and I need content, I switch to tracing/logging or a permitted decryption workflow.
Next steps I recommend
If you want ngrep to be a reliable part of your toolbox (not a one-off trick), I’d set up three habits.
First, keep a small set of “known good” command templates in your notes: one for HTTP (-W byline + tcp and port 80), one for UDP services (syslog-like traffic), and one for “prove connectivity” on 443 where you accept you’re reading binary. When the page goes off at 2 a.m., you don’t want to invent filters from scratch.
Second, pair ngrep with one other tool. I usually keep ss -tpn for socket-level truth and tcpdump -nn for header-level confirmation. ngrep shows me payload matches; ss shows me which PID owns the connection; and tcpdump (or a pcap) is my escalation path when I need deeper protocol details.
Third, make your captures reproducible. If a problem is intermittent, I’ll often:
- capture only matched packets to a pcap (
-O) - stash the exact
ngrepcommand and BPF filter in the incident notes - replay/search the pcap offline (
-I) so I can iterate on patterns without touching production again
If you do those three things, ngrep stops being a party trick and becomes a dependable “first five minutes” tool in your Linux networking workflow.
