Capturing packets
When logs disagree with reality, the packets settle it. The trick is capturing the right ones without drowning in the rest.
Start narrow
A capture with no filter on a busy server produces gigabytes and tells you nothing. Always filter:
tcpdump -i eth0 -nn host 203.0.113.5 and port 443
-nn stops it resolving names and ports, which otherwise generates DNS
traffic that appears in your own capture — a classic way to confuse
yourself.
Useful filters:
port 25— one servicehost 10.0.0.5— one machinenet 192.0.2.0/24— a networktcp[tcpflags] & (tcp-syn|tcp-rst) != 0— connection attempts and refusals onlyicmp— including the “fragmentation needed” messages behind MTU problemsvlan— tagged frames; see VLANs and tagged interfaces
Write to a file, read it somewhere else
tcpdump -i eth0 -nn -s 0 -w /tmp/capture.pcap host 203.0.113.5
-s 0 captures whole packets rather than the first fragment. Rotate so a
forgotten capture cannot fill the disk:
tcpdump -i eth0 -w /tmp/cap-%H%M.pcap -G 300 -W 12 -nn port 443
Five-minute files, twelve of them, then it starts overwriting. Copy the file off and open it in Wireshark on your own machine — reading a capture on a terminal is possible and painful.
Reading it back
tcpdump -nn -r capture.pcap — replay
tcpdump -nn -r capture.pcap -A — with payload as text, for
plaintext protocols
tcpdump -nn -r capture.pcap 'tcp[tcpflags] & tcp-rst != 0' —
who is refusing connections
What to look for: SYN with no SYN-ACK means it never arrived or was dropped. SYN followed by RST means something actively refused. Retransmissions of the same sequence number mean loss. A handshake that completes and then goes quiet on large packets is MTU.
When offloads lie to you
With GRO and TSO enabled, tcpdump shows packets far larger than the wire MTU, because the card has already reassembled them. For packet-size work specifically, disable them for the duration:
ethtool -K eth0 gro off tso off gso off
and turn them back on afterwards — they are worth real throughput. See network cards and offloads.
The privacy part
A capture contains whatever crossed the wire: addresses, headers, and for unencrypted protocols the content itself. That is personal data, and on a server serving other people it may be their customers' data.
So: capture only what you need, for as long as you need, delete it afterwards, and
do not leave .pcap files in a web-accessible directory. If you are a
processor for someone else's data, think about whether you are allowed to be looking
at it at all — see
who is responsible under the GDPR.
Before you blame the network
If the capture shows packets leaving your machine and nothing coming back, send it to us with the addresses and the time. That is the evidence that turns a vague “the network is slow” ticket into something an engineer can act on — alongside the traces in reading a traceroute.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base